MySQL Relational Database Server and Its Tools
View All Tags
SslMode=VerifyCA worked. Moving up to VerifyFull, which only adds a check of the server's name, failed with a complaint about a client certificate I'd never needed. The driver insists on one with PEM files, and then it never sends it.
I raised SslMode from Required to VerifyCA and the connection stopped working, with No file path has been provided for the connection option SslCa. VerifyCA means "check who signed the server's certificate", so the driver needs to know which signature to trust, and it only looks in the file you give it.
No error page and no 500: the whole API process ended, in the middle of a burst of requests. The message mentions authentication and I/O, and neither was the problem. The real cause is more requests at once than Maximum Pool Size, and a callback inside the driver that throws where nothing can catch it.
tlsv1 alert protocol version is the server telling the client that it won't use that TLS version. The two have nothing in common, and the fix is to find what each allows.
SSL error: Unable to get private key in the MySQL image usually means MySQL can't read the key file, not that there's anything wrong with it. MySQL runs as user 999 in that image. And the server starts anyway, with no working TLS, which is easy to miss.
CA certificate ca.pem is self signed turns up in MySQL's log every time it starts, and I went looking for what I'd done wrong. Nothing. Every root CA is self-signed, by definition, so MySQL's own automatic CA triggers it on a default install.
Failed to validate certificate … because certificate has expired is a warning, not an error, so MySQL starts and accepts TLS connections as usual. Clients that check certificates will refuse it. Clients that don't won't notice, which is the worst of both.
MySQL started, said TLS was fine, and two lines above that, warned me Failed to validate certificate … because invalid CA certificate. It carries on regardless, so the warning is easy to miss, and clients that check the certificate will be the ones to fail.
The password was right, and I still got ERROR 1045 (28000): Access denied. MySQL gives no hint of the real reason: this account has REQUIRE SSL, and the connection didn't use TLS. It caught me over a local socket too, which require_secure_transport would have allowed.
The client was disconnected by the server because of inactivity means this session was idle for longer than MySQL allows, and the server closed it. The mysql client then reconnects by itself, so it looks odd but costs you one retry. Anything that session set up is gone, though.
