Skip to main content

Glossary Infrastructure

Mutual TLS

Also: mTLS, client-certificate authentication, TLS client authentication

Origin: TLS client-certificate authentication has been part of the TLS standard since TLS 1.0 (RFC 2246, 1999); the operational pattern of using it as a primary authentication mechanism for sensitive surfaces has developed since the early 2010s.

A TLS connection mode in which the client, in addition to the server, presents and proves possession of a public-key certificate during the TLS handshake. The server may then authenticate the client by certificate (rather than, or in addition to, a password or session token) and refuse the connection if the certificate is not on a whitelist.

Mutual TLS — mTLS — is a TLS connection mode in which the client, in addition to the server, presents and proves possession of a public-key certificate during the TLS handshake. The server may then authenticate the client by certificate (rather than, or in addition to, a password or session token) and refuse the connection if the certificate is not on a whitelist. The handshake mechanic has been part of the TLS standard since TLS 1.0 in 1999; the operational pattern of using mTLS as the primary authentication mechanism for sensitive operator-side surfaces — administration consoles, internal APIs, newsroom-side editor access — has developed since the early 2010s.

The substantive security benefit over a username-and-password (or even a TOTP-protected username and password) is that an attacker who has phished the password cannot complete the handshake — they would also need to phish the private key associated with the certificate, which is materially harder when the key is held in a hardware token or in a properly-secured platform key-store. A server configured to require mTLS will refuse the TLS handshake itself before the application layer is reached, which moves the attack surface from “phishing plus credential-stuffing” to “key-extraction plus active TLS attack” — a step-change in difficulty for the attacker.

Operationally, mTLS is paired with a small organisation-internal certificate authority that issues and revokes the client certificates. The CA’s root certificate is enrolled on the server; client certificates are issued per device or per editor; revocation is tested against an OCSP responder or a CRL on every connection. The administration of the CA is the substantive overhead; the per-connection cost is essentially zero.

For an offshore-hosting operator the principal mTLS use-cases are operator-side: the administration consoles for the hosting infrastructure, the issuance gateway for journalists’ newsroom access (where the newsroom runs on operator infrastructure), and the long-lived API surfaces used for inter-system communication within the operator’s own services. The publication has set out the operational guidance for the newsroom-side deployment pattern in the upcoming field-note on Caddy-mediated mTLS for newsroom access.