The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →TLS usually authenticates the server to the client; mutual TLS (mTLS) adds authentication of the client to the server. The handshake negotiates connection parameters, establishes shared secrets and verifies the identities required by the connection. The example below creates a local certificate authority and uses OpenSSL to require and verify a client certificate.
What the TLS handshake does
TLS has two closely related parts: the handshake and the record protocol. During the handshake, peers negotiate cryptographic parameters, establish shared keying material and authenticate identities. Once that succeeds, the record protocol uses the resulting keys and parameters to protect application data.
As an Amazon Associate I earn from qualifying purchases.
As RFC 8446 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.” The protocol does not itself decide what an authenticated user or service is allowed to do; that is an application policy.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsHow a TLS 1.3 certificate handshake proceeds
This is the full certificate-based TLS 1.3 flow in broad outline. Bracketed messages are conditional, and PSK/resumption or a HelloRetryRequest can change the sequence. Unlike earlier TLS versions, TLS 1.3 encrypts more handshake messages after ServerHello, so a packet capture does not expose the entire flow as plaintext.
#1 Best Overall
- POWERFUL SECURITY KEY: The Security Key C NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key C NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key C NFC via USB-C and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
Client Server
ClientHello ---------------------------->
<-------------------------- ServerHello
<-------------------------- EncryptedExtensions
<-------------------------- [CertificateRequest]
<-------------------------- Certificate
<-------------------------- CertificateVerify
<-------------------------- Finished
[Certificate] --------------------------->
[CertificateVerify] --------------------->
Finished ----------------------------->
<=========== protected application data ===========>The client starts with ClientHello, offering supported options. The server responds with ServerHello and then its encrypted handshake messages. Its Certificate identifies the server, CertificateVerify proves control of the private key matching that certificate, and Finished confirms the derived handshake keys and protects the integrity of the handshake transcript. A certificate by itself is not proof that the peer possesses its private key.
What mTLS changes
In ordinary server-authenticated TLS, the server presents a certificate and the client validates it against its configured trust store. In mTLS, the server also requests client authentication with CertificateRequest. The client can then send its Certificate, CertificateVerify and Finished; the server validates the presented certificate under its configured trust and identity policy.
- Who presents a certificate: In standard server-authenticated TLS, the server does. In mTLS, both server and client do.
- Who requests client authentication: The server sends CertificateRequest when it wants client certificate authentication.
- Who validates each certificate: The client validates the server certificate using its configured trust, while the server validates the client certificate using its own configured trust and policy.
- What authentication grants: A verified certificate establishes an identity under the relevant policy; the application still has to map that identity to permissions.
- Operational effect: mTLS adds client certificate issuance, distribution, trust configuration and rotation to the server-side certificate work.
Having a client certificate configured is not enough: the server must request it and accept it. mTLS adds a direction of certificate-based authentication to TLS; it is not a different protected-channel protocol.
Run a local mTLS example with OpenSSL
The following shell commands create a throwaway local CA, issue server and client certificates from it, launch an OpenSSL TLS server that requires a client certificate, and connect with a verifying client. They are intended for OpenSSL installations that provide openssl req, openssl x509 and openssl s_server/s_client. The commands have not been independently executed for this article, so check option availability with your installed OpenSSL version if a command is rejected. Use these files only for a local demonstration, not as a production certificate setup.
Rank #3
1. Create a local CA and issue certificates
Run in a new, empty working directory. The server certificate includes a localhost subject alternative name so the client can verify the hostname.
mkdir tls-mtls-demo
cd tls-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 2
-subj "/CN=Local Demo CA"
# Create and sign a server certificate for localhost.
openssl req -newkey rsa:2048 -nodes
-keyout server.key -out server.csr
-subj "/CN=localhost"
printf "subjectAltName=DNS:localhostnextendedKeyUsage=serverAuthn" > server.ext
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key
-CAcreateserial -out server.crt -days 2 -sha256 -extfile server.ext
# Create and sign a client certificate.
openssl req -newkey rsa:2048 -nodes
-keyout client.key -out client.csr
-subj "/CN=demo-client"
printf "extendedKeyUsage=clientAuthn" > client.ext
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key
-CAcreateserial -out client.crt -days 2 -sha256 -extfile client.ext-nodes leaves the generated private keys unencrypted to keep this local demonstration non-interactive. Protect and delete the files when finished; do not reuse these keys or the demo CA outside the test.
Rank #4
- Tamper Resistant Star Key Set Crafted with premium chrome vanadium steel, and each star tool folds neatly into the handle for quick, easy access.
- Details - The handle is engraved with size for quick identification with drilled tips to allow use.
- Portable - Keys fold compact for easy storage, Drilled tips allow use on tamper resistant security screws.
- Size:Full Size T-6, T-7, T-8, T-9, T-10, T-15 T-20, T-25, T-27 and T-30.
- And with 10 total star sizes able to match nearly all standard tamper resistant security screws on the market.
2. Start a server that requires a trusted client certificate
In the working directory, open a terminal and run:
openssl s_server -accept 8443 -cert server.crt -key server.key
-CAfile ca.crt -Verify 1 -verify_return_error -www-Verify 1 requests and requires a client certificate, and -CAfile ca.crt supplies the CA the server trusts for client authentication. -verify_return_error makes verification errors fatal instead of allowing the diagnostic connection to continue. Keep this terminal running.
3. Connect with a client certificate and verify the server
In a second terminal, from the same directory, run:
Best Value
openssl s_client -connect localhost:8443 -servername localhost
-CAfile ca.crt -verify_hostname localhost -verify_return_error
-cert client.crt -key client.keyThe client trusts only the supplied demo CA for this check, verifies the requested hostname, and presents its client certificate and private key. A successful connection should report that certificate verification succeeded; the server terminal should show the client certificate was received and accepted. At the interactive prompt, type a line and press Enter to see the server’s simple response, or press Ctrl-C to end the client.
4. See what fails when client authentication is missing
Stop the client and reconnect without -cert and -key. Because this server requires a client certificate, the handshake should fail. If it does not, check that the server was started with -Verify 1 and that you are connecting to the intended local listener.
What this OpenSSL test proves—and what it does not
openssl s_client is a diagnostic tool, not a complete application client. Its connection is meaningful as a verified-trust demonstration here because the command explicitly supplies the trust CA, checks the hostname and uses -verify_return_error. Without explicit verification settings, a diagnostic connection can continue after certificate verification errors; a successful connection alone is not proof that trust was verified.
This local example shows a client certificate being requested, validated against a CA and used in a TLS 1.3-capable OpenSSL handshake. It does not implement application authorization: a real service must decide which verified client identities may access which resources. RFC 8446 is the protocol specification; OpenSSL’s TLS 1.3 project notes are implementation guidance on topics such as encrypted handshake messages and cipher-suite configuration.
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.
