How does client-certificate authentication (mutual TLS) to a database work, and what operational burdens does it add compared with password authentication?

## The mechanism Certificate authentication rides on the TLS handshake rather than adding a database-level exchange. 1. The connection is required to use TLS, and the server is configured to *request* a client certificate. 2. The client sends its certificate chain and proves possession of the corresponding private key by signing handshake data. That proof of possession is the whole point — the certificate itself is public. 3. The server validates the chain up to a CA it has been explicitly configured to trust, checks the validity dates, checks key usage/extended key usage, and consults its revocation material. 4. The server extracts an identity from the certificate subject — typically the Common Name — and resolves it to a database role, either by requiring an exact match with the requested role name or by consulting a name map that translates subjects to roles. 5. Only now does a session exist, with that role and no privileges beyond whatever the catalog grants it. Two settings are worth separating: requiring only that the certificate be *valid* versus requiring that it also *identify* the connecting role. The weaker mode makes the certificate an extra factor alongside a password; the stronger mode makes it the sole credential. ## Why it is attractive - **No shared secret in transit or at rest on the server.** The server stores no verifier that could be dumped and cracked; it stores a CA certificate, which is public material. - **Nothing to phish or replay.** The private key never leaves the client, and each handshake signature is bound to that handshake. - **Good fit for machine identities.** Service meshes and workload-identity systems already mint short-lived certificates; the database can consume the same identity rather than inventing another password. - **Identity is cryptographically bound to key possession**, which is much stronger than a string an application reads from an environment variable. ## The burdens **Expiry is an outage with a countdown.** Every certificate has an end date, and a fleet issued from the same automation tends to expire together. Unlike a wrong password, expiry hits every client at once and the error is often reported as a generic handshake failure. You need issuance automation, monitoring on days-to-expiry, and renewal well before the edge. **Revocation is weaker than people assume.** Many databases check a certificate revocation list loaded from a file (or a CRL directory), refreshed only when the server reloads. A key compromised at noon stays valid until you regenerate and distribute the list and reload. Live OCSP checking is frequently unavailable. Short lifetimes are a more reliable mitigation than revocation. **The trusted CA is the real authorization boundary.** The server trusts *any* certificate that chains to its configured CA. Point it at a broad corporate CA and every certificate that organisation ever issued — laptops, printers, unrelated services — becomes a candidate identity, limited only by how strictly you map subjects to roles. The correct posture is a dedicated CA used for nothing else, plus a name map that enumerates which subjects may become which roles. **Private key handling becomes your problem.** Keys must be delivered to containers or hosts, given restrictive file permissions (clients typically refuse world-readable key files), kept out of images and version control, and rotated. That is the same secret-distribution problem passwords have — it does not disappear, it changes shape. **Operational friction.** Interactive users find certificates far more awkward than passwords; ad-hoc tooling, GUI clients and CI runners all need the material wired in. Debugging is harder: a mismatched subject, a missing intermediate, a clock skew, or a hostname mismatch on the server side all surface as opaque TLS errors rather than clear "wrong password" messages. ## What it does not do It is authentication only. The role must exist and must have been granted privileges; a perfectly valid certificate can produce a session that cannot read a single table. It also does not decide *which* connections are permitted to use certificates — host-based rules select the method and the source ranges. And on its own it says nothing about whether the client verified the *server's* certificate; a client that skips server verification is still exposed to a man-in-the-middle even while presenting a client certificate. ## Practical guidance Use it for service accounts with automated, short-lived issuance and monitored expiry; keep a dedicated CA; enforce an explicit subject-to-role map rather than trusting bare name equality across a broad CA; and keep a break-glass path that does not depend on the PKI being healthy. ## What interviewers listen for Beyond the handshake mechanics, they want the two mature observations: the trusted CA defines who can even attempt to be someone, and revocation in practice is weaker than expiry management — so short lifetimes plus automation beat a CRL you refresh by hand.