iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
TLS authenticates a server to a client and establishes keys for protected traffic. Mutual TLS (mTLS) adds client authentication: the server requests a client certificate, and the client proves it controls the matching private key. The example below creates a local certificate authority, configures an OpenSSL server to require a client certificate, and connects with a verified client command.
What happens in a TLS handshake?
TLS has two related parts: the handshake and the record protocol. The handshake negotiates cryptographic parameters, authenticates the communicating parties, and establishes shared keying material. The record protocol then uses that material to protect application data.
In a full certificate-based TLS 1.3 handshake, the client begins with ClientHello. The server replies with ServerHello and then sends encrypted handshake messages, including its certificate and proof that it possesses the corresponding private key. Finished confirms the handshake keys and protects the integrity of the handshake transcript. As the RFC 8446 abstract puts it, “TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.” RFC 8446 was published in August 2018.
This is the common certificate-based flow, not a description of every TLS 1.3 connection. Resumption using pre-shared keys, a HelloRetryRequest, or optional client authentication can alter the messages. Also, messages after ServerHello are not all visible in plaintext on the network: TLS 1.3 encrypts more of the handshake than earlier TLS versions.
#1 Best Overall
Typical TLS 1.3 certificate-based flow
Client Server
ClientHello ---------------------------->
<-------------------------- ServerHello
<-------------------------- EncryptedExtensions
<-------------------------- [CertificateRequest]
<-------------------------- Certificate
<-------------------------- CertificateVerify
<-------------------------- Finished
[Certificate] --------------------------->
[CertificateVerify] --------------------->
Finished ----------------------------->
<=========== protected application data ===========>Brackets mark optional messages. CertificateRequest and the client’s certificate-related messages appear when the server requests client authentication and the client responds with a certificate.
How does mTLS differ from ordinary TLS?
In ordinary server-authenticated TLS, the server presents a certificate and the client validates the server’s identity. In mTLS, the server also asks the client to authenticate with a certificate. The server validates that certificate against its configured trust and identity policy.
| Question | Server-authenticated TLS | mTLS |
|---|---|---|
| Who presents a certificate? | The server presents its certificate to the client. | The server presents its certificate; the client also presents one when requested. |
| Who requests client authentication? | Usually, no client certificate is requested. | The server requests client authentication, using CertificateRequest in the TLS 1.3 flow. |
| Who validates each certificate? | The client validates the server certificate against its trust configuration. | The client validates the server certificate, and the server validates the client certificate against its own configured trust and policy. |
| What does authentication grant? | It establishes the authenticated peer identity; application access remains a separate decision. | It establishes the client identity for the TLS connection; the application must still map that identity to permissions. |
| What operational work is added? | Server certificate issuance, trust, and rotation. | Client certificate issuance, distribution, trust, and rotation are added to server certificate operations. |
mTLS adds a direction of certificate-based authentication; it is not a separate cryptographic channel protocol. A client certificate by itself does not guarantee a successful exchange: the server must request it and accept it under its certificate policy.
Free tools Windows power users keep installed
One-click scans. No signup required.
What do CertificateVerify and Finished prove?
A certificate identifies a public key, but presenting the certificate alone does not prove that the peer controls the corresponding private key. CertificateVerify signs a value derived from the handshake transcript using that private key. This ties the proof to this handshake rather than merely repeating a certificate.
Finished uses a key derived from the handshake secrets to confirm key possession and protect the handshake transcript’s integrity. In mTLS, the client’s CertificateVerify and Finished provide the client-side proof and confirmation when the client responds to CertificateRequest. See the authentication and verification details in RFC 8446.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Run a local mTLS example with OpenSSL
The following Bash commands create a local CA, issue server and client certificates, start a TLS 1.3 server that requires a client certificate, and connect with a client that explicitly verifies the server certificate. They are a runnable example for an OpenSSL installation that supports the shown options; they were not independently tested for a particular OpenSSL build. Run them in a disposable directory on a machine with OpenSSL and Bash.
Rank #4
1. Create a local CA and issue certificates
mkdir mtls-demo && cd mtls-demo
# Create a local CA key and self-signed CA certificate.
openssl req -x509 -newkey rsa:2048 -nodes
-keyout ca.key -out ca.crt -days 365
-subj "/CN=Local Demo CA"
# Create the server key and certificate signing request.
openssl req -newkey rsa:2048 -nodes
-keyout server.key -out server.csr
-subj "/CN=localhost"
# Issue a server certificate with a localhost subject alternative name.
printf "subjectAltName=DNS:localhost,IP:127.0.0.1nextendedKeyUsage=serverAuthn" > server.ext
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key
-CAcreateserial -out server.crt -days 365 -sha256
-extfile server.ext
# Create the client key and certificate signing request.
openssl req -newkey rsa:2048 -nodes
-keyout client.key -out client.csr
-subj "/CN=demo-client"
# Issue a client certificate.
printf "extendedKeyUsage=clientAuthn" > client.ext
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key
-CAcreateserial -out client.crt -days 365 -sha256
-extfile client.extThe CA signs both leaf certificates so each side can validate the other using ca.crt. The server certificate includes a localhost subject alternative name for the client’s hostname check, and the client certificate is marked for client authentication.
2. Start the server and require a client certificate
In one terminal, from the mtls-demo directory, run:
Best Value
- Used Book in Good Condition
openssl s_server -accept 8443 -tls1_3
-cert server.crt -key server.key
-CAfile ca.crt -Verify 1 -verify_return_error
-www-Verify 1 makes client-certificate verification mandatory. -CAfile ca.crt supplies the trust anchor for checking the client certificate, while -verify_return_error makes verification errors fatal instead of allowing the diagnostic connection to continue. The -www option provides a simple HTTP response for the demonstration.
3. Connect with a client certificate and verify the server
In a second terminal in the same directory, run:
openssl s_client -connect localhost:8443 -tls1_3
-servername localhost -verify_hostname localhost
-CAfile ca.crt -verify_return_error
-cert client.crt -key client.keyThe client trusts the server certificate through -CAfile ca.crt, checks that its name matches localhost, and supplies the client certificate and key. With both sides’ certificates accepted, the command completes the TLS connection; you can type an HTTP request such as GET / HTTP/1.0, press Enter twice, and see the server’s response. A successful connection demonstrates certificate validation for this local setup, not application authorization or the suitability of these demo credentials for production.
What failures mean
- Unknown CA or certificate verification failure: Confirm both commands use the same
ca.crt, and that the certificates were issued by that CA. The client’s-verify_return_errorensures a verification problem is not silently treated as a successful diagnostic connection. - Hostname mismatch: Connect using
localhostand keep-verify_hostname localhost; the server certificate’s subject alternative name must match the hostname being verified. - Server reports a missing client certificate: Check that the client command includes
-cert client.crt -key client.key, and that the server is running with-Verify 1. - Connection refused: Ensure the server command is still running and that the client is connecting to port 8443 on the same machine.
openssl s_client is a diagnostic client, and its behavior around certificate errors makes explicit verification important. Its documentation describes options including -verify_return_error, -CAfile, and hostname verification: OpenSSL s_client documentation. OpenSSL’s TLS 1.3 project notes discuss implementation changes such as altered cipher-suite configuration, more encrypted handshake messages, and removal of renegotiation; those notes are implementation guidance, not the protocol specification: OpenSSL TLS 1.3 notes.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
