Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Incomplete
-
10.6
-
None
Description
When replacing the server certificate and key with a cert signed by a different CA than the one configured with ssl-ca there is no error or warning returned to the client that has executed the FLUSH SSL statement to re-read the certificate files, and no warning in the server error log either.
So it looks as everything were OK, but the next client trying to connect via SSL will be greeted with
ERROR 2026 (HY000): SSL connection error: authority and subject key identifier mismatch
|
IMHO the user executing the FLUSH SSL should receive an error, or at least a warning, about the ca-cert / server-cert mismatch.
Attachments
Activity
This is especially about FLUSH SSL as the customer wants to rotate certificates without downtime, and in that situation not getting any feedback from the flush command regarding success or failure is a nightmare.
The optimal scenario would be for the server to continue to use the old certificate in case loading a new one at runtime files for whatever reason, until the failure has been resolved completely.
I think you might have misunderstood the question. So, the FLUSH SSL does succeed, and SSL connections are no more possible. But with the same non-matching certificates, if user restarts the server and does not do any "FLUSH SSL", connections are exactly as impossible, right? Or it magically behaves much better, with restart?
I just wanted to confirm that server startup does not behave differently from "FLUSH SSL. and misses the mismatch exactly as FLUSH SSL misses it and is silent exactly as FLUSH SSL is silent.
hholzgra Not sure why you picked "FLUSH SSL" specifically. If you just used this same incorrect combination certificates at the startup, the server would spit out a better error or warning? is this the case?