PKI fundamentals — the cryptography the firewall operator must understand

Every TLS connection the firewall makes — the GUI, the API, the syslog target, the RADIUS server, the LDAP server, the ACME endpoint — relies on a chain of certificates. The firewall operator who cannot read a certificate, who cannot trace a chain, and who cannot tell a root from an intermediate from a leaf will, at some point, trust a certificate they should not have trusted.

This lesson covers the cryptography at the depth the firewall operator needs: what asymmetric cryptography gives a certificate authority, what fields an X.509 certificate carries, how a chain proves trust, and the failure modes that show up when an operator mistrusts the wrong certificate.

Asymmetric cryptography in one paragraph

A certificate authority works because of asymmetric cryptography. A key pair has two halves: a private key the owner keeps secret, and a public key the owner distributes. Anything encrypted with the public key can only be decrypted with the private key, and anything signed with the private key can be verified with the public key. A certificate authority owns a private key and uses it to sign other certificates. The signature says “I, the CA, attest that this public key belongs to this name”. Anyone who trusts the CA’s public key can verify the signature.

CA private key  → signs leaf certificate's identity
CA public key   → distributed in CA certificate, used by verifiers
Leaf public key → presented by the server during TLS handshake
Leaf private key → used by the server to prove identity

The chain of trust is therefore: trust the CA, verify the CA signed this leaf, trust the leaf because the CA did.

What is in an X.509 certificate?

A certificate is a signed statement that binds a public key to a name. The structure is defined by RFC 5280. The fields the firewall operator actually reads:

The Subject Alternative Name (SAN) extension is the field that matters for hostname validation. The Common Name (CN) is no longer trusted by modern browsers and clients for hostname matching. A certificate without a SAN is broken.

Subject: CN = fw.example.com
Subject Alternative Name:
  DNS:fw.example.com
  DNS:fw.internal.example.com
Issuer: O = Example Internal CA, CN = Example Internal Root
Validity:
  notBefore: Aug  1 00:00:00 2026 GMT
  notAfter:  Aug  1 00:00:00 2027 GMT
Public Key: RSA 2048 bits
Signature: sha256WithRSAEncryption

$ openssl x509 -in /etc/ssl/certs/fw.example.com.crt -noout -subject -issuer -dates -ext subjectAltName,basicConstraints,keyUsage

subject=CN = fw.example.com
issuer=O = Example Internal CA, CN = Example Internal Root
notBefore=Aug  1 00:00:00 2026 GMT
notAfter=Aug  1 00:00:00 2027 GMT
X509v3 extensions:
X509v3 Basic Constraints: critical
  CA:FALSE
X509v3 Key Usage: critical
  Digital Signature, Key Encipherment
X509v3 Subject Alternative Name:
  DNS:fw.example.com, DNS:fw.internal.example.com

The chain of trust

A certificate is signed by something. The “something” is either a root CA or an intermediate CA. An intermediate CA is itself a certificate signed by another CA, eventually reaching a root. The root is self-signed — the root signs its own certificate.

Root CA (self-signed)
  └── Intermediate CA (signed by Root)
        └── Leaf certificate (signed by Intermediate)

The verifier’s trust store holds root certificates. When the firewall connects to a server and receives a leaf certificate, it walks up the chain: the leaf is signed by the intermediate, the intermediate is signed by the root, the root is in the trust store. If the chain completes and every signature verifies, the leaf is trusted.

A leaf certificate that chains to a root not in the trust store is untrusted. The green padlock in the browser depends on the chain completing to a root the browser trusts — not on the certificate being “valid”.

$ openssl s_client -connect fw.example.com:443 -servername fw.example.com -showcerts </dev/null 2>/dev/null | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -print_certs -noout

subject=/CN=fw.example.com
issuer=/O=Example Internal CA/CN=Example Internal Intermediate
subject=/O=Example Internal CA/CN=Example Internal Intermediate
issuer=/O=Example Internal CA/CN=Example Internal Root
subject=/O=Example Internal CA/CN=Example Internal Root
issuer=/O=Example Internal CA/CN=Example Internal Root

What extensions actually do

The extensions in a certificate are not decoration. They are constraints the issuer is asserting about the certificate.

• Basic Constraints (CA:TRUE/FALSE): CA:TRUE means this certificate is allowed to sign other certificates. CA:FALSE means it is a leaf and may not sign anything. A leaf with CA:TRUE is broken.
• Key Usage / Extended Key Usage: what the certificate is permitted to be used for. Digital Signature and Key Encipherment are normal for a TLS leaf. Code Signing is different. An intermediate needs Key Cert Sign and CRL Sign.
• Subject Alternative Name (SAN): the names the certificate is valid for. A TLS leaf with no SAN is invalid; the verifier refuses to match it to a hostname.
• CRL Distribution Points / Authority Information Access: how to find out whether the certificate has been revoked. Modern verifiers prefer OCSP (the AIA OCSP endpoint); older systems fall back to CRL.

Roots, intermediates, and the production rationale

Why have intermediates at all? Two reasons.

Limiting exposure of the root. If the root private key is ever compromised, every certificate in the entire PKI must be revoked and re-issued. The root should be kept offline, in a vault, and used only to sign intermediate CAs. The intermediates are online and do the day-to-day signing.

Separation of concerns. Different intermediate CAs can issue certificates for different purposes (TLS leaf, code signing, S/MIME, IPsec), with different validity windows and different revocation policies. The root policy is the umbrella; the intermediate policy is the operational reality.

A firewall operator who runs an internal PKI should run at least one intermediate. A single-tier “root signs everything” PKI is operationally fragile.

PKI failure modes in production

Five failure modes appear repeatedly.

1. Chain does not complete. The server sent the leaf but not the intermediate. The verifier does not have the intermediate in its trust store (because intermediates are not normally in trust stores). Result: untrusted. Fix: server must send the full chain, or the intermediate must be distributed to verifiers.

2. Certificate expired. The validity window has closed. Modern verifiers refuse to connect. Result: hard outage. Fix: monitor expiry, renew before the window closes.

3. Hostname does not match. The certificate is valid but the SAN does not include the hostname the client used. Result: untrusted. Fix: re-issue with the correct SAN.

4. Wrong trust anchor. The certificate chains to a root the verifier does not trust. The operator installs the leaf into the trust store, which does nothing — the trust store is for roots, not leaves. Fix: install the root (or the intermediate, depending on the verifier).

5. Revoked certificate. The CA revoked the certificate (compromised key, replaced, etc.) and the verifier checks CRL or OCSP. Result: untrusted. Fix: re-issue; the old certificate is permanently dead.

Summary

• PKI relies on asymmetric cryptography: a CA’s private key signs certificates, the CA’s public key verifies them.
• An X.509 certificate binds a public key to a name via the Subject and SAN, signed by an Issuer.
• Trust is rooted in the verifier’s trust store. The chain must walk from the leaf to a root the verifier already trusts.
• Run an intermediate CA, keep the root offline. Compromise of the root key is total compromise of the PKI.
• Verify chains with openssl s_client -showcerts and read certificates with openssl x509 instead of trusting a padlock.