Short Lived TLS Certificates: 2027 Plan for VPN Servers

Your panel, your subscription page and your API sit behind certificates that renew on a 90 day cycle nobody thinks about. That habit has an end date. From 10 February 2027, Let’s Encrypt plans to issue 64 day certificates by default, and from 15 March 2027 the CA/Browser Forum rules cap every publicly trusted certificate at 100 days.

The direct answer: short lived TLS certificates are a scheduling and automation problem, not a security scare. Renewal has to be automated, monitored and rehearsed before those dates, and any client that pins a certificate needs a plan. In our reading of the docs, WireGuard and REALITY do not ask you to install a certificate from a public CA. Dates here are as of 30 October 2026, from the pages we link.

This guide is for VPN operators who terminate TLS on panels, subscription pages, API endpoints or TLS based transports. It gives a dated timeline, a table of which components use a public certificate, the arithmetic of what shorter lifetimes do to a fleet, and a renewal runbook. These are industry rules for publicly trusted CAs, not law.

The 2026 to 2029 Certificate Lifetime Timeline

We keep three kinds of date apart: rules already in force, dates written into the Requirements, and plans a CA has announced. The CA/Browser Forum sets maximum lifetimes for every publicly trusted CA in its Baseline Requirements (version 2.3.1, dated 4 October 2026), following ballot SC081v3. Let’s Encrypt then chooses its own schedule inside those limits.

Date	What changes	Status
15 Mar 2026	Maximum validity 200 days; domain validation data reuse 200 days	In force
13 May 2026	Let’s Encrypt `tlsserver` profile issues 45 day certificates	In force, opt in
10 Feb 2027	Let’s Encrypt default moves from 90 to 64 days; last 90 day certificate expected to expire 11 May 2027	Announced by Let’s Encrypt
15 Mar 2027	Maximum validity 100 days; validation data reuse 100 days	Scheduled in the Requirements
2028	Let’s Encrypt default moves to 45 days; authorization reuse 7 hours	Announced, date to recheck
15 Mar 2029	Maximum validity 47 days; validation data reuse 10 days	Scheduled in the Requirements

Let’s Encrypt’s October 2026 post says its staging environment starts issuing 64 day certificates on 14 October 2026, ahead of the production change, and that valid certificates will not be revoked because of it. Its December 2025 post gave 16 February 2028 for the 45 day step, while the October post says only “2028”. Opt in six day certificates (160 hours, the shortlived profile) have been generally available since 15 January 2026, and its January 2026 post said it had no plan to make them the default at that time.

What is not settled: the date authorization reuse drops from 30 to 10 days (the December post ties it to February 2027, the October post gives no date), and when its DNS-PERSIST-01 validation method reaches production. A February 2026 post targeted the second quarter of 2026, and we did not confirm the current status.

Which VPN Components Use a Public Certificate?

The Baseline Requirements cover publicly trusted TLS server certificates and exclude private PKI whose root no software vendor distributes. So the table asks one thing: does this component present a certificate that clients check against a public trust store?

Component	Certificate you renew?	Check
Panel, subscription page, API	Public, if browsers or apps use the system trust store	Every hostname
Xray over TLS	Yours, set in `tlsSettings`	Xray reloads server certificates hourly by default
sing-box TLS inbound	Yours	`certificate_path` and `key_path` reload on change; inline `acme` is deprecated
Hysteria 2	Yours, from `tls` files or `acme`, not both	Files are read on every handshake
OpenConnect (ocserv)	Yours, `server-cert` and `server-key`	Reloads on change or SIGHUP; the manual ties clean reload to an unchanged key
REALITY	None from a public CA, in our reading	Inbound fields list `target` and an x25519 `privateKey`, no certificate path; the docs mention only a temporary REALITY certificate
WireGuard	None, in our reading	The protocol page mentions static keys, not certificates
Your own CA (OpenVPN, IKEv2, mutual TLS)	Outside the Requirements, if no software vendor distributes its root	You set the lifetimes
Bare IP address endpoint	Let’s Encrypt IP certificates must be short lived	Use `HTTP-01` or `TLS-ALPN-01`

REALITY and WireGuard still sit next to panels and subscription hosts that do need certificates. One more caution: Let’s Encrypt’s May 2025 announcement planned to drop the TLS client authentication usage from its default profile on 11 February 2026, and its profiles page says the tlsclient profile was no longer available from 8 July 2026. Its announcement adds that many client authentication uses are better served by a private CA. If your nodes authenticate to the panel with public certificates, plan that move.

Pins and key reuse

A pin ties a client to something that changes at renewal, unless you choose carefully.

Setting	Pins	Survives renewal?
Xray `pinnedPeerCertSha256`, leaf hash	The leaf certificate	No
Xray `pinnedPeerCertSha256`, CA hash	A CA; Xray checks the leaf is signed by it	Not tied to the leaf
sing-box `certificate_public_key_sha256`	The server public key	Only if the key is reused
sing-box `certificate_sha256` (1.15.0, alpha)	The whole certificate	No
Hysteria 2 `pinSHA256`	A certificate fingerprint	Test it; the docs do not say leaf or chain

Certbot’s default is a new private key at each renewal, and --reuse-key changes that. Reusing the key keeps public key pins and ocserv reloads stable, at the cost of one key living longer. Xray’s TLS documentation describes the leaf and CA behaviour, and our upgrade checklist covers the field changes around it.

What Short Lived TLS Certificates Do to a Fleet

Certbot 4.0.0 and later renews when less than a third of the lifetime remains, and half for lifetimes of 10 days or less. Before 4.0.0 the threshold was a fixed 30 days. Let’s Encrypt advises about two thirds of the lifetime for clients without ARI. Our arithmetic:

Lifetime	Renewal starts	Slack if renewal keeps failing
90 days	Day 60	30 days
64 days	Day 43	21 days
45 days	Day 30	15 days
160 hours	Hour 80	80 hours, about 3.3 days

Per hostname that is about 6 renewals a year at 90 days, 8.5 at 64 days and 12 at 45 days. A fleet of 200 hostnames goes from roughly 1,200 renewals a year at 90 days to roughly 2,400 at 45 days. Let’s Encrypt says renewals are largely exempt from its rate limits, and renewals coordinated by ARI are exempt from all of them, so volume alone is not the risk.

New names are. The limit is 50 new certificates per registered domain per 7 days, refilling one every 202 minutes, plus 5 per 7 days for an identical set of names, which has no override. On our arithmetic, standing up 120 node hostnames under one domain issues 50 at once, then about 7 a day, so the last arrives roughly ten days later unless you request an override.

Renewal Runbook for a VPN Fleet

Inventory every endpoint. Record hostname, who terminates TLS, issuer, expiry, reload method and which clients pin it.
Automate with a client that supports ARI. ACME Renewal Information, defined in RFC 9773, lets the CA suggest a renewal window; the client picks a random time inside it. Check your client’s documentation for ARI support. Without it, renew at about two thirds of the lifetime. Let’s Encrypt also says to search cron jobs, wrapper scripts and runbooks for hard coded numbers such as 83, 80 or 60.
Choose the validation path. HTTP-01 needs port 80 and the same answer on every server. DNS-01 handles wildcards but needs a DNS API credential, so scope it narrowly. Revisit this when you add nodes behind a load balancer or GeoDNS.
Deploy and reload on purpose. A deploy hook should install files, reload the service and check the served expiry. Xray’s docs describe an hourly reload timer, so a new file may take up to an hour to appear, while ocserv reloads changed files and also on a signal. Certbot’s --dry-run skips deploy hooks unless you add --run-deploy-hooks.
Stagger fleet wide changes. Canary one node, verify clients connect, then widen. Keep the previous certificate and key until the new one is confirmed.
Monitor expiry and the job itself. Let’s Encrypt ended its expiry emails on 4 June 2025. Run a check such as openssl x509 -checkend 1209600 -noout -in fullchain.pem, which exits nonzero if the certificate expires within 14 days. As our own suggested thresholds, warn when one third of the lifetime remains and page at one sixth: about 21 and 11 days for a 64 day certificate. Expect the warning to fire for certificates your client has not renewed yet, so tune it if your client waits for a CA suggested window. TunnelHQ runs real protocol handshakes and alerts on failed checks, per its product page, which helps confirm endpoints work after a rollout. Our guide to monitoring a VPN server fleet covers the wider setup.
Rehearse before the deadline. Use the staging environment at https://acme-staging-v02.api.letsencrypt.org/directory, whose certificates chain to untrusted test roots. On a spare canary hostname, request the tlsserver profile in production with Certbot’s --required-profile to live with 45 day renewals early. For CI, Let’s Encrypt suggests Pebble, a small ACME test server. Then break the job on purpose: close port 80, revoke the DNS token, make the reload fail.

FAQ

Do 47 day certificates apply to my VPN servers today?

No. As of 30 October 2026 the 47 day maximum is scheduled for 15 March 2029, and the current maximum is 200 days. Let’s Encrypt still issues 90 days by default until 10 February 2027.

Do WireGuard and REALITY servers need TLS certificates?

Not for the tunnel itself, in our reading of the docs. The WireGuard protocol page describes static keys and mentions no certificates, and the REALITY inbound documents no certificate file. Your panel and subscription host still do.

How often should Certbot run?

Often, because it only acts on certificates near expiry. Certbot’s docs say it can run as often as you like and give a twice daily cron example.

Can I keep renewing by hand?

For one hostname, barely. At 64 days that is about eight renewals a year per name, and Let’s Encrypt advises against manual renewal.

Will a private CA avoid all of this?

For endpoints only your own clients reach, the public lifetime limits do not apply, because the Requirements exclude private PKI. You then run the CA and distribute its root to every client, which browser facing endpoints cannot rely on.

The Takeaway

The date that matters for short lived TLS certificates is not 2029. It is 10 February 2027, when a renew every 60 days habit leaves a 64 day certificate only four days of slack. Automate, alert before the renewal window is missed, choose pins that survive renewal, and rehearse a failure before the first 64 day certificate is issued.

Running TLS on panels, subscription hosts or transports across many nodes? DigitalD.tech can help you plan the renewal pipeline, the monitoring and the test plan around your fleet. Tell us about your setup on the contact page.

Last checked against the CA/Browser Forum Baseline Requirements and ballot SC081v3, Let’s Encrypt’s posts, rate limit, profile, staging and challenge type pages, RFC 9773, Certbot’s documentation, the Xray, Hysteria, ocserv, sing-box and WireGuard documentation and the OpenSSL x509 manual on 30 October 2026.