Redirect Infrastructure Checklist for the 45-Day Certificate Era

SSL certificate lifetimes are about to be cut in half. Let's Encrypt — which powers 60% of all web certificates — is moving from 90-day to 45-day maximum certificate lifetimes. Google's CA/Browser Forum proposal mirrors this direction. The entire certificate industry is pushing toward shorter lifetimes as a security standard, and the timeline is no longer theoretical.

For teams managing redirect infrastructure across hundreds or thousands of domains, this isn't a minor adjustment — it's an operational multiplier. What required 4 renewal cycles per domain per year will soon require 8. Manual processes that barely worked at 90 days will fail completely at 45.

This checklist is designed to help infrastructure teams assess their readiness across six critical domains: automation, monitoring, renewal timing, alerting, wildcard strategy, and disaster recovery. Each section includes a self-assessment question and a target state. By the end, you'll have a clear picture of where your infrastructure stands — and what needs to change before the 45-day era arrives.

1. Automation: Zero-Touch Certificate Lifecycle#

The single most important question in your readiness assessment: Is every certificate issued and renewed without human intervention?

If the answer is anything other than an unqualified 'yes,' you have a problem. At 45-day lifetimes, manual certificate operations become unsustainable at surprisingly small scales. A portfolio of just 50 domains requires 400 certificate operations per year — more than one per day, every day, including weekends and holidays.

Current state self-assessment: How does your team handle certificate provisioning today? If the answer involves calendar reminders, spreadsheets, manual CSR generation, or 'someone usually handles it,' you're in the manual tier. Even if you've scripted parts of the workflow, ask whether the script covers every domain, handles every edge case, and recovers from every failure without human escalation.

Target state: Every hostname in your redirect infrastructure auto-provisions SSL via ACME the moment DNS is configured. Certificate issuance, installation, and renewal happen without any human action. The system detects new domains, validates ownership via DNS-01 challenge, requests the certificate, installs it across edge nodes, and schedules the next renewal — all within seconds of the hostname being added.

A redirect platform that manages SSL per hostname — rather than requiring you to manage certificates per server — eliminates the automation gap entirely. When DNS is delegated to the platform, SSL becomes a property of the infrastructure, not a task on someone's to-do list.

2. Monitoring: Know Before It Breaks#

Ask yourself: Do you have active certificate expiry monitoring across all domains?

Monitoring is the safety net underneath automation. Even with ACME-based renewal, things can go wrong: a DNS record changes, a rate limit triggers, a CA experiences an outage. Without monitoring, you discover expired certificates the same way your users do — through a browser warning.

But monitoring isn't just about checking expiry dates. Effective monitoring for redirect infrastructure means health checks from multiple global locations, because a certificate that appears valid from your office might fail from a user's location due to edge propagation delays or CDN caching.

Current state self-assessment: Do you have a dashboard or alerting system that shows certificate expiry dates for every domain? Is it updated in real time when certificates are renewed? Can you see at a glance which domains are approaching expiry and which have already failed?

Target state: Continuous certificate health monitoring from multiple global edge locations. The system performs active TLS handshake checks — not just expiry date lookups — to verify that every certificate is valid, trusted, and serving correctly. Dashboard shows real-time status across all domains. Monitoring is automatic: when a new hostname is added, monitoring starts without configuration.

3. Renewal Timing: The Buffer Zone#

The question: Are renewals attempted early enough to survive multi-day outages?

With 90-day certificates, renewing 7-14 days before expiry provided a comfortable buffer. With 45-day certificates, the same buffer eats 15-30% of the certificate's total usable lifetime. The math forces a trade-off: renew too early and you're constantly cycling certificates; renew too late and a temporary CA outage becomes a production incident.

Let's Encrypt rate limits add another dimension. The Duplicate Certificate limit allows 5 certificates per week for the same set of hostnames, and the Certificates per Registered Domain limit caps at 50 per week. At 45-day renewal cycles, large domain portfolios can approach these limits faster than expected — especially if you're also provisioning certificates for new domains.

Current state self-assessment: What is your renewal window? If your team renews certificates manually, are renewals started at least 15 days before expiry? Can you survive a 5-day CA outage without any certificate expiring? Have you tested what happens when a renewal attempt fails — does the system retry automatically or does it wait for human intervention?

Target state: Automated renewals begin 30 days before expiry with exponential backoff retry logic. If the first attempt fails, the system retries at increasing intervals — 1 hour, 4 hours, 12 hours, 24 hours — until the renewal succeeds. Rate limits are tracked and respected automatically. The system can survive a multi-day CA outage without any domain reaching its expiry date, because renewals started early enough that there's always at least 15 days of buffer.

4. Alerts: Before, Not After#

The question: Do the right people get notified before — not after — certificate expiry?

Alerting is the difference between a non-event and an incident. When a certificate renewal fails, two things need to happen: the system retries automatically (see section 3), and the right person knows about it. If your monitoring detects an expired certificate without alerting anyone, you still have a gap — you're just finding out about it faster.

Alerting should be tiered by severity and audience. A failed renewal that retries successfully 30 minutes later doesn't need a 2 AM page — but it should show up in a daily digest. A certificate approaching its final 72 hours without successful renewal is a critical alert that should reach the on-call engineer immediately.

Current state self-assessment: Who gets notified when a certificate is about to expire? Is there a tiered alerting system with different severity levels? Do alerts go to the right channels (Slack, email, PagerDuty) based on urgency? If the primary on-call person is unavailable, does the alert escalate?

Target state: Three-tier alerting: Info (renewal attempted, daily digest), Warning (renewal failed, 7-day window, Slack/email), Critical (renewal failed repeatedly, 72-hour window, PagerDuty/on-call escalation). Alerts include domain name, certificate expiry date, last renewal attempt time, and failure reason. Every domain in the portfolio is covered — no exceptions, no 'we'll monitor that one manually.'

5. Wildcard Certificates: Convenience vs. Risk#

The question: Are wildcard certificates handled correctly or creating single points of failure?

Wildcard certificates are tempting: one certificate for *.example.com covers every subdomain. One renewal. One expiry date. One thing to manage. But that 'one thing to manage' is also one thing that can fail — and when it does, every subdomain goes dark simultaneously.

For redirect infrastructure specifically, wildcards create another problem: DNS-01 challenges for wildcard certificates require access to the apex domain's DNS zone. If your redirect domains are spread across multiple registrars and DNS providers — common in large portfolios — managing DNS-01 challenges for a single wildcard becomes significantly more complex than managing per-hostname certificates.

Current state self-assessment: Are you using wildcard certificates for redirect domains? If the wildcard certificate fails to renew, how many domains are affected? Do you have a tested rollback plan? Are wildcards managed by the same team that manages per-domain certificates, or are they separate processes with different owners?

Target state: Per-hostname certificates are the default. Each domain gets its own certificate, provisioned and renewed independently. This provides isolation: a renewal failure on one domain doesn't affect any other. Wildcards are used only where explicitly needed (e.g., internal services behind a shared subdomain), with separate monitoring and alerting — and a documented, tested recovery procedure.

6. Disaster Recovery: When the CA Goes Down#

The question: If your Certificate Authority is unavailable for 5 days, do your certificates survive?

Let's Encrypt has experienced multi-hour outages in the past. At 90-day certificate lifetimes, a 2-3 day outage was manageable — certificates had enough remaining validity to ride it out. At 45 days, the same outage can push certificates past their renewal window before the CA comes back online.

Disaster recovery for SSL isn't just about the CA. It's about DNS — if your DNS provider has an outage during a DNS-01 challenge window, the challenge fails and the renewal is blocked. It's about edge propagation — if a renewed certificate doesn't propagate to all edge nodes before the old one expires, some users see errors. And it's about the renewal pipeline itself — if your automation platform has an outage, do renewals queue or get dropped?

Current state self-assessment: Have you modeled what happens during a 5-day CA outage? What's your shortest certificate validity window across the portfolio? Do you have a fallback CA configured, or are all certificates tied to a single provider? Can your DNS infrastructure survive an outage during a challenge window?

Target state: Certificates are renewed early enough that every domain maintains at least 15 days of buffer — enough to survive a realistic CA outage. The renewal pipeline is resilient: if a renewal fails due to CA unavailability, the system retries automatically when the CA recovers. Monitoring covers the entire dependency chain (DNS, CA, edge propagation), not just certificate expiry dates. Fallback CAs are configured for critical domains, and the team has a documented, tested runbook for manually provisioning certificates during extended CA outages.

Self-Assessment: Score Your Readiness#

Rate your infrastructure on each of the six domains below. Be honest — a low score isn't a failure, it's a roadmap.

Scoring: 1 = Manual / No capability, 2 = Partially automated / Gaps exist, 3 = Mostly automated / Minor gaps, 4 = Fully automated / No gaps, 5 = Fully automated + tested / Resilient

Interpreting your total:

24-30: You're ready. Your infrastructure is automated, monitored, and resilient. Focus on maintaining this state and testing your recovery procedures regularly.

18-23: You have solid foundations but gaps remain. Prioritize the 'Critical' domains first — automation and renewal timing are the highest-ROI improvements. A 45-day timeline will stress your current setup.

12-17: Your infrastructure is not ready for 45-day certificates. Manual processes that work at 90 days will break at 45. Start with automation (domain ①) — if you only fix one thing, make it automatic certificate provisioning and renewal.

6-11: You're at high risk. Every domain in your portfolio is vulnerable to a single missed calendar reminder or CA outage. Consider moving to a redirect platform that handles SSL automation as infrastructure — not as a task — to close the gap quickly.

The Gap Only Gets Wider#

The 45-day certificate era isn't a future possibility — it's an industry trajectory with a defined timeline. Let's Encrypt, which issues certificates for over 360 million domains, is leading the shift. Google's CA/Browser Forum proposal mirrors the same direction. The standard is moving, and the gap between automated and manual infrastructure only widens as certificate lifetimes shrink.

The teams that automate now won't feel the shift. They'll watch their dashboards show renewals completing on schedule — 30 days early, every time, across every domain — while others scramble to update spreadsheets. The checklist above isn't just an assessment tool. It's a roadmap to infrastructure that's ready for whatever certificate lifetime the industry settles on — 45 days, 30 days, or shorter.

Score your infrastructure. Fix the gaps. The 45-day certificate era is coming — your redirect domains should be the last thing you worry about.