Web Analytics

Authenticating Users and IoT Devices with Mutual TLS

Learn how to implement mutual TLS (mTLS) authentication for securing user and IoT device connections. Includes step-by-step certificate setup, server configuration, client implementation, and troubleshooting guidelines.

Related Content

Want to keep learning?

Subscribe to SSL.com’s newsletter, stay informed and secure.

Mutual TLS (mTLS) authentication creates a secure framework for authenticating both users and IoT devices. This guide will walk you through implementing mTLS to ensure secure bidirectional authentication between clients and servers.

Quick Start Guide

Setting up mutual TLS follows a straightforward process. First, generate the necessary server and client certificates. Next, configure your server to require client certificates. Then set up your clients with their certificates and implement proper certificate validation. Finally, test the connection to ensure everything works as expected.

One-Way and Mutual SSL/TLS Authentication

One of the defining features of the SSL/TLS protocol is its role in authenticating otherwise anonymous parties on computer networks (such as the internet). When you visit a website with a publicly trusted SSL/TLS certificate, your browser can verify that the website owner has successfully demonstrated control over that domain name to a trusted third-party certificate authority (CA), such as SSL.com. If this verification fails, then the web browser will warn you not to trust that site.

For most applications, SSL/TLS uses this sort of one-way authentication of a server to a client; an anonymous client (the web browser) negotiates an encrypted session with a web server, which presents a publicly trusted SSL/TLS certificate to identify itself during the SSL/TLS handshake:

Mutual authentication, in which both server and client in the SSL/TLS session are authenticated, is also possible and can be very useful in some circumstances. In mutual authentication, once the server is authenticated during the handshake, it will send a CertificateRequest message to the client. The client will respond by sending a certificate to the server for authentication:

Client authentication via mutual TLS requires that a certificate including the Client Authentication (1.3.6.1.5.5.7.3.2) Extended Key Usage (EKU) is installed on the client device. All of SSL.com’s Email, Client, and Document Signing certificates include client authentication.

Detailed Implementation Guide

Understanding Mutual TLS

Traditional TLS provides server authentication and encryption, but mutual TLS goes further by requiring both parties to present digital certificates. This two-way verification ensures server authenticity, enables client authentication, establishes an encrypted communication channel, and prevents man-in-the-middle attacks. The result is a highly secure connection suitable for sensitive applications and IoT device communication.

Prerequisites

Before beginning the implementation, ensure you have access to OpenSSL or a similar certificate management tool. Your web server must support TLS, and you’ll need either access to a Certificate Authority (CA) or the ability to create a private CA. Your clients must also support certificate-based authentication.

Step 1: Certificate Generation and Management

Start by generating the necessary certificates for both server and client authentication. The server certificate setup requires creating a private key, generating a certificate signing request, and signing the certificate with your CA.

# Generate server private key
openssl genrsa -out server.key 2048
?
# Create server certificate signing request (CSR)
openssl req -new -key server.key -out server.csr
?
# Sign the server certificate with your CA
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt

For client certificates, follow a similar process to create their unique credentials:

# Generate client private key
openssl genrsa -out client.key 2048
?
# Create client CSR
openssl req -new -key client.key -out client.csr
?
# Sign the client certificate
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt

Step 2: Server Configuration

The server must be configured to require and validate client certificates. Here’s an example configuration for Nginx:

server {
    listen 443 ssl;
    server_name example.com;
?
    ssl_certificate /path/to/server.crt;
    ssl_certificate_key /path/to/server.key;
    ssl_client_certificate /path/to/ca.crt;
    ssl_verify_client on;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;
}

For Apache servers, use this configuration:

<VirtualHost *:443>
    ServerName example.com
    
    SSLEngine on
    SSLCertificateFile /path/to/server.crt
    SSLCertificateKeyFile /path/to/server.key
    SSLCACertificateFile /path/to/ca.crt
    SSLVerifyClient require
    SSLVerifyDepth 1
</VirtualHost>

Step 3: Client Implementation

Browser-based authentication requires importing the client certificate into your browser’s certificate store. Each browser handles this process differently, but generally, you’ll find the option in the security or privacy settings.

For IoT devices, you’ll need to implement certificate-based authentication in your code. Here’s an example using Python’s requests library:

import requests
?
client_cert = ('client.crt', 'client.key')
ca_cert = 'ca.crt'
?
response = requests.get('https://example.com',  
                       cert=client_cert,
                       verify=ca_cert)

Step 4: Certificate Validation

Proper certificate validation is crucial for security. Your implementation should verify the certificate chain integrity, check expiration dates, validate revocation status, and ensure proper key usage. Here’s an example implementation:

from cryptography import x509
from cryptography.hazmat.backends import default_backend
?
def validate_certificate(cert_path):
    with open(cert_path, 'rb') as cert_file:
        cert_data = cert_file.read()
        cert = x509.load_pem_x509_certificate(cert_data, default_backend())
        
        if cert.not_valid_after < datetime.datetime.now():
            raise ValueError("Certificate has expired")
            
        try:
            key_usage = cert.extensions.get_extension_for_class(x509.KeyUsage)
            if not key_usage.value.digital_signature:
                raise ValueError("Certificate not valid for digital signature")
        except x509.extensions.ExtensionNotFound:
            raise ValueError("Required key usage extension not found")

Mutual Authentication Use Cases

Mutual TLS authentication can be used both to authenticate end-users and for mutual authentication of devices on a computer network.

User Authentication

Business and other organizations can distribute digital client certificates to end-users such as employees, contractors, and customers. These client certificates can be used as an authentication factor for access to corporate resources such as Wi-Fi, VPNs, and web applications. When used instead of (or in addition to) traditional username/password credentials, mutual TLS offers several security advantages:

  • Mutual TLS authentication is not vulnerable to credential theft via tactics such as phishing. Verizon’s 2020 Data Breach Investigations Report indicates that almost a quarter (22%) of data breaches are due to phishing. Phishing campaigns are out for easily harvested credentials like website login passwords, not the private keys to users’ client certificates. As a further defense against phishing, all of SSL.com’s Email, Client, and Document Signing certificates include publicly trusted S/MIME for signed and encrypted email.
  • Mutual TLS authentication cannot be compromised by poor password hygiene or brute force attacks on passwords. You can require that users create strong passwords, but how do you know they don’t use that same “secure” password on 50 different websites, or have it written on a sticky note? A 2019 Google survey indicates that 52% of users reuse passwords for multiple accounts, and 13% of users reuse the same password for all of their accounts.
  • Client certificates offer a clear chain of trust, and can be managed centrally. With mutual TLS, verification of which certificate authority (CA) issued a user’s credentials is baked directly into the authentication process. SSL.com’s online management toolsSWS API, and access to standard protocols like SCEP make issuing, renewing, and revoking these credentials a snap!

SSL.com offers multiple options for issuance and management of client certificates:

  • Individuals or organizations requiring only one or a few certificates may order Email, Client, and Document Signing certificates á la carte from SSL.com.
  • Protocols like SCEP, EST, and CMP can be used to automate client certificate enrollment and renewal for company-owned and BYO devices.
  • For customers requiring a large quantity of certificates, wholesale discounts are available through our Reseller and Volume Purchasing Program.

Security Best Practices

Strong security requires more than just implementing mTLS:

  • Implement automated certificate rotation to ensure certificates are regularly updated
  • Maintain a certificate revocation list to quickly invalidate compromised certificates
  • Use strong key sizes of at least 2048 bits for RSA keys
  • Configure your servers to only accept secure TLS versions and strong cipher suites

Your client security strategy should include protecting private keys with strong access controls and implementing certificate pinning. Regular security audits will help maintain the system’s integrity over time.

Troubleshooting Common Issues

Certificate Chain Issues

When implementing mTLS, you may encounter certificate chain issues. These typically stem from:

  • Incomplete certificate chains
  • Improperly installed intermediate certificates

To resolve these issues:

  • Verify that your trust anchor configuration is correct
  • Ensure all necessary certificates are present

Connection Problems

Connection problems often relate to:

  • Firewall settings blocking TLS traffic
  • Incorrect certificate permissions

To troubleshoot:

  • Check that your certificates are properly named
  • Ensure they are matched to their intended use

Performance Considerations

Performance considerations become important at scale. To optimize performance:

  • Implement session caching to reduce the overhead of repeated handshakes
  • Choose efficient cipher suites that balance security and performance
  • Monitor your certificate validation process to ensure it’s not creating unnecessary overhead

Conclusion

Mutual TLS provides robust security for both user and IoT device authentication. This guide has walked you through the essential steps of implementation, from certificate generation to troubleshooting common issues. By following these guidelines and maintaining good security practices, you can create a secure authentication system that protects against network-based attacks while ensuring reliable client identification.

Contact an SSL.com Specialist about Mutual TLS and the IoT

Stay Informed and Secure

SSL.com is a global leader in cybersecurity, PKI and digital certificates. Sign up to receive the latest industry news, tips, and product announcements from SSL.com and stay informed of the latest changes about digital identity and encryption that can impact and enhance your life.

We’d love your feedback

Take our survey and let us know your thoughts on your recent purchase.