After a DBA enabled TLS on a database server with a self-signed certificate whose subject is "localhost", every client connecting to db01.corp.example.com reports an untrusted certificate and a name mismatch. Security requires encrypted connections with server identity verification. What should the DBA do?

TLS server authentication depends on two checks performed by the client: the certificate chains to a certificate authority in the client's trust store, and the host name the client connected to matches a name in the certificate, normally in the subject alternative name extension. A self-signed certificate issued to localhost fails both checks for clients connecting to db01.corp.example.com. Replacing it with a certificate from an internal or public CA that clients already trust, with the correct DNS name, satisfies both checks and preserves server identity verification. Configuring clients to trust the server certificate without validation removes the warning by removing the protection: connections stay encrypted, but any impostor presenting any certificate would be accepted, enabling interception. Disabling TLS and relying on a firewall drops the encryption requirement entirely; network restrictions limit who can connect but do not protect data in transit or prove the server's identity. A longer key and longer validity on a new self-signed localhost certificate change neither the trust failure nor the name mismatch, so both warnings remain. Exam caveat: encryption without validation is not secure transport. Operational check: connect from a client with full certificate validation enabled and confirm the handshake succeeds with no trust or name warnings.