Remember when SSL certificates lasted three years?
Pepperidge Farm remembers.
In 2020, Apple decided that was too easy. Now we're heading toward 47-day certificates. Not 45. Not 50. Forty-seven days, because apparently Apple's random number generator picked that one.
Let me walk you through the timeline of how we got here, and why your 2027 is about to become certificate renewal hell.
The Timeline to Madness
The Good Old Days (Pre-2020)
Certificate Lifespan: 3 years (1,095 days)
Life was simple. You'd buy a certificate, install it, set a calendar reminder for 2.5 years later, then forget about it. Sure, sometimes that reminder got lost and production went down, but that was a once-every-three-years problem.
My team managed 200+ certificates this way. One spreadsheet. Quarterly reviews. Bob from accounting could handle renewals. It worked.
September 2020: The First Cut
Certificate Lifespan: 1 year (398 days)
Apple announces at their developer conference that Safari will only trust certificates issued for 398 days or less. Not 365 days like a normal year. 398 days, because Apple.
Google immediately agrees. Mozilla follows. The certificate authorities cave within weeks.
Suddenly, your annual renewal process needs to happen... annually. Revolutionary.
March 2026: The Plot Thickens
Certificate Lifespan: 200 days
"Why stop at one year?" asks someone at Apple who clearly doesn't manage certificates.
Next March—that's in 6 months, people—we drop to 200 days.
200 days. That's a renewal every six and a half months. Your nice quarterly review process? Useless. That junior developer who "figured out the cert stuff"? They're now spending 15% of their time on certificates.
March 2027: Getting Ridiculous
Certificate Lifespan: 100 days
A renewal every three months. Four times a year. Per certificate.
Got 100 certificates? That's 400 renewals annually. That's more than one renewal every single working day.
March 2029: Peak Insanity
Certificate Lifespan: 47 days
Forty. Seven. Days.
Why 47? Who knows. Maybe someone at Apple lost a bet. Maybe it's a Hitchhiker's Guide reference. Maybe they just hate us.
At 47 days, you're renewing certificates eight times per year. Per certificate.
Let's do the math that Apple apparently didn't:
- 100 certificates × 8 renewals = 800 renewal events per year
- 800 renewals ÷ 250 working days = 3.2 renewals every single day
- Zero room for error
- Zero time for vacation
- Zero patience left
The Operational Reality Nobody's Talking About
Manual Processes Are Dead
That runbook where you SSH into servers and copy certificates? Dead.
The Ansible playbook Jim wrote in 2019? Dead.
At 47-day intervals, a single failure cascades immediately. Miss one renewal because someone's on vacation? You've got 47 days to catch it. Except you won't, because certificate #2 is expiring tomorrow, and #3 the day after that.
Change Windows Become Impossible
"We only deploy on Tuesdays between 2-4 PM after CAB approval."
Cool story. Your certificates expire when they expire. That carefully planned change management process? It's about to meet the reality of 8x more certificate deployments.
Your options:
- Get blanket approval for certificate renewals (good luck with that audit)
- Automate everything (should've started yesterday)
- Watch everything burn (honestly, might be easier)
The Hidden Costs Multiply
Every certificate renewal isn't just swapping a file:
- Load balancer configs need updating
- CDN certificates need propagation
- Service restarts risk downtime
- Monitoring needs to verify the update
- Documentation needs to reflect changes
At 47 days, you're doing this dance constantly. Forever. Until you die or change careers.
The Tools Are Not Ready
Your $50,000/year monitoring platform that "supports everything"? Doesn't support 47-day automated rotation.
Your enterprise load balancer? Manual process only.
Your CDN? API supports updates, but rate-limits you to 10 changes per month.
Your managed Kubernetes service? Actually, they're probably fine. But everything else is screwed.
What This Actually Means for Your Team
Staffing Reality
At 47-day certificates, certificate management becomes a full-time job. Not hyperbole. Actual math:
- 200 certificates × 8 renewals × 30 minutes per renewal = 800 hours/year
- That's 0.4 FTE just for basic renewals
- Add troubleshooting, failures, and coordination: 1.0 FTE minimum
Congratulations, you're hiring a Certificate Engineer. That's a real job title now.
Automation Isn't Optional Anymore
"We'll automate it eventually" becomes "We automate it or we die."
But here's what automation actually means:
- Rewriting deployment pipelines
- Updating every system configuration
- Building certificate discovery tools
- Creating fallback procedures
- Testing failure scenarios
- Training everyone on the new process
Conservative estimate: 6-12 months of engineering work. For certificates. The things that used to just work.
The Path Forward (Since Apple Won't Stop)
Option 1: Full Automation or Death
Invest heavily now. And I mean now. Not next quarter. Not after the current sprint.
Build certificate automation that:
- Handles every system, not just the easy ones
- Fails gracefully with automatic rollbacks
- Alerts intelligently without noise
- Scales to thousands of certificates
- Works with your legacy nightmare systems
Option 2: Managed Certificate Services
Give up. Pay someone else. Let it be their problem.
Whether it's your CDN provider, a managed certificate service, or something we built because we're equally frustrated, the point is: stop pretending this is sustainable.
Option 3: Proxy Everything
Put all your certificates at the edge. Cloudflare, Akamai, whatever. Let them handle the 47-day nonsense. Your internal systems keep their self-signed certs that last forever.
Not elegant. Not ideal. But it works.
The Part Where I Stop Complaining and Admit Reality
Look, I get it. Shorter certificate lifespans increase security. Compromised certificates have less time to cause damage. Automated systems are more reliable than manual processes. In theory.
But theory and practice are only the same in theory.
In practice, we're forcing massive operational changes on an industry that still runs COBOL in production. We're expecting perfect automation from companies that can barely keep their primary systems running. We're creating complexity that will cause more outages than it prevents.
Your Action Items for This Week
- Count your certificates. All of them. Including that test server everyone forgot about.
- Calculate your renewal burden. Multiply by 8 for the 2027 reality.
- Start the automation discussion. Today. Not tomorrow.
- Budget for tooling. You're going to need it.
- Update your resume. Just in case.
The 47-day certificate apocalypse is coming whether we're ready or not. Apple's decided. Google's agreed. The certificate authorities are implementing it.
We built CertKit because we saw this coming and decided to do something about it. But whether you use our solution, build your own, or just pray to the certificate gods, you need to act now.
Because in 2029, while you're renewing certificates for the third time this month, remember: Apple thinks this is making the internet "more secure."
Sure it is.
How are you preparing for 47-day certificates? Drop your horror stories and survival strategies in the comments. Misery loves company, and we certificate wranglers need all the help we can get.
Top comments (1)