Mutual TLS (mTLS) on Nginx: A Comprehensive Guide to Configuration and Use Cases

In the ever-evolving landscape of cybersecurity, securing communication channels is paramount. While standard Transport Layer Security (TLS), often referred to by its predecessor’s name SSL, provides encryption and server authentication, it typically only verifies the identity of the server to the client. Mutual TLS (mTLS) takes this a step further by requiring both the client and the server to authenticate each other using X.509 certificates. This creates a significantly more secure communication channel, particularly vital in scenarios where trust needs to be explicitly established in both directions.

Nginx, being a powerhouse web server, reverse proxy, load balancer, and API gateway, is frequently deployed at the edge of networks or between microservices. Implementing mTLS on Nginx allows organizations to enforce strong, certificate-based authentication for various critical workflows.

This article provides a detailed exploration of Mutual TLS, covering its core concepts, the step-by-step process of generating necessary certificates, configuring Nginx for mTLS, demonstrating client usage, and discussing practical use cases where mTLS shines.

Understanding TLS and Mutual TLS
- Recap: The Standard TLS Handshake
- Introducing Mutual TLS (mTLS)
- The mTLS Handshake Explained
- Why Use mTLS? Key Benefits
Prerequisites
- Nginx Installation
- OpenSSL Toolkit
- Basic Understanding of TLS/SSL Concepts
- A Domain Name (Optional but Recommended for Realistic Scenarios)
Certificate Infrastructure: The Foundation of mTLS
- The Role of the Certificate Authority (CA)
- Server Certificates
- Client Certificates
Generating Certificates for mTLS using OpenSSL
- Step 1: Setting Up Your Own Certificate Authority (CA)
  - Generating the CA Private Key
  - Generating the CA Root Certificate
- Step 2: Generating the Server Certificate
  - Generating the Server Private Key
  - Generating a Certificate Signing Request (CSR) for the Server
  - Signing the Server CSR with the CA
- Step 3: Generating the Client Certificate
  - Generating the Client Private Key
  - Generating a Certificate Signing Request (CSR) for the Client
  - Signing the Client CSR with the CA
- Step 4: Organizing Your Certificates
Configuring Nginx for Mutual TLS
- Basic TLS Configuration in Nginx (Prerequisite)
- Enabling Client Certificate Verification
  - ssl_client_certificate: Specifying the Trusted CA
  - ssl_verify_client: Controlling Verification Level (on, off, optional, optional_no_ca)
- Mandatory mTLS Configuration Example
- Optional mTLS Configuration Example
- Passing Client Certificate Information to Backend Applications
  - Nginx Variables ($ssl_client_verify, $ssl_client_s_dn, $ssl_client_i_dn, $ssl_client_serial, $ssl_client_cert, $ssl_client_raw_cert)
  - Using proxy_set_header
- Configuring Certificate Revocation
  - Certificate Revocation Lists (CRLs)
  - Configuring Nginx with ssl_crl
  - Online Certificate Status Protocol (OCSP) – Considerations
Client-Side Usage of mTLS
- Using curl
- Browser Configuration (Importing Client Certificates)
- Programmatic Access (Examples)
  - Python with requests
  - Go with net/http
Common Use Cases for mTLS
- API Security: Securing Server-to-Server Communication
- Microservices Authentication: Establishing Trust within Internal Networks
- IoT Device Authentication: Verifying Device Identities
- B2B Integrations: Securing Partner Connections
- Securing Access to Sensitive Resources: Internal Dashboards, Admin Panels
- Zero Trust Architecture: Enforcing Identity Everywhere
- Mobile Application Security: Authenticating Mobile Apps to Backends
Advanced Topics and Considerations
- Performance Impact: Handshake Overhead
- Certificate Lifecycle Management: The Biggest Challenge (Issuance, Renewal, Revocation)
- Scalability: Managing Certificates for Numerous Clients
- Error Handling and Debugging: Common Nginx Errors, OpenSSL Tools
- Security Best Practices: Key Protection, CA Security, Algorithm Choices
- Integration with Service Meshes: Istio, Linkerd Automating mTLS
- Alternatives and Complements: API Keys, OAuth, JWT
Conclusion

1. Understanding TLS and Mutual TLS

Before diving into mTLS configuration, it’s essential to grasp the fundamentals of standard TLS and how mTLS extends it.

Recap: The Standard TLS Handshake

In a typical HTTPS connection using TLS, the primary goal is to encrypt the communication channel and verify the server’s identity. The simplified handshake looks like this:

Client Hello: The client initiates the connection, sending its supported TLS versions, cipher suites, and a random string.
Server Hello: The server responds, choosing a TLS version and cipher suite, sending its own random string, and crucially, its SSL/TLS certificate.
Server Certificate Verification: The client verifies the server’s certificate. This involves checking:
- If the certificate is signed by a trusted Certificate Authority (CA) present in the client’s trust store.
- If the certificate has expired or been revoked.
- If the domain name (Common Name or Subject Alternative Name) in the certificate matches the domain the client is trying to connect to.
Key Exchange: Client and server securely exchange information (using mechanisms like RSA or Diffie-Hellman) to generate a shared symmetric session key.
Finished: Both client and server send “Finished” messages, encrypted with the newly established session key, confirming the handshake is complete.
Encrypted Communication: All subsequent application data is encrypted using the symmetric session key.

Notice that in this standard flow, only the server presents a certificate and proves its identity. The client remains anonymous at the TLS layer (though authentication might happen later at the application layer, e.g., via username/password).

Introducing Mutual TLS (mTLS)

Mutual TLS builds upon the standard TLS handshake by adding a requirement for the client to also present a certificate and prove its identity to the server. This mutual authentication ensures that both parties involved in the communication are who they claim to be.

The mTLS Handshake Explained

The mTLS handshake includes additional steps compared to the standard TLS handshake:

Client Hello: Same as standard TLS.
Server Hello: Same as standard TLS, including the server sending its certificate.
Server Certificate Verification: The client verifies the server’s certificate, just like in standard TLS.
Certificate Request (Server): This is a key mTLS step. After sending its certificate (and potentially other messages like Server Key Exchange), the server sends a CertificateRequest message to the client. This message indicates that the server requires client authentication and may specify acceptable CAs (Distinguished Names) that should have signed the client’s certificate.
Client Certificate & Certificate Verify (Client): Another key mTLS step. If the client has an appropriate certificate (issued by a CA trusted by the server for client authentication) and agrees to authenticate:
- It sends its own client certificate in a Certificate message.
- It sends a CertificateVerify message. This message contains a digitally signed hash of all preceding handshake messages. The signature is created using the client’s private key corresponding to the public key in its certificate. This proves to the server that the client possesses the private key associated with the presented certificate.
Client Certificate Verification (Server): The server receives the client’s certificate and the CertificateVerify message. It performs verification:
- Checks if the client certificate is signed by a CA that the server trusts for client authentication (configured on the server).
- Checks if the certificate is valid (not expired, not revoked).
- Uses the public key from the client’s certificate to verify the signature in the CertificateVerify message. A successful verification proves the client holds the corresponding private key.
Key Exchange: Same as standard TLS, client and server generate a shared symmetric session key.
Finished: Same as standard TLS, confirming the handshake.
Encrypted Communication: Same as standard TLS.

The critical difference is the reciprocal authentication: the server authenticates the client using the client’s certificate, just as the client authenticates the server using the server’s certificate.

Why Use mTLS? Key Benefits

Strong Identity Verification: Provides cryptographic proof of identity for both parties, significantly reducing the risk of impersonation or Man-in-the-Middle (MitM) attacks where the attacker spoofs the client.
Enhanced Security for APIs and Microservices: Ensures only authorized services or clients can communicate with each other, crucial in distributed systems.
Device Authentication (IoT): Allows servers to verify the identity of connecting IoT devices, preventing unauthorized devices from accessing the network or sending malicious data.
Improved Access Control: Acts as a strong authentication factor at the network edge, preventing unauthorized access attempts before they even reach the application layer.
Compliance Requirements: Helps meet strict security requirements in regulated industries (e.g., finance, healthcare) that mandate strong authentication.
Foundation for Zero Trust: Aligns perfectly with Zero Trust principles, which assume no implicit trust based on network location and require verification for every connection.

2. Prerequisites

Before configuring mTLS on Nginx, ensure you have the following:

Nginx Installation: A working Nginx installation (version 1.13.8+ recommended for better variable support, but basic mTLS works on older versions). Nginx must be compiled with the http_ssl_module (--with-http_ssl_module), which is standard in most distributions. You can check using nginx -V.
OpenSSL Toolkit: The openssl command-line tool is essential for generating keys and certificates. It’s typically installed by default on most Linux systems. Verify with openssl version.
Basic Understanding of TLS/SSL Concepts: Familiarity with terms like private keys, public keys, certificates, Certificate Authority (CA), and the basic TLS handshake.
A Domain Name (Optional but Recommended): While you can use IP addresses or dummy names for testing, using a real domain name (even a self-managed one like myapi.internal) makes the server certificate configuration more realistic. For server certificates facing the public internet, a publicly trusted CA is needed, but for mTLS involving internal services or specific clients, a private CA is standard practice and what we’ll focus on.

3. Certificate Infrastructure: The Foundation of mTLS

mTLS relies heavily on a Public Key Infrastructure (PKI), specifically X.509 certificates. Understanding the roles of different components is crucial.

The Role of the Certificate Authority (CA)

The CA is the cornerstone of trust in a PKI system. It’s a trusted entity responsible for:

Issuing Certificates: Signing certificate requests to create valid certificates for servers and clients.
Verifying Identities: (In a real-world scenario) Verifying the identity of the entity requesting a certificate before issuing it. For our private CA, we are the authority defining trust.
Managing Revocation: Maintaining and publishing lists of certificates that are no longer valid before their expiration date (e.g., if a private key is compromised).

For mTLS, you typically set up your own private CA. This CA will be used to sign both the server certificate used by Nginx and the client certificates used by connecting clients. The Nginx server will be configured to trust only certificates signed by this specific private CA for client authentication. Similarly, clients connecting via mTLS must trust this private CA to validate the server’s certificate (though often they also need to trust public CAs for general web browsing).

Server Certificates

This is the standard TLS certificate presented by the Nginx server to identify itself to connecting clients.

Contains: Server’s public key, identifying information (like domain name – Common Name/Subject Alternative Name), validity period.
Signed By: For public-facing sites, a public CA (e.g., Let’s Encrypt, DigiCert). For internal services using mTLS, often signed by the same private CA that signs the client certificates.
Purpose: Allows clients to verify the server’s identity and encrypt the initial key exchange.

Client Certificates

These certificates are presented by the client to the Nginx server during the mTLS handshake to prove the client’s identity.

Contains: Client’s public key, identifying information (can be an email address, user ID, device ID, service name, etc.), validity period.
Signed By: The private CA that the Nginx server is configured to trust for client authentication.
Purpose: Allows the server to verify the client’s identity. The client must also possess the corresponding private key to complete the handshake (CertificateVerify step).

4. Generating Certificates for mTLS using OpenSSL

This section details how to use the openssl command-line tool to create a private CA and issue server and client certificates suitable for mTLS. We’ll create a simple file-based CA for demonstration purposes.

Scenario:
* CA Name: MyInternalCA
* Server Domain: mtls.example.com
* Client Identifier: [email protected]

Directory Structure (Recommended):

mtls_certs/ ├── ca/ │ ├── ca.key # CA Private Key (Keep VERY Secure) │ ├── ca.crt # CA Certificate (Publicly shareable within your trust domain) │ ├── serial # File containing the next serial number (e.g., 1000) │ └── index.txt # Database of issued certificates (initially empty) ├── server/ │ ├── server.key # Server Private Key │ ├── server.csr # Server Certificate Signing Request │ └── server.crt # Server Certificate (Signed by CA) └── client/ ├── client1.key # Client Private Key ├── client1.csr # Client Certificate Signing Request └── client1.crt # Client Certificate (Signed by CA)

Create the base directory: mkdir -p mtls_certs/{ca,server,client} and navigate into it: cd mtls_certs.

Step 1: Setting Up Your Own Certificate Authority (CA)

The CA is the root of trust for our mTLS setup.

Generating the CA Private Key

This key must be kept extremely secure. Anyone with this key can issue trusted certificates within your system.

“`bash
openssl genpkey -algorithm RSA -out ca/ca.key -aes256 -pkeyopt rsa_keygen_bits:4096

Enter a strong passphrase when prompted. Remember it!

“`

genpkey: Modern command to generate private keys.
-algorithm RSA: Specifies the RSA algorithm.
-out ca/ca.key: Output file for the private key.
-aes256: Encrypt the private key with AES-256 using a passphrase. This is crucial for security.
-pkeyopt rsa_keygen_bits:4096: Use a strong 4096-bit key length.

Generating the CA Root Certificate

This is the self-signed certificate representing the CA itself. It contains the CA’s public key.

“`bash
openssl req -x509 -new -nodes -key ca/ca.key -sha256 -days 3650 -out ca/ca.crt \
-subj “/C=US/ST=California/L=Mountain View/O=MyInternalOrg/OU=Certificate Authority/CN=MyInternalCA”

Enter the CA private key passphrase when prompted.

“`

req: Command for certificate requests and generation.
-x509: Output a self-signed certificate instead of a CSR.
-new: Generate a new certificate request (implicitly, as we provide -x509).
-nodes: Temporarily bypasses passphrase encryption for this command’s internal operations if needed, but relies on the encrypted -key. Do not use -nodes when generating the private key itself if you want it encrypted. The command uses the encrypted ca.key provided via -key. If you had generated an unencrypted CA key, -nodes here would mean no passphrase prompt for the key.
-key ca/ca.key: Use the CA private key to sign the certificate.
-sha256: Use SHA-256 for the signature hash algorithm.
-days 3650: Set the certificate validity period (10 years here).
-out ca/ca.crt: Output file for the CA certificate.
-subj "/C=.../CN=MyInternalCA": Specifies the subject information for the CA certificate. Adjust C (Country), ST (State), L (Locality), O (Organization), OU (Organizational Unit), and CN (Common Name) as needed. The CN should clearly identify the CA.

Initialize CA Database Files: (Required by the openssl ca command later)

bash touch ca/index.txt echo 1000 > ca/serial # Start serial numbers from 1000 (hex)

Step 2: Generating the Server Certificate

Now, let’s create the key and certificate for the Nginx server.

Generating the Server Private Key

“`bash
openssl genpkey -algorithm RSA -out server/server.key -pkeyopt rsa_keygen_bits:2048

No passphrase used here for simplicity in Nginx config,

but you can encrypt it and provide the passphrase in Nginx

using `ssl_password_file`. For unattended restarts, unencrypted is common.

Consider file permissions: chmod 400 server/server.key

“`

2048 bits is generally considered sufficient for server keys currently, though 4096 is stronger.
We omit -aes256 here. If you add it, Nginx will require the passphrase at startup.

Generating a Certificate Signing Request (CSR) for the Server

The CSR contains the server’s public key and identifying information, ready to be signed by the CA.

bash openssl req -new -key server/server.key -out server/server.csr \ -subj "/C=US/ST=California/L=Mountain View/O=MyWebServerOrg/OU=Web Services/CN=mtls.example.com"

-new: Generate a CSR.
-key server/server.key: Use the server’s private key.
-out server/server.csr: Output file for the CSR.
-subj ".../CN=mtls.example.com": Crucially, the Common Name (CN) must match the domain name clients will use to access your Nginx server. Alternatively, or additionally, use Subject Alternative Names (SANs) for better compatibility, especially if multiple domains or IPs are involved.

Generating a CSR with SAN (Recommended):
Create a configuration file, e.g., server_req.conf:

“`ini
[ req ]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
req_extensions = req_ext

[ dn ]
C = US
ST = California
L = Mountain View
O = MyWebServerOrg
OU = Web Services
CN = mtls.example.com

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = mtls.example.com
DNS.2 = api.example.com # Add other domains if needed
IP.1 = 192.168.1.100 # Add IP addresses if needed
“`

Then generate the CSR:

bash openssl req -new -key server/server.key -out server/server.csr -config server_req.conf

Signing the Server CSR with the CA

Use the CA key and certificate to sign the server’s CSR, creating the actual server certificate.

“`bash
openssl ca -in server/server.csr -out server/server.crt -cert ca/ca.crt -keyfile ca/ca.key \
-config /etc/ssl/openssl.cnf -days 365 -notext -md sha256 \
-extensions server_cert # Use appropriate extensions

Enter the CA private key passphrase when prompted.

“`

ca: OpenSSL command for CA operations.
-in server/server.csr: Input server CSR.
-out server/server.crt: Output signed server certificate.
-cert ca/ca.crt: The CA certificate file.
-keyfile ca/ca.key: The CA private key file.
-config /etc/ssl/openssl.cnf: Important: Specify your OpenSSL configuration file. This file defines CA policies and extensions. You might need to copy and customize the default openssl.cnf for your private CA, especially the [ ca ] and [ CA_default ] sections (pointing dir to ./ca, certificate to $dir/ca.crt, private_key to $dir/ca.key, etc.) and defining extension sections like server_cert and usr_cert.
- Self-Correction: The default openssl.cnf might not be correctly set up for a simple file-based CA or might enforce policies you don’t want. You may need a custom openssl.cnf or use -policy policy_anything if your config allows it, but defining proper extensions is better.
- Make sure your openssl.cnf (or a copy) defines the server_cert extension, typically including basicConstraints=CA:FALSE, keyUsage = digitalSignature, keyEncipherment, extendedKeyUsage = serverAuth.
-days 365: Validity period for the server certificate (1 year).
-notext: Don’t output the text form of the certificate.
-md sha256: Use SHA-256 for signing.
-extensions server_cert: Apply the certificate extensions defined in the openssl.cnf section named server_cert. This is crucial for defining the certificate’s purpose (e.g., TLS Web Server Authentication).

If successful, ca/index.txt will be updated, and ca/serial will be incremented.

Step 3: Generating the Client Certificate

The process is very similar to generating the server certificate, but the subject and extensions will differ.

Generating the Client Private Key

“`bash
openssl genpkey -algorithm RSA -out client/client1.key -pkeyopt rsa_keygen_bits:2048

Again, omitting passphrase for simplicity in client tools like curl,

but encryption is recommended for higher security contexts.

chmod 400 client/client1.key

“`

Generating a Certificate Signing Request (CSR) for the Client

The subject information should identify the client (user, device, service).

bash openssl req -new -key client/client1.key -out client/client1.csr \ -subj "/C=US/ST=California/O=MyClientOrg/OU=Client Devices/[email protected]"

The CN [email protected] uniquely identifies this client. You could use device IDs, service names, etc.

Signing the Client CSR with the CA

“`bash
openssl ca -in client/client1.csr -out client/client1.crt -cert ca/ca.crt -keyfile ca/ca.key \
-config /etc/ssl/openssl.cnf -days 365 -notext -md sha256 \
-extensions usr_cert # Use client certificate extensions

Enter the CA private key passphrase when prompted.

“`

Note the use of -extensions usr_cert. Make sure your openssl.cnf defines the usr_cert extension, typically including basicConstraints=CA:FALSE, keyUsage = digitalSignature, keyEncipherment, extendedKeyUsage = clientAuth. This explicitly marks the certificate for client authentication purposes.

Step 4: Organizing Your Certificates

You should now have the following essential files:

ca/ca.crt: The CA certificate (needed by Nginx to verify clients, and by clients to verify the server).
server/server.crt: The server certificate (configured in Nginx).
server/server.key: The server private key (configured in Nginx).
client/client1.crt: The client certificate (used by the client).
client/client1.key: The client private key (used by the client).

Keep private keys (.key files, especially ca.key) extremely secure with strict file permissions (chmod 400) and ideally store them offline or in hardware security modules (HSMs) for production CAs.

5. Configuring Nginx for Mutual TLS

With the certificates ready, we can configure Nginx to require or optionally request client certificates.

Basic TLS Configuration in Nginx (Prerequisite)

First, ensure you have a basic TLS server block configured in your Nginx configuration (e.g., within /etc/nginx/conf.d/mtls.conf or /etc/nginx/sites-available/mtls_site):

“`nginx
server {
listen 443 ssl http2; # Listen on port 443 for HTTPS, enable HTTP/2
listen [::]:443 ssl http2;

server_name mtls.example.com; # Your server's domain name

# Basic TLS settings
ssl_certificate /path/to/mtls_certs/server/server.crt; # Path to your server certificate
ssl_certificate_key /path/to/mtls_certs/server/server.key; # Path to your server private key

# Recommended TLS hardening (adjust cipher suites as needed)
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off; # Let client choose for TLSv1.3, 'on' for TLSv1.2 preference
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m; # Adjust size as needed
ssl_session_tickets off; # More secure, slight performance hit
ssl_stapling on; # Enable OCSP stapling
ssl_stapling_verify on; # Verify OCSP responses
# ssl_trusted_certificate /path/to/ca/ca.crt; # Needed for OCSP stapling if server cert issued by private CA

# Root directory and index files (example)
root /var/www/mtls.example.com;
index index.html;

location / {
    try_files $uri $uri/ =404;
    # Add other location specifics here
}

# Add mTLS directives below...

}
“`

Remember to replace /path/to/mtls_certs/ with the actual path where you stored your certificates.

Enabling Client Certificate Verification

Two key Nginx directives control mTLS:

`ssl_client_certificate`: Specifying the Trusted CA

This directive specifies the path to the CA certificate file that Nginx will use to verify incoming client certificates. Clients must present a certificate signed by this CA (or one of the CAs in the chain if intermediate CAs are used and concatenated in the file).

nginx ssl_client_certificate /path/to/mtls_certs/ca/ca.crt;

This file (ca.crt) contains the public key of your private CA. Nginx uses this public key to check the signature on the client certificate presented during the handshake.

`ssl_verify_client`: Controlling Verification Level

This directive determines whether client certificate verification is mandatory and how deep the verification goes. It has several possible values:

off (Default): Nginx does not request or verify client certificates. Standard TLS operation.
on: Mandatory mTLS. Nginx requests a client certificate. If the client doesn’t provide one, or if the provided certificate fails verification against the CA specified in ssl_client_certificate, the TLS handshake fails (usually resulting in an HTTP 400 Bad Request error with code SSL certificate error or No required SSL certificate was sent).
optional: Nginx requests a client certificate, but does not require one.
- If the client provides a valid certificate (verified against ssl_client_certificate), the connection proceeds, and Nginx variables like $ssl_client_verify will indicate success.
- If the client provides an invalid certificate (e.g., expired, wrong CA), the connection proceeds, but $ssl_client_verify will indicate failure.
- If the client provides no certificate, the connection proceeds, and $ssl_client_verify will indicate failure (NONE).
- This mode is useful when you want to grant different access levels based on whether a valid certificate was presented, perhaps falling back to other authentication methods.
optional_no_ca: Nginx requests a client certificate but does not require one and does not verify it against the ssl_client_certificate CA.
- If a client provides any certificate, Nginx will accept it (as long as it’s structurally valid), and variables like $ssl_client_s_dn will be populated. $ssl_client_verify will indicate SUCCESS, even though no CA check was done.
- If no certificate is provided, the connection proceeds, and $ssl_client_verify shows NONE.
- This mode is less common and less secure for authentication. It might be used if you only need to extract information from the certificate (like the Subject DN) without strictly validating its trust chain, relying on application-level checks instead. Use with caution.

Mandatory mTLS Configuration Example

This is the most common setup for enforcing mTLS. Only clients with a valid certificate signed by MyInternalCA will be allowed to connect.

“`nginx
server {
listen 443 ssl http2;
server_name mtls.example.com;

ssl_certificate /path/to/mtls_certs/server/server.crt;
ssl_certificate_key /path/to/mtls_certs/server/server.key;

# mTLS Configuration
ssl_client_certificate /path/to/mtls_certs/ca/ca.crt; # CA for verifying clients
ssl_verify_client on;                            # Require valid client cert

# Optional: Increase verification depth (if using intermediate CAs)
# ssl_verify_depth 2;

# ... other SSL settings ...

location / {
    # Access granted only if mTLS handshake succeeds
    # You can access client cert info via variables (see below)
    return 200 "mTLS Authentication Successful!\nClient DN: $ssl_client_s_dn\nVerify Status: $ssl_client_verify\n";
    add_header Content-Type text/plain;
}

}
“`

With this configuration:
* Clients without a certificate get a handshake error (e.g., curl error routines:ssl3_read_bytes:sslv3 alert handshake failure).
* Clients with a certificate not signed by ca.crt get a handshake error.
* Clients with a valid certificate signed by ca.crt can connect successfully.

Optional mTLS Configuration Example

This setup allows connections with or without a valid client certificate, enabling different handling based on verification status.

“`nginx
server {
listen 443 ssl http2;
server_name mtls-optional.example.com;

ssl_certificate /path/to/mtls_certs/server/server.crt;
ssl_certificate_key /path/to/mtls_certs/server/server.key;

# Optional mTLS Configuration
ssl_client_certificate /path/to/mtls_certs/ca/ca.crt;
ssl_verify_client optional; # Request cert, but don't require it

# ... other SSL settings ...

location / {
    # Check verification status
    if ($ssl_client_verify = SUCCESS) {
        # Client provided a valid cert signed by our CA
        return 200 "mTLS Authentication Successful (Optional)\nClient DN: $ssl_client_s_dn\n";
        add_header Content-Type text/plain;
    }

    if ($ssl_client_verify != SUCCESS) {
        # Client provided no cert, an invalid cert, or one from wrong CA
        # Option 1: Deny access
        # return 403 "Access Denied: Valid Client Certificate Required for this resource.";

        # Option 2: Allow limited access or redirect to login
        return 200 "Connected without valid mTLS Certificate.\nVerify Status: $ssl_client_verify\n";
        add_header Content-Type text/plain;
    }
}

}
“`

Passing Client Certificate Information to Backend Applications

When Nginx acts as a reverse proxy, you often need to pass information from the validated client certificate to your backend application (e.g., a Node.js, Python, Java, Go application) for further authorization or logging. Nginx provides several embedded variables populated after successful client certificate verification.

Key Nginx Variables:

$ssl_client_verify: The verification result:
- SUCCESS: Client presented a valid certificate verified against ssl_client_certificate.
- FAILED:reason: Client presented a certificate, but verification failed (e.g., FAILED:unable to verify the first certificate, FAILED:certificate has expired). Populated when ssl_verify_client is on or optional.
- NONE: Client did not present a certificate. Populated when ssl_verify_client is optional or optional_no_ca.
$ssl_client_s_dn: The Subject Distinguished Name (DN) of the client certificate (e.g., C=US, ST=California, O=MyClientOrg, OU=Client Devices, [email protected]).
$ssl_client_i_dn: The Issuer Distinguished Name (DN) of the client certificate (usually the DN of your CA, e.g., C=US, ST=California, L=Mountain View, O=MyInternalOrg, OU=Certificate Authority, CN=MyInternalCA).
$ssl_client_serial: The serial number of the client certificate.
$ssl_client_fingerprint: The SHA1 fingerprint of the client certificate (available in newer Nginx versions). Use with caution as SHA1 is weak. Consider extracting info from DN or using $ssl_client_cert.
$ssl_client_cert: The client certificate itself in PEM format (available since Nginx 1.11.8). This is useful if the backend needs to parse the certificate for specific extensions or perform custom validation. It can be large, so use judiciously. Needs URL-encoding if passed in headers.
$ssl_client_raw_cert: The client certificate in PEM format (available since Nginx 1.13.8). Similar to $ssl_client_cert but preserves whitespace, making it easier to parse but potentially harder to pass in headers without encoding.

Using proxy_set_header

You typically use the proxy_set_header directive within a location block configured with proxy_pass to forward these details as HTTP headers to the backend.

“`nginx
server {
# … (SSL and mTLS config as above, e.g., ssl_verify_client on) …

location /api/ {
    # Verify mTLS succeeded before proxying
    if ($ssl_client_verify != SUCCESS) {
        return 403 "Forbidden: Invalid or missing client certificate";
    }

    proxy_pass http://backend_service_pool; # Your backend upstream

    # Set headers for the backend application
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    # Pass mTLS information
    proxy_set_header X-SSL-Client-Verify $ssl_client_verify;
    proxy_set_header X-SSL-Client-DN $ssl_client_s_dn;
    proxy_set_header X-SSL-Issuer-DN $ssl_client_i_dn;
    proxy_set_header X-SSL-Client-Serial $ssl_client_serial;

    # Optionally pass the full certificate (URL-encoded recommended)
    # Requires Nginx 1.11.8+ and potentially Lua for reliable encoding
    # proxy_set_header X-SSL-Client-Cert $ssl_client_cert; # Simple but might break with newlines
    # Using lua-nginx-module for proper encoding:
    # set_by_lua_block $ssl_client_cert_esc { return ngx.escape_uri(ngx.var.ssl_client_cert) }
    # proxy_set_header X-SSL-Client-Cert $ssl_client_cert_esc;
}

}
“`

Your backend application can then read these headers (e.g., X-SSL-Client-DN) to identify the authenticated client and make authorization decisions.

Configuring Certificate Revocation

Issuing certificates is only half the story. You need a way to invalidate certificates before their expiry date if they are compromised or no longer needed. This is done via Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP).

Certificate Revocation Lists (CRLs)

A CRL is a list, signed by the CA, containing the serial numbers of all certificates issued by that CA that have been revoked and are not yet expired.

1. Generating/Updating the CRL:
When you need to revoke a certificate (e.g., client1.crt), use the openssl ca command:

“`bash

First, find the serial number (e.g., from ca/index.txt or using openssl x509)

Example: Assume client1.crt has serial 1001 (hex)

Revoke the certificate

openssl ca -revoke ca/newcerts/1001.pem -config /etc/ssl/openssl.cnf

Enter CA passphrase

Generate the updated CRL file

openssl ca -gencrl -out ca/ca.crl -config /etc/ssl/openssl.cnf

Enter CA passphrase

“`

You need to point -revoke to the certificate record, often stored in a subdirectory (like newcerts/ by default in openssl.cnf) created during signing. The path might vary based on your CA setup.
The ca/index.txt file is updated to mark the certificate as revoked (R).
The -gencrl command creates/updates the ca.crl file. This file needs to be accessible by Nginx.
You must regenerate and redistribute the CRL file every time a certificate is revoked. Clients (in this case, Nginx) need the latest CRL.

Configuring Nginx with `ssl_crl`

The ssl_crl directive tells Nginx where to find the CRL file to check against during client certificate verification.

“`nginx
server {
# … (SSL and mTLS config) …
ssl_client_certificate /path/to/mtls_certs/ca/ca.crt;
ssl_verify_client on;

# Enable CRL checking
ssl_crl /path/to/mtls_certs/ca/ca.crl;

# ... (rest of config) ...

}
“`

Now, during the mTLS handshake, after verifying the client certificate signature against the CA, Nginx will also check if the certificate’s serial number appears in the ca.crl file. If it does, the handshake will fail, even if the certificate hasn’t expired and is signed by the trusted CA.

Important Considerations for CRLs:
* Distribution: Nginx needs read access to the latest CRL file. You need a process to update this file on all Nginx instances whenever the CRL is regenerated.
* Size: CRLs can grow large if many certificates are revoked, potentially impacting performance.
* Frequency: Clients (Nginx here) only know about revocations included in the CRL version they have. There’s a delay between revocation and Nginx picking up the updated CRL.

Online Certificate Status Protocol (OCSP) – Considerations

OCSP is an alternative to CRLs where the client (Nginx) queries an OCSP responder (a dedicated server) in real-time to check the status of a specific certificate.

Nginx does not have built-in support for acting as an OCSP client to verify client certificates during the mTLS handshake.

OCSP Stapling (ssl_stapling on): This applies to the server’s certificate. Nginx periodically fetches a signed OCSP response for its own certificate from the CA’s OCSP responder and “staples” it to the TLS handshake for clients to verify. This improves client performance and privacy but doesn’t help Nginx verify client certificates via OCSP.
Verifying Client Certs with OCSP: To achieve this with Nginx, you would typically need:
- ssl_verify_client optional
- Pass the client certificate (e.g., via $ssl_client_cert) to a backend application or a sidecar proxy.
- That backend/sidecar would then need to perform the OCSP check against the appropriate OCSP responder defined in the client certificate’s Authority Information Access (AIA) extension.
- This adds complexity compared to using CRLs directly in Nginx.

For simplicity and direct Nginx support, CRLs (ssl_crl) are the standard way to handle client certificate revocation in an Nginx mTLS setup.

6. Client-Side Usage of mTLS

Clients connecting to an Nginx server configured for mTLS must provide their private key and corresponding certificate.

Using `curl`

The curl command-line tool makes it easy to test mTLS connections.

bash curl --cert /path/to/mtls_certs/client/client1.crt \ --key /path/to/mtls_certs/client/client1.key \ --cacert /path/to/mtls_certs/ca/ca.crt \ https://mtls.example.com/

--cert: Specifies the path to the client certificate file (client1.crt).
--key: Specifies the path to the client private key file (client1.key).
--cacert: Specifies the path to the CA certificate file (ca.crt). This is needed for curl to verify the server’s certificate, as it was signed by our private CA which isn’t in the system’s default trust store. If the server used a publicly trusted certificate, --cacert might not be needed for server verification, but the client cert/key are still required for mTLS authentication.

If mTLS is configured correctly on Nginx (ssl_verify_client on) and the client certificate is valid (signed by ca.crt, not expired, not revoked if using ssl_crl), this command should succeed and receive the response from Nginx (e.g., the “mTLS Authentication Successful!” message from our example).

If you omit --cert or --key, or if the certificate is invalid, curl will likely output an error like (58) unable to load client key: -8174 (SEC_ERROR_PKCS12_DECODING_PFX) or (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL or handshake failure alerts, depending on the exact failure point.

Browser Configuration (Importing Client Certificates)

Web browsers can also participate in mTLS, although configuration is manual. Users need to import their client certificate (usually bundled with the private key in a PKCS#12 / .p12 / .pfx file) into their browser’s certificate store.

1. Combine Client Key and Certificate into PKCS#12:

“`bash
openssl pkcs12 -export -out client/client1.p12 -inkey client/client1.key -in client/client1.crt -certfile ca/ca.crt

Enter an export password when prompted. This protects the .p12 file.

“`

-export: Create a PKCS#12 file.
-out client/client1.p12: Output file path.
-inkey client/client1.key: Input client private key.
-in client/client1.crt: Input client certificate.
-certfile ca/ca.crt: Include the CA certificate in the chain (optional but often helpful).

2. Import into Browser:
The user then imports the client1.p12 file into their browser:
* Chrome/Edge: Settings -> Privacy and security -> Security -> Manage certificates -> Your certificates -> Import…
* Firefox: Settings -> Privacy & Security -> Certificates -> View Certificates… -> Your Certificates -> Import…

They will need to enter the export password created in step 1.

3. Import CA Certificate (if needed):
If the server certificate is also signed by the private CA, users must also import the ca.crt file into their browser’s “Authorities” or “Trusted Root Certification Authorities” tab so the browser trusts the server.

Usage: When the user navigates to the mTLS-protected site (https://mtls.example.com), the browser will detect the server’s CertificateRequest during the handshake. It will then prompt the user to choose the appropriate client certificate (e.g., [email protected]) from their store to present to the server. If the correct certificate is chosen, the connection proceeds.

Programmatic Access (Examples)

Applications acting as clients also need to be configured with their certificate and key.

Python with `requests`

“`python
import requests

client_cert_path = ‘/path/to/mtls_certs/client/client1.crt’
client_key_path = ‘/path/to/mtls_certs/client/client1.key’
ca_cert_path = ‘/path/to/mtls_certs/ca/ca.crt’ # To verify server cert

url = ‘https://mtls.example.com/’

try:
response = requests.get(
url,
cert=(client_cert_path, client_key_path), # Tuple of cert and key path
verify=ca_cert_path # Path to CA cert for server verification
)

response.raise_for_status() # Raise an exception for bad status codes (4xx or 5xx)

print("Request successful!")
print("Status Code:", response.status_code)
print("Response Body:")
print(response.text)

except requests.exceptions.RequestException as e:
print(f”Request failed: {e}”)
except Exception as e:
print(f”An error occurred: {e}”)
“`

Go with `net/http`

“`go
package main

import (
“crypto/tls”
“crypto/x509”
“fmt”
“io/ioutil”
“net/http”
“os”
)

func main() {
clientCertPath := “/path/to/mtls_certs/client/client1.crt”
clientKeyPath := “/path/to/mtls_certs/client/client1.key”
caCertPath := “/path/to/mtls_certs/ca/ca.crt” // To verify server cert
url := “https://mtls.example.com/”

// Load client certificate and key
clientCert, err := tls.LoadX509KeyPair(clientCertPath, clientKeyPath)
if err != nil {
    fmt.Fprintf(os.Stderr, "Error loading client key pair: %v\n", err)
    os.Exit(1)
}

// Load CA certificate to verify the server
caCertBytes, err := ioutil.ReadFile(caCertPath)
if err != nil {
    fmt.Fprintf(os.Stderr, "Error reading CA certificate: %v\n", err)
    os.Exit(1)
}
caCertPool := x509.NewCertPool()
if ok := caCertPool.AppendCertsFromPEM(caCertBytes); !ok {
    fmt.Fprintf(os.Stderr, "Error appending CA certificate to pool\n")
    os.Exit(1)
}

// Configure TLS client
tlsConfig := &tls.Config{
    Certificates: []tls.Certificate{clientCert}, // Client certs
    RootCAs:      caCertPool,                  // Trust anchor for server verification
    // MinVersion:   tls.VersionTLS12, // Optional: Enforce minimum TLS version
}

// Create HTTP client with custom TLS config
client := &http.Client{
    Transport: &http.Transport{
        TLSClientConfig: tlsConfig,
    },
}

// Make the request
resp, err := client.Get(url)
if err != nil {
    fmt.Fprintf(os.Stderr, "Error making request: %v\n", err)
    os.Exit(1)
}
defer resp.Body.Close()

fmt.Println("Request successful!")
fmt.Println("Status Code:", resp.StatusCode)

body, err := ioutil.ReadAll(resp.Body)
if err != nil {
    fmt.Fprintf(os.Stderr, "Error reading response body: %v\n", err)
    os.Exit(1)
}
fmt.Println("Response Body:")
fmt.Println(string(body))

}
“`

7. Common Use Cases for mTLS

Mutual TLS provides significant security benefits in scenarios where strong, mutual authentication is required. Nginx is often the ideal place to enforce mTLS.

API Security: Securing Server-to-Server Communication
- Scenario: Backend services (microservices) communicating with each other or with internal APIs.
- Benefit: Ensures only authorized services, possessing valid client certificates, can invoke API endpoints. Prevents unauthorized access even if network access is somehow gained. Nginx can act as an API gateway or sidecar proxy enforcing mTLS.
Microservices Authentication: Establishing Trust within Internal Networks
- Scenario: In a distributed microservices architecture, services need to securely identify and authenticate each other.
- Benefit: mTLS provides a robust mechanism for service-to-service authentication within a cluster (e.g., Kubernetes). Service meshes like Istio heavily leverage mTLS (often automated) for this purpose, but Nginx can also be used, especially at the ingress or between specific service boundaries.
IoT Device Authentication: Verifying Device Identities
- Scenario: A large fleet of IoT devices needs to connect securely to a central platform or API endpoint hosted behind Nginx.
- Benefit: Each device can be provisioned with a unique client certificate. mTLS ensures that only legitimate, registered devices can connect and send data, preventing spoofing or unauthorized device access. The certificate’s Subject DN can carry the device ID.
B2B Integrations: Securing Partner Connections
- Scenario: Two different organizations need to exchange data via APIs or other web services.
- Benefit: mTLS establishes a secure, mutually authenticated channel. Each organization provides the other with client certificates for their connecting applications, ensuring only legitimate partner systems can interact.
Securing Access to Sensitive Resources: Internal Dashboards, Admin Panels
- Scenario: Protecting access to internal administration interfaces, monitoring dashboards (e.g., Grafana, Kibana), or other sensitive web applications.
- Benefit: Using mTLS adds a strong layer of authentication before users even reach the application’s login page. Only users or devices with a provisioned client certificate can access the resource. This complements traditional username/password or SSO authentication.
Zero Trust Architecture: Enforcing Identity Everywhere
- Scenario: Implementing a Zero Trust security model where trust is never assumed based on network location.
- Benefit: mTLS is a core technology for Zero Trust, verifying the identity of every connection (user, device, service) attempting to access a resource. Nginx at the edge or as an internal proxy can enforce these mTLS policies.
Mobile Application Security: Authenticating Mobile Apps to Backends
- Scenario: A mobile application needs to communicate securely with its backend API.
- Benefit: While API keys are common, mTLS offers stronger client authentication. The mobile app can have a client certificate embedded or provisioned, proving its identity to the backend API gateway (Nginx). This helps prevent reverse-engineering and unauthorized API usage by unofficial clients. Certificate pinning on the mobile app (ensuring it only talks to the legitimate server) is often used in conjunction.

8. Advanced Topics and Considerations

While powerful, implementing and managing mTLS involves several considerations:

Performance Impact: The mTLS handshake involves more steps and cryptographic operations (client certificate verification, CertificateVerify signature) than standard TLS. This adds latency to the initial connection setup. The impact is usually small for modern hardware but can be noticeable under very high connection rates. Session resumption/tickets can mitigate this for subsequent connections from the same client.
Certificate Lifecycle Management: This is arguably the biggest operational challenge with mTLS at scale.
- Issuance: Securely generating and distributing unique certificates and keys to potentially thousands or millions of clients (users, devices, services). Automation is key.
- Renewal: Certificates expire. You need automated processes to renew certificates before expiration and deploy the new ones without service interruption.
- Revocation: Efficiently revoking compromised or decommissioned certificates and ensuring Nginx (via updated CRLs or other mechanisms) honors these revocations promptly. Managing CRL distribution or implementing backend OCSP checks requires careful planning.
Scalability: Managing a PKI (even a private one) and the associated certificates for a large number of clients requires robust infrastructure and automation tools (e.g., HashiCorp Vault, CFSSL, dedicated Certificate Management solutions).
Error Handling and Debugging: Diagnosing mTLS handshake failures can be tricky.
- Nginx Error Logs: Check /var/log/nginx/error.log (or your configured path) with debug logging enabled for the ssl module (error_log /path/to/log debug; in the main context, then reload Nginx) can provide detailed handshake failure reasons. Look for messages related to client certificate, verify, handshake failed.
- OpenSSL Client Tool: Use openssl s_client for detailed debugging:
  bash openssl s_client -connect mtls.example.com:443 \ -cert /path/to/client1.crt \ -key /path/to/client1.key \ -CAfile /path/to/ca.crt \ -state -debug # Detailed output
- Common Errors: Incorrect CA specified in ssl_client_certificate, client cert expired, client cert revoked (if using CRL), client cert not signed by the trusted CA, client not sending the certificate, cipher suite mismatch.
Security Best Practices:
- Protect Private Keys: Especially the CA private key. Use strong passphrases, strict file permissions, HSMs for production.
- Secure CA Operations: Control who can issue certificates. Log all issuance and revocation actions.
- Use Strong Algorithms: Appropriate key lengths (e.g., RSA 2048+ or ECC), secure hash functions (SHA-256+).
- Short Certificate Lifetimes: Reduce the window of exposure if a key is compromised and revocation mechanisms fail or are slow. Requires robust automation for renewal.
- Proper Certificate Extensions: Use extendedKeyUsage = clientAuth for client certs and serverAuth for server certs.
Integration with Service Meshes: Tools like Istio and Linkerd automate mTLS deployment and management within Kubernetes clusters. They handle certificate issuance (often using a built-in CA or integrating with external ones like cert-manager), rotation, and enforce mTLS policies between services via sidecar proxies (like Envoy), significantly reducing the manual configuration burden compared to managing mTLS directly on Nginx for numerous internal services. Nginx might still be used at the ingress gateway, potentially terminating mTLS from external clients or participating in the mesh.
Alternatives and Complements: mTLS is not always the only or best solution.
- API Keys: Simpler to implement for basic API client identification, but less secure (static secret, easily leaked). Often used in addition to TLS, not mTLS.
- OAuth 2.0 / OpenID Connect: Standard protocols for authorization and federated identity, often used for user authentication and granting delegated access to APIs. Can be used alongside mTLS, where mTLS authenticates the client application itself, and OAuth tokens authorize specific actions on behalf of a user.
- JSON Web Tokens (JWT): Often used within OAuth flows or as standalone bearer tokens to carry identity and authorization claims. Signed or encrypted tokens provide integrity and confidentiality but don’t inherently authenticate the client sending the token in the same way mTLS does at the transport layer.

Choose mTLS when strong, cryptographic, mutual authentication at the transport layer is the primary requirement, particularly for non-interactive clients (services, devices) or high-security user access scenarios.

9. Conclusion

Mutual TLS significantly elevates the security posture of communications by demanding cryptographic proof of identity from both the client and the server. Nginx provides a robust and highly configurable platform for implementing mTLS, acting as a gatekeeper at the network edge or within internal architectures.

By configuring Nginx with directives like ssl_client_certificate and ssl_verify_client, administrators can enforce mandatory or optional client authentication based on certificates issued by a trusted private CA. This is invaluable for securing APIs, authenticating microservices and IoT devices, protecting sensitive internal resources, and building Zero Trust networks.

While the initial setup involving CA creation and certificate generation requires careful attention to detail, and ongoing certificate lifecycle management demands automation and vigilance, the enhanced security offered by mTLS is often indispensable. Understanding the handshake, Nginx configuration options, client usage, revocation mechanisms, and key use cases allows organizations to effectively leverage Nginx and mTLS to build more secure, trustworthy systems. In an era of increasing threats, mastering mTLS on platforms like Nginx is a critical skill for security-conscious engineers and administrators.

Mutual TLS (mTLS) on Nginx: A Comprehensive Guide to Configuration and Use Cases

Table of Contents

1. Understanding TLS and Mutual TLS

Recap: The Standard TLS Handshake

Introducing Mutual TLS (mTLS)

The mTLS Handshake Explained

Why Use mTLS? Key Benefits

2. Prerequisites

3. Certificate Infrastructure: The Foundation of mTLS

The Role of the Certificate Authority (CA)

Server Certificates

Client Certificates

4. Generating Certificates for mTLS using OpenSSL

Step 1: Setting Up Your Own Certificate Authority (CA)

Generating the CA Private Key

Enter a strong passphrase when prompted. Remember it!

Generating the CA Root Certificate

Enter the CA private key passphrase when prompted.

Step 2: Generating the Server Certificate

Generating the Server Private Key

No passphrase used here for simplicity in Nginx config,

but you can encrypt it and provide the passphrase in Nginx

using ssl_password_file. For unattended restarts, unencrypted is common.

Consider file permissions: chmod 400 server/server.key

Generating a Certificate Signing Request (CSR) for the Server

Signing the Server CSR with the CA

Enter the CA private key passphrase when prompted.

Step 3: Generating the Client Certificate

Generating the Client Private Key

Again, omitting passphrase for simplicity in client tools like curl,

but encryption is recommended for higher security contexts.

chmod 400 client/client1.key

Generating a Certificate Signing Request (CSR) for the Client

Signing the Client CSR with the CA

Enter the CA private key passphrase when prompted.

Step 4: Organizing Your Certificates

5. Configuring Nginx for Mutual TLS

Basic TLS Configuration in Nginx (Prerequisite)

Enabling Client Certificate Verification

ssl_client_certificate: Specifying the Trusted CA

ssl_verify_client: Controlling Verification Level

Mandatory mTLS Configuration Example

Optional mTLS Configuration Example

Passing Client Certificate Information to Backend Applications

Configuring Certificate Revocation

Certificate Revocation Lists (CRLs)

First, find the serial number (e.g., from ca/index.txt or using openssl x509)

Example: Assume client1.crt has serial 1001 (hex)

Revoke the certificate

Enter CA passphrase

Generate the updated CRL file

Enter CA passphrase

Configuring Nginx with ssl_crl

Online Certificate Status Protocol (OCSP) – Considerations

6. Client-Side Usage of mTLS

Using curl

Browser Configuration (Importing Client Certificates)

Enter an export password when prompted. This protects the .p12 file.

Programmatic Access (Examples)

Python with requests

Go with net/http

7. Common Use Cases for mTLS

8. Advanced Topics and Considerations

9. Conclusion

Leave a Comment Cancel Reply

using `ssl_password_file`. For unattended restarts, unencrypted is common.

`ssl_client_certificate`: Specifying the Trusted CA

`ssl_verify_client`: Controlling Verification Level

Configuring Nginx with `ssl_crl`

Using `curl`

Python with `requests`

Go with `net/http`