Certificate-Based Authentication

Certificate-based authentication is a cryptographic method where one party proves its identity to another by presenting a digital certificate issued by a trusted third party, the Certificate Authority (CA). Unlike password-based authentication, which relies on a shared secret, certificate authentication uses asymmetric cryptography: the certificate contains the subject's public key, and the corresponding private key is kept secret by the subject. Authentication is achieved when the verifier confirms that the certificate is valid (trusted, not expired, not revoked) and that the subject possesses the private key.

Passwords are weak: they can be guessed, stolen, or reused. Certificate-based authentication provides stronger, non-repudiable identity verification. It is resistant to phishing and man-in-the-middle attacks because the private key never leaves the owner's device. It also enables machine-to-machine authentication without user intervention, critical for IoT, servers, and automated systems.

The process can be broken into three phases: certificate issuance, certificate validation, and key confirmation.

Phase 1: Certificate Issuance - A subject generates a public-private key pair. - The subject creates a Certificate Signing Request (CSR) containing its public key and identity information (e.g., Common Name, Organization). - The CSR is sent to a CA. The CA verifies the subject's identity (via domain validation, organization validation, or extended validation). - The CA creates a digital certificate by signing the subject's public key and identity with its own private key. The certificate includes:

- Version (usually 3) - Serial number (unique per CA) - Signature algorithm (e.g., sha256WithRSAEncryption) - Issuer (the CA's distinguished name) - Validity period (notBefore and notAfter dates) - Subject (the entity's distinguished name) - Subject Public Key Info (algorithm + public key) - Extensions (e.g., Key Usage, Extended Key Usage, Subject Alternative Name) - CA's signature - The CA returns the signed certificate to the subject.

Phase 2: Certificate Validation When a client connects to a server (or vice versa), the server presents its certificate. The client performs the following checks (as defined in RFC 5280): 1. Signature Verification: The client uses the CA's public key (which it trusts because it's in its trust store) to verify the signature on the certificate. If the signature is invalid, the certificate is rejected. 2. Validity Period: The client checks the current time against the certificate's notBefore and notAfter fields. If expired or not yet valid, the certificate is rejected. 3. Trust Chain: The client builds a chain from the server's certificate up to a trusted root CA. Each intermediate CA's certificate must be signed by the next CA in the chain. The chain ends at a self-signed root certificate that the client trusts. 4. Revocation Status: The client checks whether the certificate has been revoked. This is done via Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP). CRLs are lists of revoked certificates published by the CA. OCSP allows real-time querying of a certificate's status. The OCSP responder must be reachable; if not, behavior depends on the client's configuration (soft-fail or hard-fail). 5. Key Usage and Extended Key Usage: The client verifies that the certificate's intended purposes (e.g., server authentication, client authentication) match the current use. 6. Subject and Subject Alternative Name: For TLS, the client checks that the certificate's Common Name (CN) or Subject Alternative Name (SAN) matches the server's hostname.

Phase 3: Key Confirmation After validation, the client and server perform a cryptographic exchange to confirm that the server possesses the private key corresponding to the public key in the certificate. In TLS 1.2 and earlier, this happens during the key exchange (e.g., RSA or Diffie-Hellman). In TLS 1.3, the server signs a transcript hash with its private key. If the client can verify the signature using the certificate's public key, the server is authenticated.

OpenSSL:

# Generate a private key and CSR
openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr

# Self-signed certificate (for testing)
openssl req -x509 -newkey rsa:2048 -keyout server.key -out server.crt -days 365

# Verify a certificate chain
openssl verify -CAfile ca-chain.crt server.crt

# Inspect a certificate
openssl x509 -in server.crt -text -noout

Windows:

# View certificate details
certutil -dump server.crt

# Verify chain
certutil -verify server.crt

Network Monitoring:

openssl s_client -connect example.com:443 -showcerts

A company hosts its e-commerce website on a public-facing server. To protect customer data, the server uses a TLS certificate issued by a public CA (e.g., DigiCert). The certificate is configured with the server's FQDN (e.g., www.example.com) in the SAN field. The server's private key is stored securely with file permissions 600 and optionally protected by a hardware security module (HSM). The web server (e.g., Nginx) is configured to use the certificate and private key, and to enable OCSP stapling for faster revocation checks. Performance considerations: TLS handshake adds roughly 1-2 round trips; using TLS 1.3 reduces this to 1 round trip. The server should be configured with strong cipher suites (e.g., ECDHE-RSA-AES256-GCM-SHA384) and disable weak protocols (TLS 1.0, 1.1). Common misconfiguration: forgetting to include intermediate CA certificates in the chain, causing mobile browsers to fail validation.

A large enterprise uses 802.1X for wireless network access control. Each employee's laptop has a client certificate issued by the company's internal CA (Active Directory Certificate Services). The wireless LAN controller (WLC) and RADIUS server (e.g., Network Policy Server) are configured to require EAP-TLS authentication. When a user connects to the corporate SSID, the RADIUS server presents its server certificate, and the client presents its certificate. The RADIUS server validates the client certificate against the internal CA's trust chain and checks revocation via CRL published every 24 hours. If the client certificate is revoked (e.g., employee leaves), the device cannot connect. Scale: thousands of devices; performance depends on CRL distribution (use delta CRLs) and OCSP responders. Common issue: clock skew between devices causes certificate validation failures; all devices must have accurate NTP sync.

A remote workforce connects to the corporate network via IPsec VPN using IKEv2 with certificate authentication. The VPN gateway (e.g., Cisco ASA) is configured to accept only certificates from the company's CA. Each user's laptop has a certificate issued by the CA, and the private key is stored in the Windows Certificate Store (protected by user PIN). The IKEv2 handshake uses the certificates for mutual authentication. The VPN gateway validates the client certificate and maps it to a user account for authorization. Performance: certificate validation adds ~100-200ms to the connection setup. Revocation is critical: if a laptop is stolen, the certificate must be revoked immediately to prevent unauthorized access. Common misconfiguration: not enabling certificate revocation checking on the VPN gateway, allowing revoked certificates to still authenticate.