cd ..

TLS / X.509 Certificate Chain Inspector — SRE Security Tooling

Stack: Node.js · node-forge · Netlify Functions | Role: Security Engineering | Focus: PKI · OCSP · Certificate Pinning
Live Demo — ssl.yaqoobahmed.com Inspect any hostname's certificate chain in real time — try your own domain.
Node.js node-forge Netlify Functions X.509 / ASN.1 OCSP / CRL SPKI Pinning SHA-1 Detection Weak Algorithm Audit

A misconfigured certificate chain is one of the most common — and most avoidable — causes of service outages for SRE teams. Missing intermediates, revoked leaves, SHA-1 deprecation, and broken SPKI pins all fail silently until they cause a P1 incident. This tool catches them before deployment.

The inspector fetches the full certificate chain from any live host, parses every certificate to its raw X.509/ASN.1 structure, performs cryptographic signature verification across the chain, checks revocation via OCSP and CRL, compares against three major trust stores, and generates SPKI hashes for certificate pinning — all in a single serverless function.

7+ Checks per Certificate
3 Trust Stores Compared
<500ms Full Chain Analysis
0 Servers to Maintain

Capabilities

Live Chain Fetch

Connects directly to any hostname:port and pulls the raw DER-encoded certificate chain from the TLS handshake — the exact chain the server presents, not a cached copy.

Cryptographic Verification

Verifies each certificate's signature using the issuer's public key. A forged or corrupted signature is caught even when metadata (expiry, issuer name) looks valid.

OCSP + CRL Revocation

Fetches OCSP responses and downloads CRL endpoints embedded in each certificate. Revoked certificates are reported with the revocation reason code.

Multi-Trust-Store Comparison

Compares root certificates against Mozilla Root Store, Apple Root CA Program, and Google Chrome Root Store. Cross-store discrepancies are flagged explicitly.

SPKI Hash Generation

Computes SHA-256(SubjectPublicKeyInfo) for every certificate in the chain — the exact format used for HTTP Public Key Pinning and Android/iOS pinning configs.

Security Audit

Flags SHA-1 signatures, RSA keys under 2048-bit, certificates expiring within 30 days, wildcard SAN mismatches, and absent Certificate Transparency SCT records.

Understanding the Certificate Chain

A TLS certificate chain has three components. A broken link anywhere in this chain breaks TLS for the end user — the inspector validates every link cryptographically, not just by reading metadata.

Cryptographic Signature Verification

Most TLS inspection tools check certificate metadata (expiry, SANs, issuer name). This tool performs actual cryptographic verification for each certificate in the chain:

  • Extracts the TBS (To-Be-Signed) certificate — the ASN.1 DER-encoded portion that was signed
  • Identifies the signature algorithm from the signatureAlgorithm field
  • Extracts the issuer's public key from the issuer certificate
  • Verifies: issuerPublicKey.verify(tbs, signature)
Why this matters for SRE: A certificate can have a valid expiry and correct issuer name but a forged or corrupted signature. Metadata-only checks miss this entirely. Cryptographic verification also catches homograph attacks in the issuer chain — an attacker may present a certificate where the issuer name matches but the signature verifies against a different key.

OCSP & CRL Revocation Checking

Revocation is the mechanism for marking a certificate invalid before expiry — used when a private key is compromised, a CA issues incorrectly, or domain ownership changes.

OCSP (Online Certificate Status Protocol)

Each certificate contains an OCSP responder URL in its Authority Information Access extension. The tool constructs a valid OCSP request (RFC 6960), sends it to the responder, parses the response, and extracts the revocation status and reason code.

CRL (Certificate Revocation List)

The CRL Distribution Points extension embeds a URL to a signed list of revoked serial numbers. The tool downloads the CRL, verifies its signature against the CA's public key, and checks whether the certificate's serial number appears in the revoked list.

Check Result Detail
OCSP Status GOOD Certificate not revoked. OCSP response signed and valid.
CRL Check NOT REVOKED Serial not present in CRL. CRL next update: 2025-02-01.
Chain Signature VERIFIED All signatures verify cryptographically across chain.
Key Strength PASS RSA 2048-bit (≥ NIST minimum through 2030).
SHA-1 Usage WARNING Root CA signed with SHA-1. Deprecated since 2017.
Mozilla Trust Store TRUSTED Root present in Mozilla NSS trust store.
Certificate Expiry VALID Expires in 287 days. No immediate action required.

SPKI Hashing for Certificate Pinning

Certificate pinning is a defense against CA compromise: instead of trusting any CA-signed certificate for a domain, the application only trusts certificates matching a specific public key hash — SHA-256(SubjectPublicKeyInfo), base64-encoded.

The tool generates SPKI hashes for every certificate in the chain. Pinning the intermediate (not the leaf) is the recommended practice — the leaf rotates annually, but the intermediate rotates every 5–10 years. Pinning the root is too broad; pinning the leaf breaks on renewal.

Output format: pin-sha256="base64encodedSPKIHash" — directly usable in an Expect-CT header, Android's network_security_config.xml, or iOS's NSAppTransportSecurity dictionary.

Failure Scenarios This Tool Catches

These are the real-world TLS failure modes that cause production incidents for SRE teams. Each is detectable before deployment.

  • 🔴
    Missing Intermediate Certificate
    Server presents leaf + root but omits the intermediate. Most browsers cache intermediates and silently succeed — mobile clients and curl do not. Results in ambiguous TLS errors that are hard to diagnose without chain inspection. This tool identifies exactly which link is absent.
  • 🔴
    Revoked Certificate in Production
    A certificate revoked after a key compromise continues to validate on expiry-only checks. OCSP/CRL revocation checking catches this. Without it, a revoked certificate passes monitoring until a browser or client rejects it in production.
  • 🟡
    SHA-1 Signature on Root or Intermediate
    SHA-1 was deprecated by major browsers in 2017. A chain containing SHA-1 signatures may be trusted today but will fail silently in future browser updates or strict clients. Flagged with the specific certificate and position in chain.
  • 🟡
    Broken SPKI Pin After Certificate Rotation
    Mobile apps and APIs with hardcoded SPKI pins break silently on certificate rotation if the new certificate uses a different key. The tool generates current SPKI hashes for all chain positions, enabling rotation planning before it causes a client outage.
  • 🔵
    Cross-Trust-Store Discrepancy
    A root CA trusted by Mozilla but not yet in Apple's store causes TLS failures on iOS while working on all other platforms. Comparing against all three major trust stores surfaces this before an iOS release uncovers it in production.

Serverless Architecture

The inspector runs as a Netlify Function — a Node.js Lambda invoked on-demand. No server to maintain, no certificate for the server itself to expire, and no idle cost. The serverless model is a natural fit: the tool does burst work (fetch, parse, verify) and returns a result in under 500ms.

Why node-forge

Node.js's built-in crypto module handles TLS but does not expose the raw certificate structure for field-level parsing. node-forge provides a full ASN.1 / X.509 parser in pure JavaScript — no native bindings, no compilation step, compatible with Netlify's serverless function sandbox.

Origin of this tool: Built after a real production incident — a deployment failed because a server sent an incomplete certificate chain (missing intermediate). The browser showed a confusing error; the curl output was ambiguous. This tool would have identified the root cause in under 30 seconds.