Cryptography / Infrastructure

Public Key Infrastructure (PKI) & X.509 Certificates

Public Key Infrastructure (PKI) binds public keys to an identifier vetted by a trusted Certificate Authority (CA), using digital signatures. What that identifier actually proves depends on the validation level: the overwhelming majority of publicly-trusted TLS certificates today are Domain Validated (DV), meaning the CA confirmed the applicant controls the domain name — not that it verified any real-world organizational identity behind it. Organization Validated (OV) and Extended Validation (EV) certificates additionally vet a legal entity, but DV is the default for most web traffic. X.509 certificates provide the trust anchor for TLS, S/MIME, code signing, and mutual TLS (mTLS) identity verification across open networks.

Core PKI Components & Trust Model

PKI commonly uses a hierarchy where trusted Root CAs issue certificates to Intermediate CAs, which in turn issue leaf or end-entity certificates. Publicly trusted TLS subscriber certificates are increasingly short-lived under CA/Browser Forum policy; S/MIME, code-signing, private-PKI, and other end-entity certificate profiles can use different validity periods.

PKI trust hierarchy: Root CA delegates signing authority to Intermediate CAs

What “Validating a Certificate” Actually Means

“Certificate validation” bundles together several distinct checks that a client must perform, and a failure in any one of them is a different failure mode from the others:

1. Path Building: Given a leaf certificate, locate a chain of intermediate certificates connecting it to a Root CA already present in the local trust store. A server that omits a required intermediate, or presents intermediates out of order, can cause path building to fail even when a valid chain exists in principle — this is why “include the full intermediate chain” is standard TLS deployment advice.
2. Path Validation: For the chain path building found, cryptographically verify each signature (leaf signed by intermediate, intermediate signed by root), confirm each certificate is within its validity window, and check policy constraints (basic constraints, name constraints, key usage/EKU) at every hop per RFC 5280 §6. This confirms the chain is cryptographically well-formed and policy-compliant — it does not yet confirm the certificate belongs to the host the client is talking to.
3. Endpoint (Hostname) Verification: Separately from chain validation, the client must confirm the hostname it intended to connect to appears in the certificate’s Subject Alternative Name (SAN) field, per RFC 9525 (which obsoletes the earlier RFC 6125). This step is easy to omit in custom TLS client code (hence a long history of vulnerabilities where a valid, trusted certificate for any domain was accepted for connections to every domain) and is worth calling out explicitly: a chain can pass path validation perfectly while still being the wrong certificate for the connection, if hostname verification isn’t performed.
4. Revocation Checking: Query CRL or OCSP (see below) to confirm the certificate hasn’t been revoked since issuance — a check that is best-effort in most real deployments (see the Trust Store row above) rather than a hard requirement.
5. Certificate Transparency: Separately, confirm the certificate carries the SCTs a given browser vendor’s policy requires (see Certificate Transparency) — a detection mechanism for rogue issuance, not part of RFC 5280 path validation itself.

Treating these as one monolithic “is this cert valid?” check, rather than as separable phases each with its own failure mode, is a common source of both security bugs (skipped hostname verification) and operational bugs (misdiagnosing a path-building failure as a revocation problem, or vice versa).

Anatomy of an X.509 v3 Certificate (RFC 5280)

Specified in RFC 5280, an X.509 v3 certificate structures identity metadata into standard fields signed by a CA:

Certificate Lifecycle & Automated Issuance (ACME & ARI)

Managing short-lived certificates at scale requires automated enrollment via the Automated Certificate Management Environment (ACME / RFC 8555) protocol:

Automated ACME lifecycle: domain validation, issuance, renewal, and a layered revocation path whose coverage, freshness, and failure behavior depend on the relying party

Certificate Lifetime Shrinkage Timeline

Publicly-trusted TLS subscriber certificate lifetime evolution: transition from multi-year (825-day) static certificates to automated short-lived certificates, tightening from 200 days today to a 47-day maximum by March 2029

ACME Renewal Information (ARI, RFC 9773)

To support these shrinking (200-day today, 47-day by 2029) certificate lifetimes without outages, ACME Renewal Information (ARI) (RFC 9773, published as a Proposed Standard in 2025) allows CAs to suggest optimal renewal windows to automated agents dynamically before expiration.

Revocation in Practice: Why It’s Not Uniformly Reliable

Revocation exists to handle the case a certificate’s validity period can’t: a key compromised, or a certificate mis-issued, before it would naturally expire. In practice, no single revocation mechanism gives every client a fast, reliable answer, which is exactly why the “best-effort” framing appears repeatedly on this page rather than a flat guarantee.

• CRLs (Certificate Revocation Lists): A CA-signed, periodically-updated list of revoked certificate serial numbers. Clients that check CRLs must fetch and parse a list that can grow to significant size for a large CA, and the list is only as fresh as its last publication — a certificate revoked minutes ago may not appear until the next scheduled CRL update.
• OCSP (Online Certificate Status Protocol): A real-time, per-certificate query to the CA (or its OCSP responder) asking “is this serial number revoked?” This avoids downloading a whole list, but introduces its own problems: it leaks browsing metadata to the CA (which domains a client is visiting), it adds a network round-trip (and a failure point) to every connection, and — critically — most browsers soft-fail when the OCSP responder is unreachable, meaning an attacker who can block the OCSP request (a common capability for someone already in a position to MitM a connection) can often make a revoked certificate appear valid simply by preventing the revocation check from completing.
• OCSP Stapling: The server itself periodically fetches a signed OCSP response from the CA and “staples” it to the TLS handshake, so the client does not need its own round-trip to the CA. This fixes the metadata-leak and latency problems, but only works if the server keeps its stapled response current. What happens on a missing or expired staple is not uniform — it varies by client and policy. An ordinary client with no specific expectation typically proceeds anyway, while a certificate carrying the TLS Feature extension (“Must-Staple,” RFC 7633) requests stapling support. A server implementing that feature is required to provide the requested status response, but RFC 7633 says a client may reject a connection when the server fails to do so; actual hard-fail behavior depends on the client and deployment profile.
• Short-lived certificates as a revocation substitute: As the CA/Browser Forum’s shrinking maximum-lifetime rules (200 days now, 47 days by 2029) take effect, some deployments increasingly treat “the certificate will expire soon anyway” as a partial substitute for timely revocation — a compromised key is only usable until natural expiry, bounding the exposure window without needing every client to check revocation status correctly. This reduces reliance on revocation checking without eliminating the need for it (a 47-day exposure window is still a real window).
• Browser-specific mechanisms: Beyond CRL/OCSP, some browsers maintain their own aggregated revocation data pushed directly to the client. Chrome’s CRLSet and Firefox’s legacy OneCRL are curated subsets — they cover only a hand-picked set of “important” revocations, not every revoked certificate. Firefox’s newer CRLite is different in kind: Mozilla compresses the revocation status of essentially all certificates from CT-logged, enrolled CAs into a compact local filter (published at roughly 300 KB/day), aiming for comprehensive coverage rather than a curated subset — see Mozilla’s CRLite announcement. All of these trade some combination of coverage, freshness, or storage cost for a fast, always-available local check that doesn’t depend on a live network request to the CA at connection time.

The practical upshot: revocation checking is a layered, best-effort defense with real gaps at every layer (staleness, soft-fail, partial coverage), not a single reliable mechanism — which is also why shrinking certificate lifetimes are treated as a complementary mitigation, not a replacement for revocation.

Certificate Formats & OpenSSL Encoding Conversions

X.509 certificates and private keys show up under five commonly seen format markers — though these aren’t five instances of one consistent category: PEM and DER are encodings (ASCII-armored vs. binary ASN.1), PKCS#7 and PKCS#12 are containers (bundling multiple objects together), and .crt/.cer is an ambiguous file extension that says nothing about the underlying encoding on its own:

OpenSSL CLI Reference Cheat Sheet

Certificate & Public Key Pinning (Mobile & Native App Defense)

Standard PKI path validation trusts any applicable pre-installed Root CA in an OS trust store — meaning any root whose path constraints and policies permit issuance for your domain and certificate purpose — to issue certificates for your domain. The exact count of trusted roots varies by platform and OS version, but is commonly on the order of 100+; not every one of those roots is actually unconstrained for every domain, since name-constrained or policy-constrained intermediates can narrow which roots can issue for a given name in practice. Certificate Pinning (or Public Key Pinning) adds an additional restriction on top of standard X.509 path validation and hostname verification — it does not replace or skip them. A pinned connection still must pass ordinary chain building, signature verification, and name checking; pinning then further requires that a specific, pre-declared public key hash also appear in the chain, narrowing acceptance from “any trusted Root CA in the OS store” down to a pre-declared set (often the server’s own SPKI plus one or more backup pins, not necessarily a single key).

Pinning Target Strategies

Pinning Scope: Public CA vs. Private CA Deployment

Certificate pinning applies to both Public PKI and Private PKI environments, addressing distinct threat vectors:

• Public CAs (e.g. Let’s Encrypt, DigiCert, Sectigo): Mobile OS trust stores pre-install a large number of commercial Root CAs — the exact count is platform- and version-specific. If a single Public CA is compromised or coerced into issuing a fake certificate for your domain (api.example.com), standard TLS path validation accepts the forged cert. Pinning your server’s SPKI key hash (plus at least one backup pin) forces native apps to reject any chain that doesn’t present one of the pinned keys, regardless of which of those Root CAs signed it — narrowing trust to the pinned set rather than to a single key.
• Private CAs (Internal / Enterprise PKI): Used inside corporate networks, mTLS microservice meshes, and IoT fleets (e.g. HashiCorp Vault PKI, AWS Private CA). Pinning the Private CA Root/Intermediate key inside native apps prevents corporate SSL decryption proxies (e.g. Zscaler, Charles Proxy) or user-installed custom root certificates from eavesdropping on enterprise API traffic.

Security Risks & Threat Vectors of Pinning

While pinning protects network transport against rogue CAs, it introduces significant security trade-offs and threat vectors:

Native Mobile Pinning Configuration Examples

Android Network Security Config (res/xml/network_security_config.xml)

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-01-01">
            <!-- Primary Pin: SHA-256 hash of SubjectPublicKeyInfo -->
            <pin digest="SHA-256">cUPcScTJnGGxEvWYspA5vF9VPol17BskT1hB64GVAHw=</pin>
            <!-- Backup Disaster Recovery Pin (Cold Storage Key) -->
            <pin digest="SHA-256">M8HwxWaMH1ECCkg4AgWFiUsS55TF0bT3A89LBFJgMqU=</pin>
        </pin-set>
    </domain-config>
</network-security-config>

iOS Network Transport Security (Info.plist)

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSPinnedDomains</key>
    <dict>
        <key>api.example.com</key>
        <dict>
            <key>NSIncludesSubdomains</key>
            <true/>
            <key>NSPinnedCAIdentities</key>
            <array>
                <dict>
                    <key>SPKI-SHA256-BASE64</key>
                    <string>cUPcScTJnGGxEvWYspA5vF9VPol17BskT1hB64GVAHw=</string>
                </dict>
                <dict>
                    <key>SPKI-SHA256-BASE64</key>
                    <string>M8HwxWaMH1ECCkg4AgWFiUsS55TF0bT3A89LBFJgMqU=</string>
                </dict>
            </array>
        </dict>
    </dict>
</dict>

Post-Quantum Hybrid Certificates

As PKI migrates toward quantum safety, Certificate Authorities and standards groups (IETF LAMPS working group) are standardizing Post-Quantum Hybrid Certificates:

• Dual-Algorithm / Composite Certificates (draft-ietf-lamps-pq-composite-sigs): Binds both a classical public key (e.g. RSA-3072 or ECDSA P-256) and a post-quantum public key (e.g. FIPS 204 ML-DSA) under a single composite algorithm identifier.
• Interoperability & Transition Mechanics: Non-upgraded legacy clients cannot parse or fall back to verifying only the classical signature component of a composite certificate, as they do not recognize the composite algorithm OID (the IETF draft explicitly notes that upgraded/non-upgraded interoperability is not directly provided by composite signatures). Upgraded/non-upgraded interoperability is therefore achieved through parallel certificates (dual X.509 certificate chains) or negotiated protocol parameters rather than in-place composite fallback.

Primary references

• RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile — IETF RFC 5280
• RFC 8555: Automatic Certificate Management Environment (ACME) — IETF RFC 8555
• RFC 9773: ACME Renewal Information (ARI) Extension — IETF RFC 9773
• RFC 7469: Public Key Pinning Extension for HTTP (Proposed Standard) — RFC Editor: RFC 7469
• CA/Browser Forum Baseline Requirements: Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates — CA/Browser Forum BRs
• Android Network Security Config: Network Security Configuration Pinning Guidance — Android Developer Security Config
• Apple PKI Guidance: Identity & Public Key Pinning Guidance — Apple Developer News
• IETF Composite Signatures Draft: Composite Signatures For Use in X.509 Public Key Infrastructure — draft-ietf-lamps-pq-composite-sigs