Let's Encrypt Goes to 45 Days: What Enterprise Teams Can Learn from the Free CA

The Free CA Is Leading the Industry

Let's Encrypt doesn't wait for deadlines. While the CA/Browser Forum's SC-081 won't require 47-day certificates until March 2029, Let's Encrypt announced it will shift to 45-day certificates well ahead of the mandate. They're also deprecating TLS Client Authentication and introducing a new DNS-PERSIST-01 validation method.

This isn't surprising. Let's Encrypt has always pushed the industry toward shorter certificate lifetimes. They launched with 90-day certificates in 2016 when the industry norm was 3 years. Their reasoning then is the same reasoning now: shorter certificates are more secure, and automation makes them practical.

Enterprise teams should pay attention. Let's Encrypt's moves are a preview of where the entire industry is headed.

Why Let's Encrypt Is Moving Early

The Automation-First Philosophy

Let's Encrypt issues over 400 million active certificates — roughly half of all TLS certificates on the public internet. They've proven at massive scale that short-lived certificates work when automation is built in from the start.

Their position is clear: if your renewal process requires human intervention, it's broken. The shift to 45 days isn't a burden on their ecosystem because their ecosystem was designed for automated renewal from day one.

Security Through Freshness

Let's Encrypt's rationale for shorter certificates comes down to three security principles:

1. Reduced exposure window: If a private key is compromised, the attacker can use it for at most 45 days instead of 398
2. Faster algorithm rotation: When post-quantum algorithms become mandatory, 45-day certificates ensure rapid adoption
3. Certificate revocation limitations: CRL and OCSP have known reliability issues — short-lived certificates reduce dependence on revocation infrastructure

DNS-PERSIST-01: Reducing Renewal Friction

Alongside the 45-day shift, Let's Encrypt is introducing DNS-PERSIST-01, a new validation method that reduces the need for dynamic DNS updates during renewals. Instead of creating a new TXT record for every renewal, organizations can set a persistent DNS record that's verified periodically.

# Traditional DNS-01 (every renewal)
_acme-challenge.example.com  TXT  "random-token-changes-each-time"

# DNS-PERSIST-01 (set once, persist)
_acme-persist.example.com    TXT  "stable-verification-token"

This is significant for enterprises managing thousands of certificates — it reduces the DNS API calls and propagation delays that can cause renewal failures.

Lessons for Enterprise Teams

Lesson 1: Design for Automation, Not for Humans

Let's Encrypt's entire model is built on the assumption that no human touches the renewal process. Enterprise teams should adopt the same mindset.

What this means in practice:

• Every certificate renewal should be fully automated end-to-end
• Approval workflows should be pre-authorized by policy, not gated by individuals
• Deployment should be automated — a renewed certificate sitting in a queue is as dangerous as an expired one
• Error handling should be automated with retry logic and escalation

Lesson 2: Standardize on ACME

Let's Encrypt popularized the ACME protocol. Today, major commercial CAs support ACME:

• DigiCert: ACME support for OV and EV certificates
• Sectigo: ACME integration for automated issuance
• GlobalSign: Atlas ACME support
• Google Trust Services: ACME-compatible issuance
• ZeroSSL: ACME endpoint available

Standardizing on ACME across all your CAs creates a uniform automation layer regardless of the certificate provider.

# Multi-CA ACME configuration
acme_providers:
  production:
    primary:
      ca: digicert
      directory: "https://acme.digicert.com/v2/acme/directory"
    fallback:
      ca: letsencrypt
      directory: "https://acme-v02.api.letsencrypt.org/directory"

  staging:
    primary:
      ca: letsencrypt
      directory: "https://acme-v02.api.letsencrypt.org/directory"

  internal:
    primary:
      ca: step-ca
      directory: "https://ca.internal/acme/directory"

Lesson 3: Treat Certificates as Ephemeral Infrastructure

Let's Encrypt certificates have always been short-lived by design. Enterprise teams should adopt the same mental model: certificates are ephemeral, like container instances or cloud resources. They spin up, serve their purpose, and get replaced.

This mindset shift has operational implications:

• Stop treating certificate issuance as a project — it's a continuous automated process
• Stop storing certificate metadata in spreadsheets — use a certificate management platform
• Stop requiring manual approvals for renewals — pre-authorize renewals by policy
• Stop deploying certificates manually — automate deployment as part of the renewal pipeline

Lesson 4: Monitor Renewal Health, Not Just Expiration

Let's Encrypt's infrastructure monitors the health of their issuance pipeline, not just certificate expiration dates. Enterprise teams should track:

A certificate that expires in 30 days isn't an emergency. A renewal pipeline with a 20% failure rate is.

Lesson 5: Plan for DCV at Scale

With 45-day certificates and 10-day DCV reuse (coming in 2029), domain validation becomes a high-frequency operation. Let's Encrypt's DNS-PERSIST-01 addresses this directly.

Enterprise teams should:

1. Consolidate DNS management to providers with robust APIs (Cloudflare, Route 53, Azure DNS, Google Cloud DNS)
2. Automate DNS record management for ACME challenges
3. Implement DNS-PERSIST-01 when available to reduce validation overhead
4. Monitor DNS propagation to catch validation failures caused by slow propagation

What About Commercial CAs?

The Hybrid Reality

Most enterprises can't use Let's Encrypt exclusively. Regulatory requirements, OV/EV certificate needs, and contractual obligations mean commercial CAs remain part of the mix. But the lessons still apply:

• Use ACME with commercial CAs wherever they support it
• Automate the remaining CAs through their APIs
• Build a unified automation layer that abstracts CA-specific differences
• Use Let's Encrypt for the long tail of certificates where DV is sufficient

The Best of Both Worlds

┌─────────────────────────────────────────────────┐
│          Certificate Lifecycle Platform          │
├─────────────────────────────────────────────────┤
│              Unified ACME Layer                  │
├──────────┬──────────┬──────────┬────────────────┤
│  Let's   │ DigiCert │ Sectigo  │  Internal CA   │
│ Encrypt  │  (ACME)  │  (ACME)  │  (Step CA)     │
├──────────┴──────────┴──────────┴────────────────┤
│            Automated Deployment                  │
├──────────┬──────────┬──────────┬────────────────┤
│   AWS    │  Azure   │   GCP    │  Kubernetes    │
└──────────┴──────────┴──────────┴────────────────┘

Preparing for 45-Day Certificates Today

If You Use Let's Encrypt

If you already use Let's Encrypt, you're closer to ready than you think. Verify:

• ACME clients (certbot, acme.sh, Caddy, cert-manager) are configured for automatic renewal
• Renewal hooks deploy certificates to all endpoints automatically
• Monitoring alerts on renewal failure, not just expiration
• DNS automation is in place for DNS-01 challenges
• Fallback procedures exist if the primary ACME client fails

If You Use Commercial CAs

Start adopting Let's Encrypt patterns for your commercial CA certificates:

• Evaluate ACME support from your CA
• Pilot automated renewal for a subset of certificates
• Build deployment automation that works regardless of the CA
• Implement renewal monitoring alongside expiration monitoring
• Plan migration to shorter validity periods ahead of mandates

The Signal Is Clear

Let's Encrypt moving to 45-day certificates isn't just a technical decision — it's a signal to the entire industry. The world's largest CA, responsible for half of all TLS certificates, is demonstrating that short-lived certificates work at scale when automation is the foundation.

Enterprise teams that learn from Let's Encrypt's approach — automation-first, ACME-based, ephemeral certificates — will navigate the transition to 47-day certificates smoothly. Those that treat their commercial CA certificates differently from their Let's Encrypt certificates will end up managing two separate operational models when one would do.

TigerTrust unifies certificate lifecycle management across Let's Encrypt and commercial CAs with ACME-native automation. See how at tigertrust.io.