Open becz opened 3 years ago
I don't believe this is a security regression. The client still validates the server certificate using the original CA certificate, so the connection is still valid. It will also trust an additional CA certificate when you add the second certificate.
The "original CA certificate" was actually overwritten in step 6. So after step 6 the "other broker certificate" in not the second but the only one within InvalidCa.crt library 1.4.15 does not connect after step 6, so expectation is same for library 1.6.14
Follow-up to #2130
The provided fix does not entirely fix the issue.
I run further tests with new library 1.6.14 and observed further "unexpected connect" which is not present with library 1.4.15
I did the following in conjunction with the example project provided in #2130
Use broker with tls enabled and without client authentication (like test.mosquitto.org:8883)
Create empty ca file on client side (e.g. touch InvalidCa.crt)
Start example project (NameOfBinary PathToCaFile) --- observe library does not connect --- (OK)
Write valid certificate for the broker into InvalidCa.crt --- observe library connected to broker --- (OK)
Make sure library disconnects (e.g. switch ethernet off for a while)
Write certificate of "other broker" into InvalidCa.crt (CommonName of certificate does not match host we are connecting to)
Make sure library can connect (e.g. switch ethernet on) --- observe library connected to broker --- (UNEXPECTED)
Output of example program:
--> Write valid certificate data to caInvalid.crt
--> Disconnect client from broker (e.g. switch ethernet off for a while)
--> Write certificate of "other broker" into InvalidCa.crt and enable connection to broker
best regards, Benjamin