OpenSSL can decode any certificate, but its real power lies in letting you inspect the fine-grained details that often betray misconfigurations or security vulnerabilities.
Let’s say you have a certificate file, mycert.pem. To get a human-readable dump of its contents, you’d use:
openssl x509 -in mycert.pem -text -noout
This command tells openssl to treat mycert.pem as an x509 certificate, display its contents in text format, and suppress the standard output (-noout) so you only see the decoded information.
Here’s what you’ll see, and why it matters:
Version: This tells you which X.509 version the certificate conforms to. Most modern certificates are Version 3. A Version 1 certificate is very basic and lacks extensions, making it less flexible.
Serial Number: A unique identifier for the certificate issued by the Certificate Authority (CA). It’s crucial for the CA to revoke specific certificates. If you see duplicate serial numbers (though highly unlikely with good CA practices), it’s a major red flag.
Signature Algorithm: This shows the cryptographic hash function and public-key algorithm used to sign the certificate. For example, sha256WithRSAEncryption. A transition from older algorithms like sha1WithRSAEncryption to SHA-256 is a common security upgrade. If you see SHA-1, it’s a strong indicator that the certificate is outdated and potentially vulnerable.
Issuer: The distinguished name (DN) of the Certificate Authority that issued this certificate. This is critical for verifying the trust chain. You’ll see fields like C (Country), ST (State), L (Locality), O (Organization), and CN (Common Name). The CN here is the name of the CA itself.
Validity:
- Not Before: The date and time the certificate becomes valid.
- Not After: The date and time the certificate expires.
This is the most common reason for certificate-related errors: a certificate being used before its validity period or after it has expired. A quick check here can often resolve "certificate expired" or "certificate not yet valid" errors.
Subject: The distinguished name (DN) of the entity (e.g., a website, an organization) to whom the certificate was issued. The CN field here is the most important: it should match the hostname you are trying to connect to. If you’re accessing www.example.com and the Subject CN is www.anothersite.com, your browser will (correctly) show a security warning.
Subject Public Key Info:
- Public Key Algorithm: The algorithm used for the public key (e.g.,
rsa,ecfor elliptic curve). - Public Key: The actual public key itself, typically displayed in hexadecimal.
- Key Usage: This extension dictates what the certificate’s public key can be used for. Common values include
digitalSignature,keyEncipherment,dataEncipherment. If a certificate intended for SSL/TLS (which requireskeyEnciphermentand oftendigitalSignature) is missing these, your server won’t be able to establish a secure connection.
X509v3 Extensions: These are where much of the modern certificate’s functionality resides.
- X509v3 Key Usage: A more granular and often more critical set of flags than the basic "Key Usage" above. For SSL/TLS servers, you absolutely need
digitalSignatureandkeyEncipherment. If this is missing or incorrect, the handshake will fail. - X509v3 Extended Key Usage: Specifies the intended purposes of the public key. For web servers, you’ll typically see
TLS Web Server Authentication. For clients,TLS Web Client Authentication. If the certificate is used for a purpose not listed here (e.g., trying to use a server auth cert for client auth), it will fail. - X509v3 Subject Alternative Name (SAN): This is crucial for modern web security. It allows a single certificate to be valid for multiple hostnames. Instead of just relying on the Subject
CN, browsers check the SAN list forDNS Nameentries. Ifwww.example.comis the CN butsub.example.comis not in the SAN list, the connection tosub.example.comwill be insecure. This is the primary way to secure multiple subdomains with one certificate. - X509v3 Basic Constraints: Indicates whether the certificate is a Certificate Authority (CA) certificate and if it can be used to sign other certificates.
CA:TRUEmeans it’s a CA certificate;CA:FALSEmeans it’s an end-entity (server/client) certificate. - X509v3 CRL Distribution Points: Provides URLs where Certificate Revocation Lists (CRLs) can be fetched. If a certificate has been revoked, clients can check the CRL to detect this.
- Authority Information Access (AIA): Points to online locations (like OCSP responders) where clients can check the certificate’s status in real-time.
When debugging, you’re often looking for mismatches between the certificate’s contents and the server’s configuration or the client’s expectations. For instance, a common issue is a certificate that is valid for example.com but not www.example.com, or vice-versa, when the SAN extension is not configured correctly.
Once you’ve confirmed your certificate is valid and correctly configured, the next logical step in securing communication is understanding how to build a robust trust store that includes intermediate certificates.