Short-lived VPN certificates: why 24 hours beats 12 months

A VPN client trusts the server it connects to via a certificate signed by a certificate authority. That certificate proves the server is who it says it is. If the certificate gets compromised (taken from a stolen laptop, leaked from a backup, exfiltrated from a misconfigured S3 bucket), an attacker can impersonate the server. Until somebody manually revokes that certificate, every client that connects gets man-in-the-middled with no warning.

Most consumer VPNs issue certificates valid for months. A few issue them for years. Fexyn issues them for 24 hours from a Vault-backed public key infrastructure. Here is why that's the right number.

The certificate revocation problem nobody talks about

The standard answer to "what if a cert leaks" is "we revoke it." The mechanism is a Certificate Revocation List (CRL) or its modern cousin OCSP (Online Certificate Status Protocol). The client checks the CRL, sees the cert is revoked, refuses to trust it.

In practice, both mechanisms are unreliable.

CRLs are slow to propagate. The PKI publishes a new CRL on a schedule — typically hourly or daily. Clients cache the CRL between checks. Between revocation and propagation, every client out there still trusts the revoked cert.

CRLs are large. A long-lived PKI accumulates revocations. The CRL grows unbounded until a certificate ages out. CRLs of several megabytes are common. Clients that download the full CRL on every connection slow down as the PKI ages. Clients that don't fall behind on revocation status.

OCSP is supposed to fix this by making revocation checks real-time per-cert rather than batched per-CRL. In practice, OCSP responders go down. When the responder is unreachable, clients face a choice: fail closed (block the connection) or fail open (trust the cert anyway). Most fail open, because failing closed breaks user experience whenever the OCSP responder hiccups. So in practice, OCSP doesn't reliably catch revocations either.

Browsers eventually gave up. Chrome stopped doing OCSP by default in 2012. Firefox followed. They moved to CRLSets and CRLite (curated subsets of revocations pushed in browser updates). Better, but specifically for browsers, not VPNs.

For a VPN PKI: if your cert leaks and you revoke it, hope that every client refreshes its CRL before the attacker uses it. Hope they don't fail open during a transient OCSP outage. Hope nothing went wrong in the gap.

Short-lived certificates dodge the problem

The Let's Encrypt insight: if certificates expire fast enough, you don't need to revoke them. The cert is gone before it matters.

Let's Encrypt issues 90-day certificates. The web ecosystem rebuilt its automation around that constraint. ACME, certbot, automatic renewal — all of it exists because somebody decided that 90 days was short enough that revocation became a footnote rather than a feature.

For a VPN PKI you can go shorter. The trade-off:

Long certs (months to years): low operational load, terrible blast radius if compromised.
Short certs (hours): higher operational load, low blast radius.

24 hours is the sweet spot for VPN clients. Long enough that a single sleep/resume cycle doesn't trigger renewal. Short enough that a stolen credential expires before most attackers can do anything with it.

How Fexyn implements it

Fexyn runs a HashiCorp Vault PKI as the certificate issuer. The configuration:

Root CA offline, kept on hardware tokens. Out of reach of any compromise of the running infrastructure.
Intermediate CA online, signs server and client certificates.
Client cert TTL: 24 hours.
Server cert TTL: 24 hours, rotated automatically.

The flow when you connect:

The Fexyn client authenticates to the API with your account credentials.
The API requests a fresh certificate from Vault for your client.
Vault signs a new certificate, valid for 24 hours.
The client uses that cert for the VPN tunnel.
The cert expires. Next connect triggers a fresh issuance.

The cert never sits on disk longer than its lifetime. There's no long-lived secret on your laptop that needs to survive between sessions.

Threat models this addresses

Stolen laptop. A thief has a 24-hour window to impersonate you on the VPN before the cert dies. Compared to a long-lived cert that would be valid for months: dramatic improvement.

Border seizure. Crossing borders with a laptop, anywhere customs has expansive seizure authority. If they image your disk or pull credentials, those credentials expire the next day. You don't need to scramble to revoke; the system handles it by aging out.

Compromised backup. If your backup gets stolen and the attacker extracts the VPN credential, same story. The attacker has hours, not months.

Compromised infrastructure. If a Fexyn server gets compromised in a way that exposes its certificate, the impact is bounded by the cert's remaining lifetime. We rotate server certs daily; the worst case is a 24-hour window where a malicious server could be impersonated. We pair this with certificate pinning on the client side, which catches the impersonation before it matters.

What this isn't

Short-lived certs aren't a substitute for:

Strong account auth. If your password gets phished and the attacker logs into your Fexyn account, they get fresh certificates from the API. The cert lifetime doesn't help. Use a password manager and enable MFA.
Endpoint security. A compromised laptop can be backdoored to silently exfiltrate every cert the moment it's issued. The PKI doesn't fix that.
Network-layer compromise outside the tunnel. If your ISP is doing TLS interception with their CA pre-trusted on your machine, that's a different attack and the VPN PKI is below the level where it can help.

The PKI bounds one specific failure mode: leaked credentials staying useful indefinitely. It's a meaningful improvement, not a complete defence.

Why no other consumer VPN does this

It's not technically hard. Vault PKI is open-source. ACME-style automation is well-documented. The reason most VPN providers stick with long-lived certs is operational:

Long-lived certs mean less load on the PKI infrastructure.
They mean clients can connect even if the PKI is briefly unreachable.
They mean fewer support tickets from "my VPN won't connect" caused by a botched renewal.

These are real concerns. Solving them requires building the renewal flow into the client until it's invisible. That's engineering work the average VPN team doesn't prioritise because the marketing copy doesn't sell on PKI hygiene.

Fexyn prioritised it because it's a meaningful security difference for users in higher-risk positions: journalists, activists, remote workers handling sensitive data.

Try Fexyn free for 7 days. Your first cert is valid for 24 hours, and you don't have to think about it.