Let's Encrypt — the free certificate authority that secures hundreds of millions of domains — has announced that beginning February 2027, all newly issued certificates will carry a 64-day validity period by default, down from the 90-day certificates organizations have built their renewal workflows around for a decade. This is an intermediate step toward an even shorter 45-day validity period, aligning with the CA/Browser Forum Baseline Requirements ballot that progressively shrinks maximum TLS certificate lifespans across the entire public PKI ecosystem.
This is not a vulnerability announcement, but make no mistake: it is an operational security event with real defensive consequences. In my 15 years of IR and SOC work, expired certificates have caused more self-inflicted outages — and more emergency change-control exceptions that weakened security posture — than many CVEs. When certificate lifespans compress from 90 days to 64, and eventually to 45, every manual renewal process, every calendar reminder, and every undocumented cert on a forgotten appliance becomes a ticking outage. Worse, expiry incidents create pressure to bypass TLS validation, stand up unencrypted fallbacks, or grant emergency firewall exceptions — exactly the kind of improvised weakening attackers exploit.
Organizations that treat this as a routine operational footnote will learn about it the hard way in February 2027: when web front ends, API gateways, VPN concentrators, mail servers, and IoT fleets begin failing TLS handshakes at 2 a.m.
Technical Analysis
What Is Changing
- February 2027: All newly issued Let's Encrypt certificates default to 64-day validity (down from 90 days).
- Subsequent phase: Let's Encrypt is preparing for a 45-day validity period, consistent with the CA/Browser Forum's industry-wide schedule for reducing maximum certificate lifespans (which steps down in stages toward ~47 days by 2029 for all publicly trusted CAs).
- Shorter-lived certificates are not new for Let's Encrypt — short-lived certs have been available on an opt-in basis — but 2027 makes short validity the default for everyone, including legacy ACME clients and integrations that were configured years ago and forgotten.
Why the Industry Is Doing This
From a defender's perspective, shorter certificate lifespans are genuinely good security hygiene:
- Reduced compromise window. A stolen private key is only useful to an attacker for the certificate's remaining validity. 45 days versus 398 days dramatically shrinks the window for adversary-in-the-middle abuse.
- Weakness of revocation. CRL and OCSP revocation checking is inconsistently enforced by browsers and clients. Short validity is a pragmatic substitute for broken revocation — an expired cert dies on its own.
- Faster ecosystem remediation. When crypto algorithms or CA practices need to change (key sizes, signature algorithms, post-quantum transitions), short-lived certs roll the entire ecosystem forward automatically.
Where Organizations Will Break
The operational risk concentrates in places where renewal was never fully automated:
- Legacy ACME clients pinned to old versions, with deprecated challenge types or broken cron jobs that have been silently failing (tolerable at 90 days, fatal at 45).
- Non-ACME issuance paths: certificates manually downloaded from a CA portal and installed by hand on load balancers, F5/NetScaler appliances, or embedded devices.
- Internal services using Let's Encrypt via DNS-01 where API tokens for DNS providers have expired or been rotated.
- Vendor appliances and IoT with hardcoded renewal assumptions or no automation hooks at all.
- Kubernetes ingress cert-manager deployments running outdated versions with rate-limit or webhook issues.
- Monitoring gaps: no certificate inventory, no expiry alerting, no ownership mapping.
Exploitation Status
There is no CVE and no active exploitation associated with this announcement. The threat model is operational: expired certificates causing service outages, TLS validation bypasses introduced under outage pressure, and attackers phishing or intercepting users conditioned to click through certificate warnings. Treat this as a resilience and PKI-hygiene engagement, not a patch cycle.
Detection & Response
You cannot detect a policy change — but you can, and must, detect the symptoms: TLS validation failures, expired-certificate errors in service logs, and unmanaged certificate artifacts on endpoints. The detections below target the failure modes this change will trigger.
SIGMA Detection
---
title: TLS Certificate Expiration or Validation Errors in Application Logs
id: 3f8a2c14-9b7d-4e61-a5c9-2d4f6b8a0c1e
status: experimental
description: Detects TLS certificate expiration and validation failure strings in application and service logs, indicating expired or untrusted certificates that may result from shortened certificate validity periods or failed automated renewals.
references:
- https://letsencrypt.org/
- https://www.securityweek.com/lets-encrypt-cuts-default-certificate-validity-to-64-days-ahead-of-45-day-switch/
author: Security Arsenal
date: 2026/06/10
tags:
- attack.defense_evasion
- attack.t1553
logsource:
category: application
detection:
selection:
Message|contains:
- 'certificate has expired'
- 'certificate verify failed'
- 'SSL certificate problem'
- 'tls: expired certificate'
- 'x509: certificate has expired'
- 'ERR_CERT_DATE_INVALID'
- 'UNABLE_TO_VERIFY_LEAF_SIGNATURE'
falsepositives:
- Development and test environments with intentionally expired certificates
- Third-party service integrations failing due to upstream certificate issues
level: medium
KQL Hunt (Microsoft Sentinel / Defender)
This query hunts syslog and network-device telemetry for certificate expiration and validation failures — the first observable signal that a renewal pipeline has broken under compressed validity windows. Baseline it now so the 2027 spike is visible instantly.
let certErrors = dynamic(["certificate has expired","certificate verify failed","SSL certificate problem","expired certificate","x509: certificate","certificate is not yet valid","tls handshake failure"]);
union isfuzzy=true
(Syslog
| where SyslogMessage has_any (certErrors)
| project TimeGenerated, Computer, Facility, SeverityLevel, ProcessName, SyslogMessage, Type),
(CommonSecurityLog
| where Message has_any (certErrors)
| project TimeGenerated, Computer=DeviceName, Facility=DeviceVendor, SeverityLevel=LogSeverity, ProcessName=ApplicationProtocol, SyslogMessage=Message, Type)
| summarize ErrorCount = count(), SampleMessage = take_any(SyslogMessage) by Computer, ProcessName, bin(TimeGenerated, 1h)
| where ErrorCount > 5
| order by TimeGenerated desc
Velociraptor VQL Hunt
This artifact inventories Let's Encrypt certificate material and ACME client installations across endpoints — the discovery step for finding unmanaged renewal paths before they fail.
-- Inventory Let's Encrypt certificate files and ACME client artifacts
SELECT FullPath, Mtime, Size,
Mtime < timestamp(epoch=now() - 86400*30) AS RecentlyModified
FROM glob(globs=[
'/etc/letsencrypt/live/*/cert.pem',
'/etc/letsencrypt/renewal/*.conf',
'/root/.acme.sh/*/*.cer',
'/home/*/.acme.sh/*/*.cer',
'C:/ProgramData/win-acme/**/Configuration/*.json',
'C:/Certbot/live/*/cert.pem'
], accessor='file')
-- Separately, identify ACME client processes that should be running renewals
SELECT Pid, Name, CommandLine, Exe, Username
FROM pslist()
WHERE Name =~ '(?i)certbot|acme|lego|win-acme|wacs|posh-acme'
OR CommandLine =~ '(?i)letsencrypt|acme.sh|certbot renew'
Renewal Readiness Audit Script
Run this against your public-facing endpoints to identify certificates expiring within the new 64-day window — anything on this list after February 2027 represents a service one renewal failure away from outage.
#!/bin/bash
# audit-cert-expiry.sh - Audit TLS certificate expiry against 64-day validity threshold
# Usage: ./audit-cert-expiry.sh domains.txt
# domains.txt format: one host:port per line (port optional, defaults to 443)
THRESHOLD_DAYS=64
DOMAINS_FILE="${1:-domains.txt}"
while IFS= read -r entry; do
host="${entry%%:*}"
port="${entry##*:}"
[ "$port" = "$host" ] && port=443
enddate=$(echo | openssl s_client -servername "$host" -connect "${host}:${port}" 2>/dev/null \
| openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
if [ -z "$enddate" ]; then
echo "[ERROR] $host:$port - could not retrieve certificate"
continue
fi
exp_epoch=$(date -d "$enddate" +%s 2>/dev/null || date -j -f "%b %d %T %Y %Z" "$enddate" +%s)
now_epoch=$(date +%s)
days_left=$(( (exp_epoch - now_epoch) / 86400 ))
issuer=$(echo | openssl s_client -servername "$host" -connect "${host}:${port}" 2>/dev/null \
| openssl x509 -noout -issuer 2>/dev/null)
if [ "$days_left" -le "$THRESHOLD_DAYS" ]; then
echo "[ACTION REQUIRED] $host:$port expires in $days_left days ($enddate) | $issuer"
else
echo "[OK] $host:$port expires in $days_left days"
fi
done < "$DOMAINS_FILE"
Remediation: Preparing for 64-Day and 45-Day Certificates
1. Build a Complete Certificate Inventory Now
You cannot automate what you haven't found. Enumerate every certificate in your environment — public-facing TLS, internal services, mail (STARTTLS), VPN, RADIUS/802.1X, code signing, Kubernetes ingresses, cloud load balancers, and vendor appliances. Map each certificate to an owner, a renewal method, and a dependency. The Velociraptor hunt and Bash audit above are starting points; supplement with your CA's issuance logs and passive DNS data.
2. Mandate ACME Automation — Everywhere
At 64 days (and certainly at 45), manual renewal is operationally impossible. Every Let's Encrypt certificate in your estate must renew via ACME without human involvement:
- Standardize on maintained ACME clients: certbot, acme.sh, lego, win-acme (Windows), cert-manager (Kubernetes), or your load balancer's native ACME integration (most modern F5, NetScaler, HAProxy, and cloud LB platforms support it).
- Renew early: configure renewal at ~50–60% of validity (e.g., renew day 30–35 of a 64-day cert) so a transient failure leaves weeks of runway.
- Prefer DNS-01 with API automation for wildcard certs and non-public services; verify DNS provider API credentials are vaulted, rotated, and monitored.
- Eliminate portal-download workflows. If a vendor appliance cannot consume ACME or an API-driven cert pipeline, escalate to the vendor now or plan its replacement — it will be unmaintainable in the 45-day era.
3. Test the Failure Modes Before 2027
Use the Let's Encrypt staging environment to validate your renewal pipeline end-to-end. Then deliberately break it — revoke DNS API tokens, block outbound ACME traffic — and confirm your monitoring fires. Opt into Let's Encrypt's short-lived certificates ahead of the mandate as a dress rehearsal: if your automation handles 64-day renewals today, February 2027 is a non-event.
4. Instrument Expiry Alerting Independent of the Renewal Tool
Never trust the renewal client to report its own failure. Deploy independent, external certificate monitoring (synthetic TLS checks, the KQL hunt above, or a dedicated cert-monitoring platform) with alerts at 30, 14, and 7 days to expiry, routed to an on-call owner — not a shared mailbox.
5. Harden Against the Human Factor
- Enforce HSTS and certificate-transparency monitoring so users and admins can't casually click through expiry warnings — and so you detect rogue issuance for your domains.
- Lock down CAA records to restrict which CAs may issue for your domains.
- Update incident runbooks: certificate expiry incidents must be resolved by fixing automation, never by disabling TLS verification, installing self-signed certs, or punching plaintext fallbacks.
6. Engage Vendors and Third Parties
Inventory every third-party integration, SaaS webhook, and B2B connection that depends on your certificates (or theirs). Confirm vendors' roadmaps for automated cert lifecycle management. Organizations with PCI-DSS, HIPAA, or NIST CSF obligations should document this transition in their asset management and configuration management controls — auditors will ask.
The Bottom Line
The move to 64-day certificates in February 2027 — and 45-day certificates after that — is good for the security of the internet and survivable for organizations with mature automation. It is an extinction-level event for manual certificate management. The defensive work starts now: inventory, automate, monitor independently, and rehearse failure. Teams that do this will never notice the change. Teams that don't will meet it in a bridge call at 2 a.m.
Related Resources
Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.