Some database deployments require each client to present its own X.509 certificate before the session is accepted. What does that buy over a password, and what operational burden does it add?
answer
- proof of key possession, no bearer secret
- subject/SAN mapped to a database role
- cert can gate admission and still require a password
- revocation weak, so keep lifetimes short
- pooler collapses per-service identity
basics
~20 sA client certificate proves who is connecting without sending a reusable shared secret, and the server maps the certificate subject to a database role. The cost is a full certificate lifecycle: issuance per service, secure distribution, short expiry causing outages, and revocation that is hard to make timely.
solid answer
~50 sWith mutual TLS the database also authenticates the caller: the client proves possession of a private key, and the server maps the certificate's subject or SAN to a database role, usually requiring the mapped name to match the role being requested. Advantages over a password: nothing reusable crosses the wire, the credential is bound to a key that can be kept in a hardware or platform key store, identity is per service rather than a shared string in a config file, and rotation is a defined process rather than an ad-hoc secret change. Many deployments require both certificate and password, so a stolen certificate alone is not enough. The burden is real: every service needs an issued certificate, delivered securely and renewed automatically, or expiry becomes an outage. Revocation is the weak point -- CRL/OCSP checking on database connections is often absent, so short lifetimes are the practical answer. Poolers complicate it, since the pooler becomes the certificate-bearing client.
go deeper
Know that mutual TLS means the client also presents a certificate and that it identifies the caller rather than encrypting more.
Explain the mapping from certificate subject to database role and why a certificate does not grant privileges.
Own the lifecycle: automated renewal, expiry alerting, the weakness of revocation, and pooler interactions; know the emergency cut-off is the role, not the CRL.
Decide whether workload identity should come from the platform (mesh/workload identity) or a database-specific PKI, and price the operational risk against shared-secret alternatives.
## What mutual TLS means for a database connection In an ordinary TLS session only the server proves its identity. With client certificates the server also demands proof from the caller: the client sends its certificate and signs a handshake value with the matching private key. The database then applies two separate decisions: 1. **Is the certificate acceptable?** It must chain to a CA the server trusts and be within its validity window. Deployments usually require the client CA to be a dedicated internal CA, not the public web PKI, so only certificates you issued can connect at all. 2. **Which database role does it correspond to?** The engine extracts a name from the certificate (common name or SAN) and either requires it to equal the requested database user or maps it through a name-mapping table. This is the step that turns a cryptographic identity into an authorization subject. An important nuance: requiring a client certificate is a *transport* admission check, and mapping it to a role is *authentication*. Some deployments use the certificate only as an admission gate and still require a password for authentication -- effectively two factors for a machine account. ## Why teams adopt it - **No reusable secret on the wire or in a config file.** A password is a bearer token: whoever reads the deployment manifest can connect from anywhere. A private key can live in a platform key store or hardware module and never be exported. - **Per-service identity.** Each deployment gets its own certificate, so audit logs and connection sources attribute activity to a specific workload instead of one shared application account. - **A real lifecycle.** Certificates have issuance, expiry and renewal built in, which forces rotation to exist as a process; shared passwords notoriously never rotate. - **Composability with platform identity.** In environments that already issue workload certificates (a service mesh, a workload identity system), the database can consume the same identity rather than inventing another secret. ## What it costs - **Distribution.** Every instance of every service needs a key pair delivered securely at start-up, which means an issuing service or an agent, not a file baked into an image. - **Expiry becomes an outage class.** Short lifetimes are good for security and bad for uptime unless renewal is fully automated and monitored ahead of the deadline. A missed renewal fails *every* connection at once. - **Revocation is weak.** Databases often do not check CRLs or OCSP for client certificates, or the check is a static file that nobody refreshes. The practical mitigation is short validity plus the ability to remove the mapped role, since revoking the database role is instant while revoking a certificate may not be. - **Poolers and proxies break the chain.** If a pooler terminates TLS, the pooler holds a certificate and the database sees one identity for many callers -- collapsing exactly the per-service attribution you wanted. Either the pooler passes through identity explicitly or the model must be rethought. - **Debuggability.** Failures are opaque: 'connection closed' can mean an expired certificate, an untrusted CA, a name that does not map, or a clock skew. Teams need a runbook. ## How to talk about it A strong answer positions client certificates as *machine authentication with a lifecycle*, contrasts it with bearer secrets, and is honest about the two hard parts -- renewal automation and revocation. It also connects the mapping step: a certificate alone authorizes nothing; the mapped role's grants still decide what the session may do.
- A client certificate for a service is believed to be compromised. How do you cut off access quickly?Do not rely on revocation lists alone, since many database servers do not check them or refresh them slowly. The fast, reliable lever is the database side: remove or lock the role the certificate maps to, or drop the mapping entry so the identity no longer resolves to any account. Then issue a new certificate under a new identity and, in parallel, publish the revocation and shorten lifetimes if this was the second incident.
- Does mutual TLS replace the need for least-privilege grants on the account?No. Certificates decide who is connecting, not what they may do. Once the session is established the role's privileges govern every statement, so a compromised workload with a valid certificate still reaches everything that role can reach. Authentication strength and privilege scope are independent controls and both are required.
saying these in an interview costs you the question
- Saying a client certificate makes the connection more encrypted -- it changes who is authenticated, not the cipher
- Assuming revocation is timely because a CRL exists
- Baking a long-lived client key into a container image
- Believing a valid certificate implies authorization to read the data
- Ignoring that a TLS-terminating pooler becomes the single certificate identity