X509 Client Certificates: Secure User Authentication

TL;DR

X509 client certificates offer a strong alternative to passwords for user authentication. They work by verifying the user’s identity using a digital certificate instead of relying on something they *know* (a password). This guide explains how to set them up and use them.

1. Understanding X509 Client Certificates

An X509 client certificate is an electronic file that uniquely identifies a user or device. Think of it like a digital ID card. It’s issued by a Certificate Authority (CA) – a trusted organisation – and contains information about the user, their public key, and a digital signature verifying its authenticity.

• Public Key Infrastructure (PKI): X509 certificates are part of PKI. This means there’s a CA issuing certificates, users having their own certificate/private key pair, and servers trusting the CA.
• How it works: When a user tries to connect, the server asks for a certificate. The user provides theirs. The server checks if the certificate is valid (not expired), trusted (issued by a known CA), and matches the user attempting to access the resource.

2. Generating Certificates

You’ll need a Certificate Authority (CA). For testing, you can create your own using OpenSSL. For production, use a commercial CA.

2.1 Creating a Root CA (for Testing)

openssl genrsa -out rootCA/private.key 2048

openssl req -x509 -new -nodes -key rootCA/private.key -sha256 -days 3650 -out rootCA/rootCA.crt

2.2 Creating a Server Certificate

openssl genrsa -out server/private.key 2048

openssl req -new -key server/private.key -sha256 -out server/server.csr

openssl x509 -req -in server/server.csr -CA rootCA/rootCA.crt -CAkey rootCA/private.key -CAcreateserial -out server/server.crt -days 365 -sha256

2.3 Creating a Client Certificate

openssl genrsa -out client/private.key 2048

openssl req -new -key client/private.key -sha256 -out client/client.csr

openssl x509 -req -in client/client.csr -CA rootCA/rootCA.crt -CAkey rootCA/private.key -CAcreateserial -out client/client.crt -days 365 -sha256

3. Configuring the Server (Example: Apache)

This example uses Apache, but the principles apply to other web servers.

3.1 Enable SSL

Make sure your Apache server is configured for SSL/TLS. You’ll need a standard server certificate (created in step 2.2) already installed and working.

3.2 Configure Virtual Host for Client Certificate Authentication

Edit your virtual host configuration file (e.g., /etc/apache2/sites-available/your_site.conf).

<VirtualHost *:443>

  ServerName yourdomain.com

  SSLEngine on

  SSLCertificateFile /path/to/server/server.crt

  SSLCertificateKeyFile /path/to/server/private.key

  <Directory /var/www/your_site>

    Require all granted

    SSLVerifyClient require

    SSLVerifyDepth 1

    SSLCACertificateFile /path/to/rootCA/rootCA.crt

  </Directory>

Explanation:

• SSLVerifyClient require: Forces client certificate authentication.
• SSLVerifyDepth 1: Checks the certificate chain up to one level (the root CA).
• SSLCACertificateFile /path/to/rootCA/rootCA.crt: Specifies the path to your Root CA certificate file. This tells Apache which CAs it trusts.

3.3 Restart Apache

sudo systemctl restart apache2

4. Configuring the Client (Example: Web Browser)

Most web browsers support importing client certificates.

4.1 Import the Certificate

• Chrome/Edge: Settings > Privacy and security > Security > Manage device certificates > Import
• Firefox: Preferences > Privacy & Security > Certificates > View Certificates > Import

You’ll need to import both the client.crt *and* the client/private.key file. The browser will usually prompt you for a password if your private key is protected (which it should be!).

4.2 Test the Connection

Visit your website (https://yourdomain.com). The browser should now present your client certificate to the server during the SSL handshake.

5. Security Considerations

• Protect Private Keys: Keep client private keys secure! They are essential for authentication. Use strong passwords and consider hardware security modules (HSMs) for sensitive environments.
• Revocation: Implement a Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) to revoke compromised certificates quickly.
• CA Security: If you’re using your own CA, protect the root CA key extremely carefully. Compromise of the root CA compromises all issued certificates.