OpenSSL Verify Certificate: A Comprehensive Guide

OpenSSL Certificate Verification: A Definitive Guide

The easiest way to verify an OpenSSL certificate is with the openssl verify command-line tool. This tool validates the certificate’s signature, its validity period (not before and not after dates), and its chain of trust against a trusted certificate authority (CA). The basic command is openssl verify -CAfile <path_to_ca_bundle> <path_to_certificate>. A successful verification returns “OK”. Correct and secure certificate verification involves understanding certificate chains, trust stores, revocation checks, and OpenSSL’s verification options. This guide explores these aspects.

Understanding OpenSSL Certificate Verification

Verifying an OpenSSL certificate confirms it’s authentic, trustworthy, and valid. This involves:

• Signature Verification: Ensuring the issuing CA signed the certificate, preventing tampering. Uses the CA’s public key.
• Validity Period: Checking the current date falls within the certificate’s ’notBefore’ and ’notAfter’ dates. Certificates outside this window are expired or not yet valid.
• Chain of Trust: Establishing a chain from the certificate to a trusted root CA. Each certificate signs the next.
• Revocation Status: Checking if the CA revoked the certificate before its expiration date.

These checks are vital for trust. Improper verification can lead to accepting fraudulent certificates, creating security vulnerabilities.

Using the openssl verify Command

The openssl verify command is a powerful tool for command-line certificate verification. Here’s a breakdown:

Basic Usage

The most basic command is:

openssl verify -CAfile <path_to_ca_bundle> <path_to_certificate>

• -CAfile <path_to_ca_bundle>: Specifies the path to a file containing trusted CA certificates (a ‘CA bundle’). This bundle contains the public keys of root and intermediate CAs.
• <path_to_certificate>: Specifies the certificate to verify.

Example:

openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt mycertificate.pem

This verifies mycertificate.pem against the CA certificates in /etc/ssl/certs/ca-certificates.crt.

Understanding the Output

The openssl verify command returns:

• OK: The certificate is valid and trusted.
• error at X509:: Indicates a failure. number is an error code, depth shows where the error occurred in the chain (0 is the certificate itself), and reason explains the error (e.g., ‘certificate has expired’, ‘unable to get local issuer certificate’).

Common Errors and Their Meanings

Other Useful Options

• -CApath <path_to_directory>: Specifies a directory containing PEM format CA certificates. OpenSSL scans this directory.
• -purpose <purpose>: Specifies the certificate’s purpose (e.g., sslclient, sslserver), adding extra checks.
• -showcerts: Displays the verified certificate chain.
• -verify_hostname <hostname>: (Newer OpenSSL versions) Verifies the certificate is valid for the hostname, checking the Subject Alternative Name (SAN) or Common Name (CN).
• -crl_check: Enables Certificate Revocation List (CRL) checking. Requires a CRL file or a CRL distribution point in the certificate.
• -crl_check_all: Checks revocation status for all certificates in the chain.

Example using -verify_hostname:

openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt -verify_hostname example.com mycertificate.pem

This verifies mycertificate.pem against the CA bundle and confirms it’s valid for example.com.

Certificate Chains and Intermediate Certificates

A certificate chain is a sequence starting with the certificate, followed by intermediate certificates, ending with a trusted root CA. Each certificate signs the next. The root CA certificate is self-signed.

CAs often use intermediate CAs instead of directly signing end-entity certificates, adding a security layer.

Verifying a certificate signed by an intermediate CA requires providing the intermediate certificate(s) to openssl verify via -CAfile or -CApath. The order in -CAfile usually doesn’t matter; OpenSSL should build the chain. However, older implementations might need a specific order.

‘unable to get local issuer certificate’ or ‘unable to verify first certificate’ errors usually mean a missing intermediate certificate.

You can often find intermediate certificates on the CA’s website or within the certificate itself (look for an ‘Authority Information Access’ extension).

Certificate Revocation List (CRL) Checking

Certificate Revocation Lists (CRLs) list certificates revoked by the CA before their expiration. Reasons include private key compromise, affiliation changes, or unauthorized issuance.

Checking the CRL status is important.

Enable CRL checking with openssl verify using -crl_check or -crl_check_all. Provide the CRL file, often found in the certificate’s ‘CRL Distribution Points’ extension.

openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt -crl_check -CRLfile myca.crl mycertificate.pem

This verifies mycertificate.pem against the CA bundle and checks its revocation status using myca.crl.

Note: CRL checking can be unreliable due to size and distribution issues. Online Certificate Status Protocol (OCSP) is a modern alternative. openssl verify doesn’t directly support OCSP; use other tools for OCSP stapling verification.

Alternatives to openssl verify

Besides openssl verify, other methods exist:

• Programming Languages: Python, Java, Go have libraries for certificate verification, offering fine-grained control.
• Web Browsers: Automatically verify certificates for HTTPS websites using built-in trust stores and revocation checking.
• Online Certificate Verification Tools: Websites offer online tools, but be cautious about uploading certificates to third-party servers.

Security Considerations

• Keep your CA bundle up-to-date: Regularly update to include the latest trusted root CAs and revoked certificates. Operating systems and package managers provide update mechanisms.
• Be wary of self-signed certificates: Use only in controlled environments where you explicitly trust the entity that created the certificate.
• Consider OCSP stapling: Use OCSP stapling instead of CRL checking for more reliable revocation information if possible.
• Verify certificates in your applications: Don’t rely solely on the operating system or web browser. Implement verification in applications.
• Use a consistent hostname: When using -verify_hostname, ensure the hostname matches the client’s connection hostname.

Understanding certificate verification principles and using openssl verify (or alternatives) correctly ensures certificate authenticity and trustworthiness, enhancing system and application security.

Frequently Asked Questions

What does ‘unable to get local issuer certificate’ mean?

This OpenSSL error indicates that the certificate was signed by a Certificate Authority (CA) that is not trusted by your system. The solution is to add the CA’s certificate to your trusted CA bundle or specify the path to the CA certificate using the -CAfile or -CApath options in the openssl verify command.

How do I fix ‘certificate has expired’?

The ‘certificate has expired’ error means the certificate’s validity period (defined by ’notBefore’ and ’notAfter’ dates) has ended. To resolve this, you must obtain a new, valid certificate from the issuing CA. Also, ensure your system clock is set correctly.

What is a CA bundle and why is it important?

A CA bundle is a file containing a list of trusted Certificate Authority (CA) certificates. It’s crucial for verifying the chain of trust for SSL/TLS certificates. When verifying a certificate, OpenSSL uses the CA bundle to check if the certificate was ultimately signed by a trusted CA. Keeping your CA bundle up-to-date is essential for maintaining secure connections.