Fixes for Common Issues and Errors
View All Tags
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.
ERROR 3888: Failed to set up SSL with Unable to get private key means MySQL couldn't use the files you asked it to load. The good news is in the manual: a failed reload changes nothing, and the old certificate keeps running until you fix it.
Connections using insecure transport are prohibited while --require_secure_transport=ON means the server refuses anything unencrypted, and this connection is. Turn TLS on in the client: it's usually one option.
Access denied for user 'inventory_app'@'localhost'. Account is locked. is unusually clear: the password isn't the problem, the account is switched off. One thing I didn't expect: sessions that were already connected kept working.
