Certificate Management in Python — Core Concepts

The anatomy of an X.509 certificate

Every TLS certificate follows the X.509 standard. The key fields:

Subject — who this certificate identifies. For a website, this is typically the domain name (e.g., CN=example.com). For internal services, it might be a service name or IP address.

Issuer — the Certificate Authority that signed this certificate, vouching for the subject’s identity.

Public key — the subject’s public encryption key. Anyone can use this to encrypt data that only the certificate holder (who has the matching private key) can decrypt.

Validity period — “not before” and “not after” dates. Outside this window, the certificate is invalid.

Subject Alternative Names (SANs) — additional identities the certificate covers. A single certificate can be valid for example.com, www.example.com, and api.example.com.

Signature — the CA’s digital stamp. Created by signing a hash of the certificate contents with the CA’s private key. Anyone can verify this using the CA’s public key.

The chain of trust

Certificates form a chain:

End-entity (leaf) certificate — your server’s certificate. Signed by an intermediate CA.

Intermediate CA certificate — signed by the root CA. Organizations use intermediates so the root’s private key can be kept offline in a vault.

Root CA certificate — self-signed (the issuer is itself). Pre-installed in operating systems and browsers. There are roughly 150 root CAs trusted by major browsers.

When your browser receives a server’s certificate, it builds the chain: leaf → intermediate → root. If the root is in the browser’s trust store, the entire chain is trusted. If any link is missing, expired, or revoked, the connection fails.

Certificate Signing Requests (CSRs)

To get a certificate from a CA, you generate a Certificate Signing Request:

1. Generate a private key (and keep it secret)
2. Create a CSR containing your public key and identity information
3. Send the CSR to the CA
4. The CA verifies your identity and signs the certificate
5. You receive the signed certificate and install it with your private key

The private key never leaves your server. The CA only sees the public key and your identity claim. This separation is fundamental to certificate security.

Mutual TLS (mTLS)

Standard TLS is one-directional: the client verifies the server’s certificate, but the server doesn’t verify the client. Mutual TLS adds client certificates — both sides authenticate each other.

This is standard practice for service-to-service communication in microservices architectures. Instead of API keys or tokens, each service presents a certificate. The receiving service verifies the certificate against a trusted internal CA.

Advantages: no shared secrets to manage, certificates carry identity information, connections are both authenticated and encrypted, revocation is centralized.

Certificate revocation

What happens when a private key is compromised before the certificate expires? The certificate must be revoked.

Certificate Revocation Lists (CRLs) are files published by CAs listing revoked certificate serial numbers. Clients download and check the list. Problem: CRLs can be large and stale.

Online Certificate Status Protocol (OCSP) lets clients query the CA in real-time: “Is certificate #12345 still valid?” More current than CRLs, but adds latency and a privacy concern (the CA sees which sites you visit).

OCSP stapling solves the privacy issue: the server periodically fetches its own OCSP response from the CA and “staples” it to the TLS handshake. The client gets freshness without contacting the CA directly.

Certificate lifetimes and renewal

Let’s Encrypt issues certificates valid for 90 days, encouraging automation. Traditional CAs offer 1-year certificates (down from 2-3 years previously — the industry trend is toward shorter lifetimes).

Shorter lifetimes reduce the window of exposure if a key is compromised, but demand reliable automation. A certificate that expires at midnight because the renewal cron job was broken causes outages that affect real users.

ACME (Automatic Certificate Management Environment) is the protocol behind Let’s Encrypt’s automation. An ACME client on your server proves domain ownership (via DNS or HTTP challenges), requests a certificate, and installs it — all without human intervention. Certbot is the most common ACME client.

Internal PKI — being your own CA

For internal services (microservices, databases, internal tools), many organizations run their own Certificate Authority rather than using public CAs:

• Full control over certificate policies and lifetimes
• No per-certificate cost
• Can issue certificates for internal hostnames that public CAs won’t sign
• Certificates are only trusted by your internal systems — they won’t work for public-facing sites

Tools like HashiCorp Vault’s PKI engine, step-ca (Smallstep), and CFSSL power internal PKI at scale.

Common misconception

“A valid certificate means the website is safe.” A certificate only proves the server controls the domain listed in the certificate. Let’s Encrypt (and other domain-validated CAs) don’t verify that the domain owner is a legitimate business. Phishing sites routinely use valid HTTPS certificates. The padlock means your connection to the server is encrypted and authenticated — not that the server is trustworthy.

The one thing to remember: Certificate management is a lifecycle — generate keys, request certificates via CSRs, monitor expiration, automate renewal, handle revocation — with the chain of trust (leaf → intermediate → root) determining whether any client trusts the connection.