TLS client certificates for website access

How mutual TLS works

In the normal TLS handshake only the server presents a certificate, and the client verifies it. Mutual TLS (mTLS) goes one step further: the server also asks the client to present a certificate, and the server verifies that certificate before the connection completes. Both sides prove who they are.

The server asks with a CertificateRequest during the handshake, lists the certificate authorities it will accept, and refuses to complete the handshake if the client does not present a certificate from an accepted authority. This is a digital identity check at the transport layer, so access cannot be guessed, shared as a password, or bypassed with a URL.

mTLS is common for server-to-server and API access, partner integrations, admin panels and a small, known set of users. It is rare on public consumer websites, because every visitor would need a certificate installed, which is exactly why it is a strong gate for a small audience.

What the server sends in the request

When the handshake reaches the certificate exchange, the server tells the client which issuers it trusts and which signature algorithm it accepts:

TLS 1.3  CertificateRequest
  certificate_extensions: authority key identifier
  distinguished_name: CN=Internal CA

The client that holds a certificate issued by that authority sends it; a client with no matching certificate generates a handshake error. If the server requires the client certificate (rather than merely requesting it), the connection fails for a client without one before any HTTP is exchanged.

Issue, renew and revoke

1. Create a CA if you do not have one. It signs the client certificates and is the trust root every server must be configured to accept.
2. Issue a certificate per user or service, with a reasonable expiry (days to a year). Give it an identity (Common Name or SAN) that names the user or device.
3. Install the certificate in the client (a password manager, OS keychain, code signing store or API key file) and keep the private key secret.
4. Configure the server to require the client certificate and to trust only your CA. On nginx:

ssl_verify_client on;
ssl_client_certificate /etc/ssl/ca-client.pem;

1. Renew before expiry. A short expiry bounds the risk of a stolen key. Issue a new certificate, distribute it, and confirm the user can connect before the old one lapses.
2. Revoke promptly when a user leaves or a key is compromised. Publish the serial in a Certificate Revocation List or use OCSP, and make the server check it so a revoked certificate stops working.

When to prefer mTLS

Choose mTLS when the audience is known and small and you need stronger assurance than a username and password. For broad consumer access it is heavy to roll out, and a TLS handshake failure for a user without a cert is an "access denied" you must design for. Where you already rely on server certificate types, adding the client side of the exchange gives you mutual authentication for the small group that needs it.