PKI and digital certificates: CAs, chains of trust and TLS

The problem PKI solves

Public key cryptography lets anyone encrypt data or check a signature using a public key, while only the owner holds the matching private key. The weak point is trust: when your browser receives a public key claiming to be from your bank, how does it know an attacker did not substitute their own? Public key infrastructure (PKI) answers this with digital certificates signed by trusted third parties called certificate authorities (CAs).

A certificate (in the X.509 format) binds a public key to an identity. Key fields include the subject, the Subject Alternative Names (SANs, the domain names it covers), the issuer, the validity dates, the public key, allowed uses, and the CA's signature over all of it.

Chains of trust

Operating systems and browsers ship with a trust store of root CA certificates. Roots are kept offline and rarely used; they sign intermediate CAs, which issue certificates to websites. When you connect, the server sends its certificate plus the intermediates. The browser checks each signature up to a trusted root, confirms the name matches the site, the dates are valid and the certificate has not been revoked.

A very common misconfiguration is a server that sends only its own certificate and not the intermediate. Some browsers cope by fetching it, but other clients (scripts, IoT devices, mobile apps) fail with "unable to get local issuer certificate".

Validation types and private PKI

Organisations often run a private CA for internal use. Its root is pushed to company devices so they trust internal certificates, but it is not trusted by the public internet.

Issuing, expiring and revoking

To get a certificate you generate a key pair, create a certificate signing request (CSR) containing the public key and names, and send it to the CA. The private key never leaves your server.

openssl req -new -newkey rsa:3072 -nodes -keyout example.key -out example.csr -subj "/CN=www.example.com" -addext "subjectAltName=DNS:www.example.com,DNS:example.com"
openssl x509 -in example.crt -noout -subject -issuer -dates -ext subjectAltName
openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts

Public TLS certificate lifetimes are getting shorter. Industry rules agreed by the CA/Browser Forum reduce the maximum lifetime in stages, from 398 days to 200 days in 2026 and down to 47 days by 2029. Manual renewal does not scale at that pace, so automation using the ACME protocol is now the normal approach.

If a private key is stolen, the certificate should be revoked. Clients learn about revocation through certificate revocation lists (CRLs) or the Online Certificate Status Protocol (OCSP). Revocation checking has always been patchy in practice, which is one reason short lifetimes are favoured.

Tip: expired certificates cause real outages. Keep an inventory of every certificate, automate renewal, and alert well before expiry. See the certificate expiry project for a scripted check.

Real-world example: an expired certificate at a clinic

On a Monday morning, staff at a fictional health clinic cannot open the online booking portal; browsers show a warning that the connection is not private. The certificate on the portal expired over the weekend because it had been renewed by hand once a year and the person who did it had left. The IT supplier issues a new certificate from the clinic's public certificate authority, installs the full chain and confirms that browsers now trust it. To stop a repeat, they switch to automatic renewal using the ACME protocol and add expiry monitoring that alerts 30 days ahead.