A business-critical in-house project management system suddenly stopped working. The server runs CentOS 7 with MySQL Community Edition 5.7.16, while Windows 11 clients use 32-bit Microsoft Access and the 32-bit MySQL ODBC 5.3.13 driver. The clients began reporting a "protocol version mismatch" even though there were no obvious recent Windows updates, and changing the enabled TLS versions and encryption algorithms did not help. Downgrading to the much older ODBC driver 5.1.13 temporarily restored connectivity. The cause turned out to be an expired auto-generated MySQL CA certificate, specifically the MySQL_Server_5.7.15_Auto_Generated_CA_Certificate, which had reached its 10-year expiration date. Has anyone else dealt with this kind of certificate expiration, and what would you recommend for keeping such a legacy setup reliable while it is being migrated?
4 Answers
I would avoid treating the old ODBC driver as the real fix. It may bypass stricter TLS or certificate checks, but that can weaken security and create another compatibility problem later. Install a properly renewed certificate, verify the trusted CA on the clients, and test a supported driver in a staging environment before changing the production system.
This setup has several long-term risks beyond the certificate: CentOS 7 and MySQL 5.7 are both end-of-life, and the 32-bit Access/ODBC stack is difficult to maintain. Once service is restored, document the dependencies, schedule regular certificate renewal, and prioritize moving to a supported operating system, database version, and client architecture.
The immediate problem was the expired MySQL auto-generated CA certificate. Replacing or renewing the server certificate and ensuring the clients trust the new CA should resolve the TLS negotiation failure. The older ODBC driver probably only appeared to help because it handled certificate or TLS validation differently.
That was exactly it. The certificate had expired after ten years. It fixed the connection, although the system still needs a proper modernization plan.
The bigger lesson is that a business-critical application cannot depend on one person and an untouched server. Even if the certificate issue is resolved, the company should establish ownership, backups, monitoring, patching, and a migration plan instead of waiting for the next ten-year failure.
A certificate renewal process and monitoring would at least prevent another surprise outage while the migration is being planned.