mTLS
Most important commands to remember
curl --cert … --key …— present a client identity during TLS.openssl x509— inspect a certificate without displaying its private key.
Commands and flags
| Option | Meaning |
|---|---|
-in client.crt -noout |
Read this certificate without printing its encoded contents. |
-subject -issuer -dates |
Show subject, issuer, and validity period. |
-i --max-time 10 |
Include HTTP response headers and bound each transfer to ten seconds. |
--cacert lab-ca.crt |
Use the lab CA to verify the server. |
--cert client.crt --key client.key |
Supply the client’s certificate and corresponding private key. |
Use disposable lab credentials. An encrypted private key may prompt locally for its passphrase; do not put that passphrase in the command.
The concepts that matter
1. Mutual TLS authenticates both sides
Ordinary HTTPS usually authenticates the server to the client. Mutual TLS (mTLS) adds client-certificate authentication so the server can also authenticate its peer at the TLS layer.
This is useful for service-to-service or managed-device communication. It does not mean a human user necessarily logged in, and it does not require that both directions use the same issuing CA.
2. The certificate alone is not the credential proof
A certificate is public information. Authentication also requires proving possession of the matching private key. Copying someone else’s certificate without its private key is therefore not enough to authenticate as that identity.
The certificate’s validity, intended use, and chain must meet the receiving side’s policy. Reading the subject with OpenSSL only inspects metadata; it does not verify the full identity relationship or whether the server will accept it.
3. Server trust and client trust run in opposite directions
The client verifies the server against its configured trust and hostname. The server separately verifies the presented client certificate against its own accepted authorities and policy.
Curl’s --cacert configures server verification; it does not tell the server to trust the client. A valid server certificate and a rejected client certificate can therefore occur in the same attempted connection.
4. Authentication still needs an authorization decision
After identifying a client, the service must decide what that identity may do. A certificate accepted by TLS does not automatically grant access to every route or object.
If a proxy terminates mTLS, the backend may receive identity information through a trusted forwarding mechanism rather than perform client TLS verification itself. Certificate rotation, expiry, and revocation procedures must fit that boundary and the application’s identity mapping.
One small example
Optional: use the existing local mTLS lab and files specified above. This example deliberately does not build a CA or modify a server.
openssl x509 -in client.crt -noout -subject -issuer -dates
curl -i --max-time 10 --cacert lab-ca.crt https://localhost:8443/
curl -i --max-time 10 --cacert lab-ca.crt --cert client.crt --key client.key https://localhost:8443/First read the subject, issuer, and validity dates; those values are not proof of server acceptance. Then compare requests without and with the client certificate. A server requiring mTLS may reject the first during TLS, so there may be no HTTP status.
The second can complete TLS when the client identity is accepted, yet still receive an HTTP authorization error. Exact messages depend on the TLS version and server. A missing file or no listener on 8443 is a local prerequisite failure, not an authentication finding.
Neither command disables server verification. No credential is generated or uploaded outside this local lab, and no cleanup is needed.
Keep this idea: mTLS proves possession of accepted client and server identities; application policy decides their permissions.