47-Day TLS Certificates: A Practical Preparation Playbook
The debate about shorter certificate lifespans is over. The CA/Browser Forum has ratified a phased reduction that ends at 47-day maximum TLS certificate validity. This is no longer a proposal to argue about. It is a deadline to prepare for.
Plenty of coverage explains why this is happening. This playbook is about what to do. It walks through the operational sequence, from knowing what you have, to automating renewal, to building the fallback plans that keep you online when automation fails, because at 47-day cadence, it eventually will.
If your certificate operations still involve a spreadsheet and a calendar reminder, this post is the migration plan away from that.
Renewal Workload Explosion
300 certificates: annual renewals & engineer hours as lifespans shrink
8×
More renewals at 47 days vs 1 year
1,200 hrs
= 0.6 FTE doing nothing but renewals
The Phased Timeline You Are Planning Against
The reduction happens in steps, not all at once. Each step compresses your renewal window further.
| Phase | Maximum TLS Validity | Renewals per Cert per Year |
|---|---|---|
| Today | 398 days | ~1 |
| Phase 1 | 200 days | ~2 |
| Phase 2 | 100 days | ~4 |
| Final | 47 days | ~8 |
The number that matters is the last column. A certificate you renew once a year today will need renewing roughly eight times a year at the final phase. That multiplier is what breaks manual processes.
The Math That Forces the Change
The workload increase is linear with certificate count and inversely proportional to lifespan. It compounds fast.
| Certificate Count | Renewals/Year at 398 days | Renewals/Year at 47 days | Renewals/Week at 47 days |
|---|---|---|---|
| 100 | 100 | ~780 | ~15 |
| 500 | 500 | ~3,900 | ~75 |
| 1,000 | 1,000 | ~7,800 | ~150 |
| 5,000 | 5,000 | ~38,800 | ~745 |
At 500 certificates, you go from renewing about ten certificates a week to seventy-five. Each manual renewal involves validation, issuance, deployment, and verification. Even at an optimistic 20 minutes each, 75 per week is 25 hours of pure certificate work, every week, for one team that also has other responsibilities.
Manual renewal does not scale to this. The playbook below is how you get out of manual.
Phase 1: Know What You Have (Weeks 1 to 3)
You cannot automate renewal for certificates you do not know exist. Inventory is the prerequisite for everything else, and it is where most teams discover their real problem: they have far more certificates than they thought.
Discover External Certificates
Certificate Transparency logs record every publicly-trusted certificate ever issued for your domains. Query them to find certificates you forgot about.
# Find every publicly-logged certificate for your domain
curl -s "https://crt.sh/?q=%25.example.com&output=json" | \
jq -r '.[].common_name' | sort -u > external-certs.txt
echo "Unique names found in CT logs: $(wc -l < external-certs.txt)"Scan Active Endpoints
CT logs show what was issued. Active scanning shows what is actually deployed and when it expires.
#!/bin/bash
# Check live expiry for a list of hosts
while read host; do
expiry=$(echo | timeout 5 openssl s_client -connect "$host:443" \
-servername "$host" 2>/dev/null | \
openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
[ -n "$expiry" ] && echo "$host,$expiry"
done < external-certs.txt > cert-expiry-inventory.csvBuild the Ownership Map
For each certificate, record: the hostname and all SANs, the CA that issued it, the expiry date, the current renewal method (manual, automated, or unknown), and the owner who gets paged when it expires. The “unknown” and “manual” rows are your automation backlog.
Phase 2: Automate Renewal (Weeks 3 to 10)
The only sustainable answer to 47-day certificates is automation. The mechanism depends on where the certificate lives.
ACME for Everything That Supports It
The ACME protocol (RFC 8555) handles domain validation, issuance, and renewal without human involvement. It is no longer just Let’s Encrypt, commercial CAs including DigiCert, Sectigo, and Entrust support ACME endpoints.
# certbot with automatic renewal via systemd timer
sudo certbot certonly --standalone -d api.example.com \
--deploy-hook "systemctl reload nginx"
# Confirm the renewal timer is active
systemctl list-timers | grep certbot
# Dry-run to prove renewal works before relying on it
sudo certbot renew --dry-runcert-manager for Kubernetes
In Kubernetes, cert-manager renews automatically. The key setting for short lifespans is renewBefore, which should be a healthy fraction of the total lifetime so transient failures have time to retry.
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: api-tls
namespace: production
spec:
secretName: api-tls-secret
duration: 1128h # 47 days
renewBefore: 360h # renew 15 days early, leaves retry headroom
issuerRef:
name: letsencrypt-prod
kind: ClusterIssuer
dnsNames:
- api.example.comThe Awkward Middle: Things ACME Cannot Reach
Load balancers, network appliances, legacy Java keystores, and third-party SaaS portals often cannot run an ACME client. These are the certificates that will cause your outages at 47-day cadence, because they stay manual while everything around them automates.
For these, you need either a CLM platform that pushes certificates to them via vendor APIs, or a documented, owned, monitored manual process with alerts far enough in advance to act. At 47 days, a 30-day advance alert leaves very little slack, so tighten alerting for anything that stays manual.
Phase 3: Monitor Like You Mean It (Weeks 8 to 12)
Automation without monitoring is a silent failure waiting to happen. At 47-day cadence, a broken renewal has days, not months, before it becomes an outage. Your monitoring must catch failures in hours.
# Prometheus blackbox exporter alerts for short-lived certs
groups:
- name: certificate_expiry
rules:
- alert: CertExpiringSoon
expr: probe_ssl_earliest_cert_expiry - time() < 86400 * 10
for: 1h
labels:
severity: warning
annotations:
summary: "Certificate on {{ $labels.instance }} expires within 10 days"
- alert: CertRenewalStalled
expr: probe_ssl_earliest_cert_expiry - time() < 86400 * 5
for: 1h
labels:
severity: critical
annotations:
summary: "Certificate on {{ $labels.instance }} under 5 days, renewal likely failed"The critical shift is that alert thresholds must compress along with the certificate lifespan. A 60-day warning is meaningless for a 47-day certificate. Align your alert ladder to the new reality: informational at 14 days, action-needed at 10, critical at 5.
Phase 4: Plan for When Automation Fails
At eight renewals per certificate per year, automation will occasionally fail. A DNS challenge times out, a CA rate-limits you, a deploy hook errors, a network path breaks. Mature operations plan for this instead of hoping it does not happen.
| Failure Mode | Detection | Fallback |
|---|---|---|
| ACME challenge fails | Renewal error in logs, expiry alert fires | Retry with alternate challenge type (DNS-01 vs HTTP-01) |
| CA rate limiting | Repeated issuance rejections | Stagger renewals, use a secondary CA |
| Deploy hook fails | New cert issued but old cert still served | Alert on serial mismatch between issued and deployed |
| Network path breaks | Endpoint unreachable during renewal | Manual issuance runbook, owned and documented |
The single most valuable practice is verifying deployment, not just issuance. A renewal that issues a new certificate but fails to deploy it looks successful in the CA logs while the server still serves the old, expiring certificate. Monitor the certificate actually being served, not just the one in your store.
# Verify the SERVED certificate matches the freshly issued one
served_serial=$(echo | openssl s_client -connect api.example.com:443 \
-servername api.example.com 2>/dev/null | \
openssl x509 -noout -serial | cut -d= -f2)
echo "Currently served serial: $served_serial"
# Compare against the serial your automation just issuedWhat Good Looks Like at 47 Days
An organization ready for 47-day certificates has these properties:
- Complete, continuously-updated inventory of every certificate, with an owner for each
- The large majority of certificates renewing automatically via ACME or a CLM platform
- The unavoidable manual exceptions documented, owned, and monitored with tight alerts
- Deployment verification, not just issuance confirmation
- An alert ladder compressed to match the 47-day window
- Tested fallback runbooks for renewal failure
Notice what is not on the list: heroics, calendar reminders, or a single person who remembers when things expire. The entire point of preparing for 47-day certificates is to remove humans from the routine renewal loop, so the compression from one renewal a year to eight becomes a configuration detail rather than a staffing crisis.
The Cost of Waiting
Every phase of the reduction that arrives before you automate makes the manual burden worse. Teams that start now automate calmly at today’s volume. Teams that wait automate under pressure, during outages, after a missed renewal has already taken down a customer-facing service. The work is the same either way. Only the circumstances differ.
The reduction is phased precisely so organizations have time to adapt. That time is the resource. Spending it on inventory and automation now is far cheaper than spending it firefighting later.
FAQ
Q: When do 47-day certificates take effect? The CA/Browser Forum ratified a phased reduction that steps down through 200-day and 100-day maximums before reaching the 47-day maximum. The intermediate phases arrive first, each one compressing the renewal window further, so preparation should not wait for the final deadline.
Q: Does the 47-day limit apply to internal certificates? The CA/Browser Forum rules govern publicly-trusted certificates. Internal certificates from a private CA (AD CS, Vault, step-ca) are not directly bound by them. In practice, auditors increasingly question why internal certificates have multi-year lifespans when the public standard is 47 days, so many organizations shorten internal lifespans and automate them too.
Q: Do I have to buy a CLM platform to handle this? Not necessarily. If your certificates are ACME-compatible and live on systems that can run an ACME client, open-source tooling like certbot and cert-manager can handle renewal for free. A CLM platform becomes worthwhile when you have hundreds of certificates, multiple CAs, and systems that cannot run ACME clients directly.
Q: What is the single most common cause of certificate outages under automation? Deployment failure after successful issuance. Automation issues a new certificate, but the deploy step fails and the server keeps serving the old one until it expires. Always monitor the certificate actually being served, not just the one your automation issued.
Q: How early should renewal be triggered for a 47-day certificate? A common target is renewing when about a third of the lifetime remains, roughly 15 days early. This leaves enough headroom to retry transient failures (DNS timeouts, CA rate limits) before the certificate actually expires.
About QCecuring
QCecuring helps enterprises prepare for short-lived certificates before the deadline forces the issue. Our platform continuously discovers every certificate across your infrastructure, automates renewal across multiple CAs, verifies deployment rather than just issuance, and compresses alerting to match the 47-day reality, so the shift to eight renewals a year is something your systems handle, not your on-call engineer.
Get ready for 47-day certificates
Tags: 47-Day Certificates, CA/Browser Forum, Certificate Lifecycle Management, CLM, TLS, Certificate Automation, ACME, certbot, cert-manager, Short-Lived Certificates, Certificate Renewal, Certificate Monitoring, PKI, Certificate Outage