Certificate Lifetimes Are Shrinking: What 64-Day and 45-Day TLS Means for Custom Domains on Tunnels

On February 10, 2027, roughly three months from now, Let’s Encrypt changes its default certificate lifetime from 90 days to 64 days. About five weeks later, on March 15, 2027, the industry-wide maximum for publicly trusted TLS certificates drops from 200 days to 100. Neither change is a surprise, yet few developers have asked what it does to a custom domain pointed at a tunnel.

If you run app.yourdomain.com through a tunneling service, a certificate sits between your users (or your webhook senders) and your localhost. Someone has to renew it every time the clock runs out, and that clock is about to run faster. This guide covers the exact timeline, how renewal and DNS verification work behind a tunnel, the difference between provider-managed and bring-your-own (BYO) certificates, and the failure modes that appear when renewal quietly stops.

The Timeline: What Is Actually Changing and When

Two separate schedules are in play, and people often blur them together.

1. The CA/Browser Forum schedule (applies to every public CA)

In April 2025 the CA/Browser Forum passed Ballot SC-081v3. It phases down both the maximum certificate validity and the period for which a CA may reuse a prior domain validation (DCV). The ballot passed on April 11, 2025, with no votes against.

2. The Let’s Encrypt schedule (the CA most tunnel and ACME setups use)

Let’s Encrypt is moving faster than the mandate. It will reach 45 days in 2028, a year before the Forum’s 47-day maximum.

A few details from Let’s Encrypt’s announcements:

• Staging is live now. 64-day certificates have been available in Let’s Encrypt’s staging environment since October 14, 2026, so you can test your renewal setup before production changes.
• Existing certificates are not revoked. Let’s Encrypt expects the last 90-day certificate to expire on May 11, 2027.
• Users of the tlsserver (45-day) or shortlived (6-day) profiles are not affected by the February change.
• The short authorization reuse period is the quiet part. As the reuse window shrinks, you prove domain control at essentially every issuance rather than leaning on a cached validation. Let’s Encrypt says this also removes the need for “CAA rechecking” when validation data is more than seven hours old.

If you use the default profile and never touched your ACME client’s settings, the February 2027 change happens to you automatically. That is fine if your renewal is truly automated. It is a problem if “automated” means a cron job nobody has looked at since 2023.

Why Tunnel Custom Domains Are a Special Case

On a normal server you hold the private key and run the ACME client yourself. With a tunnel, the public edge belongs to the provider, and your domain is an alias pointing at it. That splits responsibility three ways:

• The provider terminates TLS and (usually) obtains and renews the certificate.
• You control the DNS records that make that issuance possible.
• Your local app never sees the certificate at all.

Shorter lifetimes stress the DNS half of that arrangement most. The renewal job on the provider’s side can be flawless and still fail because a record on your side drifted.

Provider-Managed Certificates: Convenient, Not Invisible

Most tunnel platforms default to managed certificates, and ngrok’s documentation is a concrete example. It recommends automatic certificates unless you have special requirements. For these it provisions and renews certificates from an ACME-compliant CA such as Let’s Encrypt. It uses an HTTP-01 challenge for most domains and switches to DNS-01 for wildcard domains.

For a branded domain such as api.your-domain.com, you create a CNAME record, and provisioning does not begin until you do. For a wildcard such as *.app.example.com, you need two CNAMEs: the wildcard itself and _acme-challenge.app.example.com.

Provisioning is asynchronous. ngrok says it typically takes from a few seconds up to several minutes, and occasionally longer if a DNS challenge is slow to validate. While it runs, ngrok serves its own default wildcard certificate. That certificate is not issued for your hostname, so browsers and other TLS clients show a hostname-mismatch warning.

That documentation describes one vendor, but the pattern is common. It tells you what to watch under shorter lifetimes:

1. The CNAME is your issuance credential. If someone “cleans up” DNS and removes it, provisioning cannot proceed. At 398 days you might not notice for a year. At 64 days you find out within about two months, and at 45 days within about six weeks.
2. Wildcards depend on a second record. The _acme-challenge CNAME is easy to forget, because nothing visibly breaks until the certificate needs renewing.
3. Fallback certificates look like an outage. A hostname-mismatch warning is a hard failure for many API clients and webhook senders, even if a human could click through.

Managed certificates do not remove your obligations. They narrow them to a short list: keep the DNS records correct and monitor the outcome.

Bring Your Own Certificates: Control With a Rotation Tax

Some teams upload their own certificate: one from an internal CA, an EV certificate, or one pinned by a partner. That is legitimate, and the trade-off sharpens as lifetimes shrink.

With ngrok, as an example, custom certificates mean you are responsible for renewal and rotation. You upload a PEM bundle with the leaf certificate first, followed by any intermediates, plus a private key that is not encrypted. Then you attach the certificate to one or more domains, because creating it alone changes no traffic.

On ngrok, TLS certificates are available on all plans, but BYO certificates require the pay-as-you-go plan. They are billed at a flat $0.27 per hour for any clock hour in which at least one endpoint using that certificate is active. A wildcard certificate is billed once, not per matching subdomain. Pricing and plan rules differ by vendor, so check yours.

Now do the rotation math for a single hostname:

These are minimums if you replaced each certificate exactly at expiry. Renewing earlier, as you should, pushes the real number higher.

A manual process that was tolerable once a year (download, convert, upload, attach, test) becomes a recurring operational cost at six to eight times a year per hostname, multiplied by every environment. If you must use BYO, automate the whole path:

1. Your ACME client obtains the certificate.
2. A deploy hook uploads it through the provider’s API.
3. A second step attaches it to the domain.
4. A check verifies the live certificate’s expiry afterwards.

Treat any step you cannot script as the one that will fail.

The Forum’s schedule applies to publicly trusted certificates. A certificate from a private CA that your own clients trust is outside it, but it does not help when external services call your tunnel URL.

What Breaks When Renewal Silently Fails

“Silently” is the operative word. Several things that used to cushion failures are weaker now:

• No more reminder emails. Let’s Encrypt ended its expiration notification emails on June 4, 2025. It recommends third-party monitoring instead, and its monitoring page names Red Sift Certificates Lite, which is free for up to 250 certificates. If you relied on that email as a safety net, it is gone.
• Shorter windows leave less slack. Let’s Encrypt recommends renewing at roughly two-thirds of a certificate’s lifetime. For a 45-day certificate that means renewing around day 30, leaving about 15 days to fix a failure. For a 64-day certificate it is around day 43, leaving about three weeks.
• Reuse is shrinking. With authorization reuse falling to 10 days and then 7 hours for Let’s Encrypt’s default profile, “it worked last time” no longer implies “it will work this time.”

Typical failure modes on tunnel custom domains:

Two details from Let’s Encrypt’s documentation are relevant here. First, HTTP-01 can only be done on port 80. Its validation follows up to 10 redirects, but only to ports 80 or 443. Second, Let’s Encrypt checks CAA records before issuing, and its CAA identifier is letsencrypt.org.

Webhook providers and API consumers are the least forgiving. A person might click past a warning, but an automated sender typically just fails the TLS handshake, and the first sign is missing events rather than a visible error page.

Renewal Timing: Stop Using Fixed Offsets

Many tools were configured for 90-day certificates with a fixed rule, such as “renew when 30 days remain” or “renew every 60 days.” Let’s Encrypt’s own guidance is blunt. A hardcoded interval of 60 days is no longer sufficient for 45-day certificates. It suggests grepping cron jobs, wrapper scripts and runbooks for hardcoded numbers like 83, 80 or 60. Anything that waits 80 days will miss a 64-day certificate entirely.

The better answer is ACME Renewal Information (ARI), standardized as RFC 9773. The CA tells the client when to renew, and clients should renew inside the suggested window. Let’s Encrypt recommends ARI, and says that if your client lacks it, renewing at about two-thirds of the certificate’s lifetime is acceptable.

Certbot has checked ARI automatically when the CA supports it since version 4.1.0 (June 2025). Other clients differ, so verify your specific client and version rather than assuming. For tunnel providers, ask whether their renewal pipeline uses ARI-based timing, since you do not control it.

DNS Verification Under Shorter Lifetimes

HTTP-01 vs DNS-01

HTTP-01 is simple for single hostnames: the CA fetches a token from your site. On a tunnel the provider usually answers it for you once the CNAME is in place. DNS-01 is required for wildcards and works where HTTP-01 cannot, but it needs DNS write access at every issuance. Let’s Encrypt notes that putting full DNS API credentials on a web server increases the impact of a compromise. It recommends narrowly scoped credentials, or validating from a separate server.

Delegate the challenge instead of sharing DNS keys

Let’s Encrypt follows standard DNS lookups for DNS-01 validation, so you can use CNAME or NS records to delegate the _acme-challenge name to another zone. That lets you point _acme-challenge.yourdomain.com at a zone reserved for automation, with credentials scoped to that zone only. Client support for following the delegation varies, so confirm yours and test with a dry run before relying on it.

DNS-PERSIST-01: a new option to watch

Let’s Encrypt has described a new challenge type, DNS-PERSIST-01, based on an IETF draft. Instead of publishing a fresh token at each issuance, you publish a standing TXT record at _validation-persist.<domain> that names the CA and your specific ACME account. Renewals then need no DNS changes, so DNS write access can be locked down after setup.

Scope and lifetime are controlled with optional parameters. policy=wildcard widens the authorization to wildcard certificates and matching subdomains. persistUntil sets an expiry timestamp. Without an expiry, the authorization lasts indefinitely, so set a monitoring reminder. Because the record persists, protecting your ACME account key becomes the central concern. The CA/Browser Forum approved the underlying validation method in ballot SC-088v3 in October 2025.

Let’s Encrypt had targeted a production rollout in Q2 2026, with staging first. I could not find confirmation that it is live in production. Community discussion as late as July 2026 described the IETF draft as still being tightened and said no public CA had a production implementation. Treat it as something to plan for rather than depend on. It also matters whether your tunnel provider supports it, not just your own ACME client, because on a managed domain the provider holds the ACME account.

A Practical Checklist for Custom Domains on Tunnels

Before February 10, 2027

1. Inventory every custom hostname and note who renews it: the provider, your ACME client, or a person.
2. Verify DNS records (the CNAME target, plus _acme-challenge for wildcards) against your provider’s current instructions.
3. Check CAA records to confirm they permit the CA actually issuing.
4. Test renewal end to end. Run your ACME client against Let’s Encrypt staging, which has issued 64-day certificates since October 14. For managed domains, confirm the provider’s status field or dashboard shows a healthy certificate.
5. Update old clients. Make sure yours supports ACME profiles and ARI, and remove hardcoded renewal offsets.

Ongoing

1. Monitor the live certificate, not the job. Run an external check that connects to each hostname and alerts when the remaining lifetime falls below a set threshold, such as the last third of the certificate’s life. A job exiting with code 0 proves nothing about what the edge is serving.
2. Alert on DNS drift. A scheduled check that your CNAMEs still resolve to the expected targets catches the most common managed-certificate failure.
3. Document the ownership. When the person who set up the domain leaves, the renewal process should not leave with them.
4. Rehearse the failure. Know the manual recovery steps (re-create the record, trigger reissue, re-upload) before you need them at 2 a.m.

Provider-Managed or BYO? A Quick Decision Guide

For most developers the managed path is right, and shorter lifetimes strengthen the case. A provider that renews continuously is doing the job you would otherwise script yourself.

Where Pro Custom Domains Fit

Custom domains are the point where a tunnel stops being a throwaway URL and becomes part of your infrastructure: a stable hostname for webhooks, demos, staging, or a client’s preview. That makes certificate handling part of what you are buying. When evaluating a Pro custom-domain plan from any tunnel provider, ask:

• Are certificates issued and renewed automatically, and what happens to the hostname if renewal fails?
• Which challenge types and DNS records are required, and can I see certificate status and expiry in a dashboard or API?
• Is wildcard support available, and how is the _acme-challenge record handled?
• Can I bring my own certificate, and is rotation scriptable through an API? What does it cost?
• How does the provider alert me before expiry, given that Let’s Encrypt’s reminder emails no longer exist?

A plan that answers these clearly turns the 64-day and 45-day changes into a non-event.

Frequently Asked Questions

Is the 64-day change a CA/Browser Forum rule?

No. The 64-day default is Let’s Encrypt’s own interim step. The Forum’s current maximum is 200 days, falling to 100 on March 15, 2027.

Do I need to do anything if my tunnel provider manages certificates?

Mainly keep your DNS records intact and monitor the certificate your hostname actually serves.

Will Let’s Encrypt certificates become 47 days?

No. Let’s Encrypt plans 45 days from February 16, 2028, slightly under the Forum’s eventual 47-day maximum in 2029.

What happens to my existing 90-day certificates?

They stay valid until they expire, and none are revoked as part of the change. Let’s Encrypt expects the last 90-day certificate to expire on May 11, 2027. Anything issued or renewed from February 10, 2027 gets 64 days.

Does this apply to self-signed or private-CA certificates?

The schedule governs publicly trusted TLS certificates, so private PKI is outside it, though external callers will not trust such certificates.

Key Takeaways

• The key dates are February 10, 2027 (Let’s Encrypt moves to 64 days), March 15, 2027 (100-day industry maximum), February 16, 2028 (Let’s Encrypt moves to 45 days), and March 15, 2029 (47-day maximum, 10-day DCV reuse).
• On tunnels, the risk is rarely the provider’s renewal engine. It is DNS drift, expired credentials, and BYO certificates nobody rotated.
• Monitor the served certificate externally, because Let’s Encrypt’s reminder emails ended in June 2025.
• Replace hardcoded renewal offsets with ARI or renewal at about two-thirds of the lifetime.
• Prefer managed certificates unless a real requirement says otherwise, and automate every step if you bring your own.

Sources

• CA/Browser Forum Ballot SC-081v3 schedule: SSLInsights, Odown, DNSimple
• Let’s Encrypt / ISRG: Decreasing Certificate Lifetimes to 45 Days
• Let’s Encrypt: 64-Day Certificate Lifetimes Coming Feb 2027
• Let’s Encrypt: DNS-PERSIST-01
• Let’s Encrypt community: DNS-PERSIST-01 deployment status and win-acme discussion
• Let’s Encrypt: Expiration Notification Service Has Ended
• Let’s Encrypt: Monitoring Service Options
• Let’s Encrypt: Challenge Types
• Let’s Encrypt: CAA
• ngrok: TLS certificates documentation
• Certbot 4.1.0 release (ARI support)
• IETF: ACME Renewal Information, RFC 9773

Originally published at https://instatunnel.my/blog/certificate-lifetimes-are-shrinking-what-64-day-and-45-day-tls-means-for-custom-domains-on-tunnels