What is PKI (public key infrastructure)

Public key infrastructure — PKI — is the system that lets two parties on the internet verify each other's identities using cryptographic certificates. When your browser connects to a bank's website, PKI is what tells it "this server really is the bank."

The mechanism uses asymmetric cryptography: a public key that anyone can see, and a private key that only the owner has. PKI is the chain of signatures and trust that makes those keys meaningful.

How PKI is structured

Three layers, top to bottom:

1. Root certificate authority. A small number of organisations (DigiCert, Let's Encrypt, Sectigo, etc.) hold root keys that browsers and operating systems trust by default. Roots sign intermediate certificates.
2. Intermediate CAs. Day-to-day signing happens with intermediates. They sign end-entity certificates. If an intermediate is compromised, only certs signed by it are affected; the root stays safe (offline, ideally on hardware).
3. End-entity certificates. What gets issued to actual servers and devices. Has a hostname, an expiry, and a chain back up to a trusted root.

When you visit a site, your browser checks the certificate chain: end-entity → intermediate → root. If every signature validates and the root is in the trust store, the chain is good. If anything fails, the browser warns you.

What can go wrong

Several common failure modes:

• Compromised intermediate. If a CA's intermediate key leaks, attackers can issue certs for any domain. This has happened to commercial CAs. Browsers respond by distrusting the affected intermediate.
• Compromised root. Catastrophic. A trusted root key in attacker hands means they can sign anything. Roots are kept offline on hardware tokens precisely to prevent this.
• Misissued certificate. A CA wrongly issues a cert for a domain to someone who shouldn't have one. Certificate Transparency logs make this detectable but not preventable.

Each of these requires the broken cert to be revoked. Revocation is famously slow — see the short-lived certificates post for why.

PKI inside a VPN

Your VPN provider runs its own PKI. The structure is similar:

• A root CA (offline, on hardware) that signs intermediates.
• An intermediate CA (online) that signs server and client certificates.
• End-entity certs for each VPN server, and each authenticated user.

Servers prove their identity to clients via these certs. Clients prove their identity (and authorisation) the same way. It's the same trust mechanism HTTPS uses, applied to the VPN session.

Fexyn runs a HashiCorp Vault PKI. Root offline on hardware tokens. Intermediate online, signing both server and client certs. Issued cert TTL is 24 hours — long enough that a single sleep/resume doesn't trigger renewal, short enough that a stolen credential expires before most attackers can use it.

Compare this to consumer VPNs that issue 12-month or longer client certs. If one of those leaks, it's valid until manual revocation completes — and revocation propagation is unreliable. 24-hour certs make that problem self-correcting.

What this means for users

You don't interact with the PKI directly; the VPN client handles it. But the PKI's design determines blast radius if something goes wrong. A leaked Fexyn cert is invalid in 24 hours. A leaked cert from a competitor running 12-month rotations is a year-long problem.

Read more in Short-lived certificates and the security overview.

Try Fexyn free for 7 days — your first cert lives 24 hours.