A business-critical in-house project management system suddenly stopped working. The server runs CentOS 7 with MySQL Community Edition 5.7.16, while clients use 32-bit Microsoft Access on Windows 11 with the 32-bit MySQL ODBC driver 5.3.13. The clients began reporting a "protocol version mismatch" even though there had been no obvious Windows update or configuration change. Re-enabling older SSL and encryption options did not help, but replacing the ODBC driver with the much older 5.1.13 release restored connectivity. The system had been left largely untouched for years, and the person who normally maintains it is currently on a long sabbatical. The actual cause turned out to be an expired automatically generated MySQL CA certificate, which had reached the end of its validity period.
3 Answers
The fact that an older client driver restored access does not mean it is safer or more compatible long term. Certificate expiration, unsupported software, and undocumented dependencies should be addressed directly rather than solved by freezing the environment in place.
This is also a pretty serious maintenance warning. CentOS 7, MySQL 5.7, a 32-bit Access front end, and an old ODBC stack are all beyond their normal support lifetimes. Even after fixing the certificate, they should document the system, establish backups and monitoring, and make a migration plan before the next certificate, operating system, or compatibility issue causes a longer outage.
The older ODBC driver probably only appeared to fix the problem because it handled the TLS and certificate negotiation differently. The real issue was the automatically generated MySQL CA certificate expiring after its 10-year lifetime. Replacing or renewing the certificate is the proper fix; keeping the old driver only hides the underlying problem.
Exactly. Once the expired MySQL_Server_5.7.15_Auto_Generated_CA_Certificate was replaced, the newer driver worked again.