The 90-Day Mandate: Why Automating Let's Encrypt is No Longer Optional

The landscape of SSL/TLS certificate management is undergoing a massive, irreversible shift. For years, managing certificates manually was a tedious but manageable chore. You bought a certificate, installed it, and set a calendar reminder for a year or two down the line. Today, that approach is a fast track to widespread infrastructure outages.

What Let's Encrypt pioneered—free, 90-day certificate lifespans combined with automated renewals via the ACME protocol—is rapidly becoming the mandatory blueprint for the entire internet. With major browsers pushing to enforce shorter lifespans for all public certificates, automation is no longer a DevOps luxury; it is a strict operational requirement.

In this comprehensive guide, we will explore the impending industry changes, dissect the technical implementation of the ACME protocol, review modern tooling, and establish best practices for securing and monitoring your automated certificate pipelines.

The Impending 90-Day Standard and Agile PKI

If you are still manually rotating certificates, the clock is ticking. Google Chrome, through its "Moving Forward, Together" initiative, has proposed reducing the maximum validity of public TLS certificates from 398 days to just 90 days. While the CA/Browser (CAB) Forum is finalizing the exact timeline, the cybersecurity industry is treating this as an impending 2025 reality.

This shift to 90 days is not an arbitrary punishment for sysadmins; it is a critical security upgrade. Shorter lifespans reduce the window of compromise if a private key is leaked and force organizations to adopt Agile PKI (Public Key Infrastructure).

Enter ACME Renewal Information (ARI)

To support this massive scale of automation, Let's Encrypt recently introduced support for the ACME Renewal Information (ARI) extension to the standard ACME protocol (RFC 8555).

Historically, ACME clients (like Certbot) blindly guessed when to renew—usually at the 60-day mark. ARI changes this by allowing Let's Encrypt to signal to your ACME client exactly when it should renew a specific certificate.

This is critical for mass-revocation events. If a Certificate Authority (CA) discovers a compliance bug and must revoke millions of certificates within 24 hours, ARI allows the CA to tell clients to renew immediately, preventing catastrophic global outages. Furthermore, as the industry lays the groundwork for Post-Quantum Cryptography (PQC) algorithms like ML-KEM, automated pipelines powered by ARI will be essential for the rapid transition to quantum-safe certificates over the next few years.

Choosing Your ACME Challenge: Why DNS-01 is the Enterprise Standard

Automation relies on proving to Let's Encrypt that you actually control the domain you are requesting a certificate for. The ACME protocol handles this via "challenges." The core technical decision in your implementation is choosing the right validation challenge.

The HTTP-01 Challenge (The Beginner's Route)

How it works: The ACME client places a specific token file on your web server at http://<domain>/.well-known/acme-challenge/. Let's Encrypt makes an HTTP request to that URL; if the token matches, the certificate is issued.

While HTTP-01 is incredibly easy to set up and requires no DNS API access, it has severe limitations for enterprise environments:
* It requires port 80 to be open to the internet.
* It does not support wildcard certificates (e.g., *.example.com).
* It is notoriously difficult to use for internal-only servers or staging environments hidden behind corporate firewalls.

The DNS-01 Challenge (The Industry Best Practice)

How it works: Instead of placing a file on a web server, the ACME client creates a specific TXT record (_acme-challenge.<domain>) in your domain's DNS zone. Let's Encrypt queries global DNS for this record to verify ownership.

DNS-01 is the undisputed enterprise standard. Because validation happens at the DNS level rather than the server level, you can issue certificates for internal, private-network servers without exposing them to the internet. Crucially, DNS-01 is the only way Let's Encrypt allows you to provision highly versatile wildcard certificates.

The only drawback? It requires programmatic access to your DNS provider via an API, which introduces specific security considerations we will cover later.

Modern Tooling: Moving Beyond Standalone Cron Jobs

The tooling ecosystem for Let's Encrypt has matured significantly. Modern infrastructure best practices dictate moving away from standalone shell scripts and cron jobs toward native infrastructure integrations.

Kubernetes Standard: cert-manager

If you are running cloud-native workloads, cert-manager is the undisputed standard. It runs as a controller within your Kubernetes cluster, automatically provisioning Let's Encrypt certificates for your Ingress resources and storing the private keys securely as Kubernetes Secrets.

Here is a practical example of configuring a ClusterIssuer in Kubernetes using the DNS-01 challenge with AWS Route53:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: security@yourdomain.com
    privateKeySecretRef:
      name: letsencrypt-prod-account-key
    solvers:
    - dns01:
        route53:
          region: us-east-1
          hostedZoneID: Z1234567890ABCDEF
          accessKeyIDSecretRef:
            name: route53-credentials
            key: access-key-id
          secretAccessKeySecretRef:
            name: route53-credentials
            key: secret-access-key

Once applied, simply adding a standard TLS block to your Ingress resource will trigger cert-manager to fetch and continually renew the certificate without any human intervention.

Modern Web Servers: Caddy and Traefik

If you are deploying standalone web servers or reverse proxies, consider using tools with native ACME integration. Caddy and Traefik automatically fetch, apply, and renew Let's Encrypt certificates out-of-the-box.

With Caddy, for example, a fully functioning, auto-renewing HTTPS web server requires just a three-line Caddyfile:

example.com {
    reverse_proxy localhost:8080
}

Caddy handles the ACME registration, the HTTP-01 challenge, the certificate generation, and the 60-day renewal cycle automatically.

Traditional VMs: Certbot and acme.sh

For traditional Linux VMs, Certbot (maintained by the Electronic Frontier Foundation) remains the gold standard. For restricted environments where installing Python dependencies (required by Certbot) is problematic, acme.sh is a brilliant, lightweight alternative written purely in Shell.

To issue a wildcard certificate using Certbot and the Route53 DNS plugin, the command is straightforward:

certbot certonly \
  --dns-route53 \
  -d "example.com" \
  -d "*.example.com" \
  --agree-tos \
  -m admin@example.com

Securing Your Automation Pipeline

Automation introduces new attack vectors. If your ACME client requires access to your DNS provider to create TXT records, a compromised server could lead to full domain hijacking.

Principle of Least Privilege for DNS APIs

A common, catastrophic mistake is handing an ACME client a global administrator token for a DNS provider (like Cloudflare or Route53). If an attacker extracts that token, they can reroute your entire company's email and web traffic.

Best Practice: Use scoped API tokens that only have permission to edit TXT records, and ideally, only for the specific _acme-challenge subdomain.

Here is an example of a securely scoped AWS IAM Policy for Certbot or cert-manager using Route53:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "route53:GetChange",
      "Resource": "arn:aws:route53:::change/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "route53:ChangeResourceRecordSets",
        "route53:ListResourceRecordSets"
      ],
      "Resource": "arn:aws:route53:::hostedzone/Z1234567890ABCDEF",
      "Condition": {
        "ForAllValues:StringEquals": {
          "route53:ChangeResourceRecordSetsNormalizedRecordNames": [
            "_acme-challenge.example.com"
          ],
          "route53:ChangeResourceRecordSetsRecordTypes": [
            "TXT"
          ]
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "route53:ListHostedZonesByName",
      "Resource": "*"
    }
  ]
}

Notice the Condition block: this credential can only modify TXT records named _acme-challenge.example.com. Even if the server is fully compromised, the blast radius is contained.

Preventing Rogue Issuance with CAA Records

Shadow IT is a massive problem. Developers might spin up unauthorized endpoints and issue Let's Encrypt certificates for them. To maintain control over your PKI, implement Certificate Authority Authorization (CAA) DNS records.

A CAA record tells the world which CAs are allowed to issue certificates for your domain. By setting this record, you ensure that even if someone compromises a subdomain, they cannot use a different CA to issue a trusted certificate.

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issuewild "letsencrypt.org"
example.com.  IN  CAA  0 iodef "mailto:security@example.com"

Handling Let's Encrypt Rate Limits Like a Pro

When building and testing your automation pipelines, you will inevitably make mistakes. Let's Encrypt enforces strict rate limits to protect their infrastructure—most notably, a limit of 50 certificates per registered domain per week. Hitting this limit during a CI/CD pipeline test means you cannot issue production certificates for a week.

The Solution: Always configure your ACME clients to use the Let's Encrypt Staging Environment during setup and testing. The staging environment has vastly higher rate limits, though the certificates it issues are not trusted by browsers.

The staging directory URL is