GARUDACLOUD

Decoding X.509 SSL/TLS Certificates: How to Audit Expired Certs, Subjects, and Signature Keys

Published by GarudaCloud Engineering |

Comprehensive technical guide explaining decoding x.509 ssl/tls certificates: how to audit expired certs, subjects, and signature keys. Learn root concepts and implementation protocols.

Decoding X.509 SSL/TLS Certificates: How to Audit Expired Certs, Subjects, and Signature Keys

In the realm of modern internet security, X.509 certificates are the bedrock of trust, encrypting communication and verifying identities across vast networks. They are indispensable for SSL/TLS (Secure Sockets Layer/Transport Layer Security) protocols, safeguarding everything from web browsing to API interactions. As a Senior Cloud Infrastructure Architect at GarudaCloud, understanding the intricate details of X.509 certificates is not just a best practice, but a fundamental requirement for maintaining robust and secure cloud environments.

This guide provides a deep dive into the structure of X.509 certificates, their role in the TLS handshake, common formats, and how to effectively audit them using standard command-line tools like openssl. We will cover how to inspect critical fields such as validity periods, subjects, and signature keys, and offer practical troubleshooting for common certificate-related issues.

The Role of X.509 Certificates in the TLS Handshake

The TLS handshake is a complex negotiation process that establishes a secure, encrypted connection between a client (e.g., a web browser) and a server. X.509 certificates play a pivotal role in this process by enabling the client to verify the identity of the server and establish a shared secret for symmetric encryption.

Here’s a simplified overview of the server-side certificate validation during a TLS 1.2 handshake:

1. ClientHello: The client initiates the handshake by sending a ClientHello message, proposing TLS versions, cipher suites, and compression methods it supports. 2. ServerHello & Certificate: The server responds with a ServerHello (agreeing on parameters), followed by its X.509 certificate. This certificate contains the server’s public key and is signed by a trusted Certificate Authority (CA). The server may also send intermediate CA certificates if necessary to complete the chain of trust. 3. Client Verification: * The client verifies the server’s certificate against its own trust store (a collection of trusted root CA certificates). * It checks the certificate’s validity period (Not Before and Not After dates) to ensure it’s not expired or not yet valid. * It verifies the signature of the certificate using the public key of the issuing CA. If an intermediate CA signed the server’s certificate, the client verifies that intermediate CA’s certificate with its parent CA’s public key, continuing until it reaches a trusted root CA. This forms the “chain of trust.” * It checks the Subject Common Name (CN) or, more commonly, the Subject Alternative Names (SANs) in the certificate to ensure they match the domain name or IP address the client is trying to connect to. * It checks the certificate’s revocation status using Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP). 4. Key Exchange & Encryption: If all checks pass, the client uses the server’s public key (from the certificate) to encrypt a pre-master secret. Both parties then derive a shared secret key, and the subsequent communication is encrypted using this key.

A failure at any point in the client verification stage will result in a connection error, typically preventing the secure connection from being established.

Understanding X.509 Certificate Formats: PEM, DER, and PKCS#12

X.509 certificates can be represented in several formats, each serving specific purposes.

PEM (Privacy-Enhanced Mail)

PEM is the most common format for certificates and keys. It’s a text-based, Base64-encoded representation of a DER-encoded certificate. PEM files are easily readable and contain headers and footers that denote the type of data enclosed.

  • Structure: ` —–BEGIN CERTIFICATE—– MIIDezCCAyOgAwIBAgIRAMPvVw/P2J5eZ9+yN4J… —–END CERTIFICATE—– `
  • Contents: Can contain a certificate, private key, certificate signing request (CSR), or a full certificate chain.
  • File Extensions: .pem, .crt, .cer, .key.
  • Usage: Commonly used by web servers (Apache, Nginx) for certificates and private keys.

DER (Distinguished Encoding Rules)

DER is a binary encoding format for X.509 certificates. It’s a compact and non-human-readable representation.

  • Structure: Binary data.
  • Contents: Typically a single certificate or a single private key.
  • File Extensions: .der, .cer.
  • Usage: Often used in Java-based applications, for smart cards, or where space efficiency is paramount. Certificates downloaded from browsers might sometimes be in DER format.

PKCS#12 / PFX

PKCS#12 (Public Key Cryptography Standard #12), often with a .pfx or .p12 extension, is a binary format used to store a certificate, its corresponding private key, and sometimes the entire certificate chain, all in one encrypted file.

  • Structure: Binary, password-protected.
  • Contents: Certificate, private key, and potentially intermediate CA certificates.
  • File Extensions: .pfx, .p12.
  • Usage: Common on Windows systems for importing/exporting certificates with their private keys (e.g., IIS servers, user certificates).

For auditing and inspection with openssl, PEM is the most convenient format. If you have a certificate in DER or PFX format, openssl can convert it to PEM:

  • DER to PEM: `bash openssl x509 -in certificate.der -inform DER -out certificate.pem -outform PEM `
  • PKCS#12 to PEM (certificate only): `bash openssl pkcs12 -in keystore.pfx -clcerts -nokeys -out certificate.pem `
  • PKCS#12 to PEM (private key only): `bash openssl pkcs12 -in keystore.pfx -nocerts -nodes -out privatekey.pem ` (You will be prompted for the PKCS#12 password.)

Dissecting the X.509 Certificate Structure

An X.509 certificate is an ASN.1 (Abstract Syntax Notation One) structure that adheres to a specific schema. At its core, it contains a public key and identity information, all digitally signed by a CA.

The primary components of an X.509 certificate are:

1. tbsCertificate (To Be Signed Certificate): This is the main body of the certificate containing all the critical information, which is then hashed and signed by the issuer. * version: Specifies the X.509 version. Most modern certificates are Version 3 (v3), enabling critical extensions. * serialNumber: A unique positive integer assigned by the CA to each certificate it issues. * signatureAlgorithm: Identifies the algorithm used by the CA to sign this certificate (e.g., sha256WithRSAEncryption). * issuer: The Distinguished Name (DN) of the entity that signed and issued this certificate (the CA). For root certificates, the issuer and subject are typically the same. * Example: C=US, O=Let's Encrypt, CN=R3 * validity: Defines the period during which the certificate is considered valid. * notBefore: The date and time from which the certificate is valid. * notAfter: The date and time after which the certificate is no longer valid. Crucial for expiry auditing. * subject: The Distinguished Name (DN) of the entity (server, user, device) to whom the certificate is issued. * Example: CN=garudacloud.io, O=GarudaCloud, L=Jakarta, ST=DKI Jakarta, C=ID * subjectPublicKeyInfo: Contains the subject’s public key and the algorithm used with that key (e.g., RSA, ECDSA). * algorithm: The algorithm identifying the public key type. * subjectPublicKey: The actual public key data. * issuerUniqueID (v2/v3) and subjectUniqueID (v2/v3): Rarely used, provide unique identifiers in cases where names might be reused. * extensions (v3 only): A collection of additional attributes that provide enhanced functionality and constraints. These are critical for modern certificate usage.

2. signatureAlgorithm: This field is a duplicate of the tbsCertificate‘s signatureAlgorithm field, specifying the algorithm used to sign the tbsCertificate data.

3. signatureValue: The actual digital signature computed by the CA over the tbsCertificate data using its private key and the specified signature algorithm. This is what allows clients to verify the certificate’s authenticity using the CA’s public key.

Key X.509 v3 Extensions

The extensions section of a v3 certificate is where most of the critical operational information resides:

  • Subject Alternative Name (SAN): By far one of the most important extensions for web servers. It allows a single certificate to be valid for multiple hostnames (DNS names) and/or IP addresses. Modern browsers prioritize SANs over the Subject Common Name (CN). * Example: DNS:garudacloud.io, DNS:www.garudacloud.io, DNS:api.garudacloud.io
  • Basic Constraints: Dictates whether the certificate belongs to a CA and, if so, the maximum path length for certificates it can issue. * CA:TRUE indicates a CA certificate. * pathlen:N specifies the maximum number of non-self-issued intermediate certificates that can follow in a certification path.
  • Key Usage: Defines the specific cryptographic operations the public key in the certificate can be used for (e.g., Digital Signature, Key Encipherment, Cert Sign, CRL Sign).
  • Extended Key Usage (EKU): Provides more specific applications for the public key. * Server Authentication: For TLS servers. * Client Authentication: For TLS clients. * Code Signing: For signing software. * Email Protection: For S/MIME.
  • Authority Key Identifier (AKI): Identifies the public key of the CA that signed this certificate. Helps clients build the certificate chain.
  • Subject Key Identifier (SKI): A hash of the public key contained within this certificate. Useful for identifying certificates, especially where the subject name might not be unique.
  • CRL Distribution Points: URLs where Certificate Revocation Lists (CRLs) can be obtained to check if the certificate has been revoked.
  • Authority Information Access (AIA): Specifies methods for accessing information about the CA, including OCSP (Online Certificate Status Protocol) URLs for real-time revocation checks and CA Issuer URLs for fetching parent CA certificates.
  • Certificate Policies: Identifies the policies under which the certificate was issued and managed.

Auditing X.509 Certificates with openssl

The openssl command-line tool is indispensable for working with X.509 certificates. It allows you to inspect, parse, generate, and verify certificates and keys.

Prerequisites

Ensure openssl is installed on your system. Most Linux distributions, macOS, and WSL environments come with it pre-installed.

Basic Certificate Inspection

To view the human-readable details of a PEM-encoded certificate file:

`bash openssl x509 -in server.pem -text -noout `

  • -in server.pem: Specifies the input certificate file.
  • -text: Displays the certificate in human-readable text form.
  • -noout: Prevents printing of the encoded version of the certificate.

Example Output Snippet:

` Certificate: Data: Version: 3 (0x2) Serial Number: 40:c0:ed:d1:77:c3:2c:13:c2:d0:9c:8f:2c:88:51:3e Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, O = Let’s Encrypt, CN = R3 Validity Not Before: Aug 1 09:30:15 2023 GMT Not After : Oct 30 09:30:14 2023 GMT Subject: CN = garudacloud.io Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c3:f1:d2:e5:0f:7f:08:b8:30:a9:6b:d7:1e:3c: … Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Subject Alternative Name: DNS:garudacloud.io, DNS:www.garudacloud.io X509v3 Authority Key Identifier: keyid:14:21:B3:2C:5B:3F:8A:28:96:76:CD:65:E5:A2:DB:87:C7:5A:F1:C9 X509v3 Subject Key Identifier: 0A:4F:92:E3:B4:7B:A2:C9:D8:10:E0:4F:D3:5F:B6:5E:8D:1A:63:F7 … Signature Algorithm: sha256WithRSAEncryption Signature Value: 5d:11:c1:0b:96:3d:e8:14:a3:7e:92:5f:41:8c:13:62:01:21: … `

Auditing Specific Certificate Fields

1. Auditing Validity Period (Expiry)

Expired certificates are the most common cause of SSL/TLS failures. Proactive monitoring is essential.

To quickly check the Not Before and Not After dates:

`bash openssl x509 -in server.pem -dates -noout `

Output: ` notBefore=Aug 1 09:30:15 2023 GMT notAfter=Oct 30 09:30:14 2023 GMT `

To check if a certificate expires within a specific number of seconds (e.g., 30 days = 2592000 seconds):

`bash openssl x509 -in server.pem -checkend 2592000 -noout `

  • If the certificate expires within 30 days, it will output: Certificate will expire in 2591999 seconds.
  • If it expires later, it will output: Certificate will not expire in 2592000 seconds.
  • If it’s already expired, it will output: Certificate has expired on Oct 30 09:30:14 2023 GMT.

You can use this in scripts for automated expiry checks.

2. Auditing Subject and Issuer

To extract just the subject or issuer DN:

`bash openssl x509 -in server.pem -subject -noout openssl x509 -in server.pem -issuer -noout `

Output: ` subject=CN = garudacloud.io issuer=C = US, O = Let’s Encrypt, CN = R3 `

3. Auditing Subject Alternative Names (SANs)

To ensure the certificate covers all necessary domain names and IP addresses:

`bash openssl x509 -in server.pem -text -noout | grep -A 1 ‘Subject Alternative Name’ `

Output: ` X509v3 Subject Alternative Name: DNS:garudacloud.io, DNS:www.garudacloud.io `

4. Auditing Signature Algorithm and Public Key

To check the signature algorithm used by the CA and the public key details of the server:

`bash openssl x509 -in server.pem -noout -text | grep “Signature Algorithm” openssl x509 -in server.pem -pubkey -noout > publickey.pem openssl rsa -in publickey.pem -pubin -text -noout `

The grep command will show the signature algorithm (e.g., sha256WithRSAEncryption). The openssl rsa command (if it’s an RSA key) will display the modulus and exponent, which confirms the key length (e.g., 2048-bit).

To get the certificate fingerprint (useful for identification and comparison):

`bash openssl x509 -in server.pem -fingerprint -noout openssl x509 -in server.pem -sha256 -fingerprint -noout # For SHA256 fingerprint `

Output: ` SHA1 Fingerprint=0A:4F:92:E3:B4:7B:A2:C9:D8:10:E0:4F:D3:5F:B6:5E:8D:1A:63:F7 SHA256 Fingerprint=B8:C0:01:F8:7A:D3:0A:7B:7C:1E:8D:F2:F2:B5:A3:C6:B7:D4:F9:E8:A1:B2:C3:D4:E5:F6:A7:B8:C9:D0:E1:F2 `

5. Auditing Key Usage and Extended Key Usage

To ensure the certificate is authorized for its intended purpose:

`bash openssl x509 -in server.pem -noout -text | grep -E ‘Key Usage|Extended Key Usage’ -A 1 `

Output: ` X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication `

Retrieving Certificates from a Remote Server

To inspect the certificate presented by a remote server (e.g., a website):

`bash echo | openssl s_client -connect garudacloud.io:443 -showcerts 2>/dev/null | openssl x509 -text -noout `

  • echo |: Provides empty input to s_client to gracefully terminate the connection after fetching certificates.
  • openssl s_client -connect garudacloud.io:443: Connects to the specified host and port using SSL/TLS.
  • -showcerts: Displays the entire certificate chain received from the server.
  • 2>/dev/null: Suppresses error messages (e.g., “Verification error: unable to get local issuer certificate”).
  • | openssl x509 -text -noout: Pipes the certificate output to openssl x509 for parsing. If -showcerts outputs multiple certificates, this command will only parse the first one (the server’s leaf certificate). To parse all, you might need to split them or use awk.

To save the entire chain:

`bash echo | openssl s_client -connect garudacloud.io:443 -showcerts 2>/dev/null > garudacloud_chain.pem `

Advanced Troubleshooting: Common X.509 Certificate Issues

Effective certificate management goes beyond just knowing the structure; it involves proactive troubleshooting.

1. Expired Certificates

Impact: Complete service outage, browser warnings (e.g., “NET::ERR_CERT_DATE_INVALID”), API failures. Users cannot establish secure connections. Reason: The notAfter date on the certificate has passed. Troubleshooting: * Check certificate expiry: openssl x509 -in server.pem -dates -noout * Verify system time: Ensure server’s time is accurate and synchronized with NTP. Resolution: Renew the certificate from your CA before it expires. Implement automated renewal processes (e.g., ACME clients like Certbot for Let’s Encrypt).

2. Mismatched Subject/SAN

Impact: Browser warnings (e.g., “NET::ERR_CERT_COMMON_NAME_INVALID”), connection failures, particularly with modern browsers that prioritize SANs. Reason: The domain name or IP address being accessed does not match the Subject Common Name (CN) or any entry in the Subject Alternative Name (SAN) extension of the certificate. Troubleshooting: * Inspect SANs: openssl x509 -in server.pem -text -noout | grep -A 1 'Subject Alternative Name' * Check the requested hostname. Resolution: Reissue the certificate to include all necessary domain names (including www. and apex domains) in the SAN extension.

3. Untrusted Issuer / Incomplete Chain

Impact: Browser warnings (e.g., “NET::ERR_CERT_AUTHORITY_INVALID”), connections are rejected. Reason: * Incomplete Chain: The server is not sending all necessary intermediate CA certificates to the client, preventing the client from building a full chain of trust back to a root CA it trusts. * Untrusted Root: The certificate is issued by a CA whose root certificate is not present in the client’s trust store (common with self-signed certificates or enterprise CAs). Troubleshooting: * Check the certificates sent by the server: echo | openssl s_client -connect example.com:443 -showcerts 2>/dev/null * Validate the chain manually: `bash openssl verify -CAfile intermediate_ca.pem -untrusted root_ca.pem server.pem # More practically, place root_ca.pem and intermediate_ca.pem in a ca-chain.pem # openssl verify -CAfile ca-chain.pem server.pem ` Resolution: * Incomplete Chain: Configure your web server (Apache, Nginx, etc.) to send the complete certificate chain (leaf cert + all intermediate certs) to clients. The root CA certificate is usually not sent by the server, as clients are expected to have it. * Untrusted Root: If it’s a private CA, ensure the client’s trust store includes the private root CA certificate. For public CAs, verify the CA is reputable and widely trusted.

4. Revoked Certificates

Impact: Connection failures, strong security warnings. Reason: The issuing CA has explicitly marked the certificate as untrustworthy, often due to a compromise of the private key or incorrect issuance. Clients check this status via CRLs or OCSP. Troubleshooting: * Check OCSP status (if supported by the cert): `bash openssl x509 -in server.pem -ocsp_uri -noout # Then query: # openssl ocsp -issuer ca_cert.pem -cert server.pem -url -resp_text ` * Check CRL distribution points: `bash openssl x509 -in server.pem -text -noout | grep -A 2 ‘CRL Distribution Points’ # Then download the CRL and check it: # wget -O crl.pem # openssl crl -in crl.pem -text -noout ` Resolution: If a certificate is revoked, it cannot be used. Immediately replace it with a newly issued, valid certificate.

5. Incorrect Key Usage / Extended Key Usage

Impact: Application-specific failures (e.g., a certificate meant for server authentication cannot be used for code signing), security warnings. Reason: The Key Usage or Extended Key Usage (EKU) extensions do not permit the intended cryptographic operation. Troubleshooting: * Inspect Key Usage: openssl x509 -in server.pem -noout -text | grep -E 'Key Usage|Extended Key Usage' -A 1 Resolution: Reissue the certificate with the correct key usage and extended key usage extensions for its specific application.

6. Algorithm Weakness / Deprecated Ciphers

Impact: Browser warnings about insecure connections, connection failures with modern clients, reduced security posture. Reason: The certificate uses a weak hash algorithm (e.g., SHA1) or the server’s TLS configuration enables deprecated cipher suites. Troubleshooting: * Check signature algorithm: openssl x509 -in server.pem -noout -text | grep "Signature Algorithm" * Check server cipher suites (more involved, usually server config): openssl s_client -connect example.com:443 -cipher 'ALL:eNULL' -msg (look for accepted ciphers). Resolution: * Ensure certificates use strong hashing algorithms (e.g., SHA256 or SHA384). * Configure the server’s TLS settings to use only strong cipher suites and TLS 1.2 or 1.3.

Best Practices for Certificate Management

As a Senior Cloud Infrastructure Architect, managing X.509 certificates effectively is paramount:

  • Automate Everything: Leverage ACME clients (like Certbot) for Let’s Encrypt certificates to automate issuance and renewal. For enterprise CAs, explore integration with automation tools.
  • Centralized Monitoring: Implement robust monitoring solutions to track certificate expiry dates across your infrastructure. Integrate alerts with incident management systems.
  • Maintain Inventory: Keep a detailed inventory of all certificates, including their subjects, issuers, expiry dates, and associated services.
  • Secure Private Keys: Private keys are the most sensitive components. Ensure they are generated securely, stored in protected locations (e.g., HSMs, KMS), and never exposed or committed to version control.
  • Understand Your Trust Stores: Be aware of the trusted root CAs on your operating systems, browsers, and application runtimes.
  • Regular Audits: Perform periodic audits of your certificates and TLS configurations to identify potential vulnerabilities or misconfigurations.

Conclusion

X.509 certificates are the cornerstone of trust and security on the internet. A deep understanding of their structure, lifecycle, and the tools to inspect them is critical for any cloud infrastructure architect. By diligently auditing validity periods, subject information, signature keys, and maintaining a robust certificate management strategy, organizations can proactively prevent outages, mitigate security risks, and ensure a seamless, secure experience for their users. The openssl command remains an invaluable utility in this ongoing endeavor, empowering engineers to effectively manage the complex world of SSL/TLS.

#certificates #decoding #pem #security #ssl #tls #x509