The Ops Community ⚙️: CertKit

How to Audit Your Domain's Certificate History (And Why You Should Be Terrified)

Todd H. Gardner — Tue, 28 Oct 2025 18:45:14 +0000

You probably have no idea how many SSL certificates exist for your domains. Or who has them.

Most ops teams track the certificates they issue. Nobody tracks the certificates they didn't issue. The ones from your previous CDN. Your former hosting provider. That contractor who left six months ago. They're all still out there. Still valid.

The BygoneSSL research found 1.5 million domains with valid certificates owned by the wrong people. Your domains are probably in that list.

Time to find out.

Start with Certificate Transparency Logs

Every publicly trusted certificate gets logged. That's good news. It means you can find them.

Go to CertKit Certificate Search and search for your domain. You want to see everything. Not just valid certs. Everything.

What you'll find will make you uncomfortable.

I searched for a client's domain last week. Found over 100 certificates. They knew about 3.

The rest? Old hosting providers. Development agencies. That "quick test" someone ran with Let's Encrypt. A wildcard certificate from their previous CDN that doesn't expire until 2026.

Each one is a potential security incident.

The Vendors You Forgot About

Look at the issuer field for each certificate. See Let's Encrypt? Sectigo? DigiCert? Now ask yourself: who uses those CAs?

That Sectigo certificate from 2023? Probably your old CDN. Still valid for another 200 days.

The Let's Encrypt cert renewed every 90 days? Could be that staging server your contractor set up. The one that's supposedly decommissioned. Except someone's still renewing the certificate.

The DigiCert wildcard? Your previous hosting provider included it "free" with your plan. You moved providers. They kept the certificate.

Check the SANs (Subject Alternative Names)

This is where things get really fun. Multi-domain certificates.

Your domain might be bundled with 50 other domains on the same certificate. Maybe 500. I've seen CDN certificates with over 700 domains.

Here's why that matters: If any of those domains changes ownership, the new owner can revoke the entire certificate. Your site goes down because some random domain on your shared certificate got sold.

The Subdomain Problem

Wildcards are convenient. They're also dangerous.

That *.yourdomain.com certificate you issued two years ago? It works for every subdomain. Including the ones you delegated to vendors. The test environments you forgot about. The staging server that "doesn't exist anymore."

Search for these patterns in your CT logs:

*.yourdomain.com (wildcards)
staging.yourdomain.com
test.yourdomain.com
dev.yourdomain.com
Any vendor-specific subdomains

Each valid certificate is active infrastructure, whether you know about it or not.

Who Can Request Certificates?

This is the question nobody asks. Who can prove control of your domain?

Anyone with access to your DNS
Anyone receiving admin emails
Anyone who can place files on your web server
Anyone with access to your cloud account

That's a lot of people. Current employees. Former employees. Your DNS provider. Your CDN. Your hosting company.

They can all request certificates. Right now. And you won't know until you check the CT logs.

What To Do About It

You can't revoke certificates you don't control. Revocation barely works anyway. But you can minimize future damage.

Immediate steps:

Document every certificate you find. Note the expiration dates.
CAA records. Set them now. Lock down which CAs can issue certificates.
Monitor CT logs. Weekly at minimum. Daily is better. Or monitor them continuously with CertKit.
Rotate credentials after vendor changes. DNS passwords, cloud API keys, everything.

Long term fixes:

Short certificate lifespans. The 47 day certificates everyone's complaining about? They solve this problem. A certificate issued today expires before real damage happens.

Certificate automation. Manual processes can't track this. You need tools that discover, monitor, and manage certificates continuously.

Want to automate certificate discovery and monitoring? CertKit tracks every certificate for your domains, not just the ones you issued. Because the certificates you don't know about are the ones that hurt you.

Let's Encrypt Ate Everyone's Lunch: From 0% to 59% Market Share

Todd H. Gardner — Mon, 06 Oct 2025 21:13:49 +0000

Remember paying $300 for an SSL certificate?

Of course you do. It was 2015. You had a budget line item called "certificates." Purchasing needed three approvals. The renewal reminder went to Dave, who left six months ago.

Then Let's Encrypt showed up and chose violence.

The Numbers Don't Lie

2016: Let's Encrypt had 0.1% market share.
2024: 59%.

That's not growth. That's annihilation.

They didn't just disrupt the certificate industry. They ate it. While the traditional CAs were figuring out how to charge more for wildcard domains, Let's Encrypt was issuing millions of free certificates. Daily. With 90-day lifetimes that forced everyone to automate whether they liked it or not.

Which, surprise, is exactly what we needed for 47 day certificates.

The Business Model That Shouldn't Have Worked

Here's what Let's Encrypt proposed:

Free certificates
No phone support
No sales team
90-day expiration (not the 3-year cash cows)
API-only provisioning
Funded by... donations?

The CAs laughed. Actually laughed.

"Nobody will trust free certificates."
"Enterprises need hand-holding."
"90 days is too short."
"Automation is too complex for normal ops teams."

Turns out normal ops teams were already automating everything else. Adding one more API call? Not exactly rocket science.

The Part Nobody Talks About

Let's Encrypt didn't win because they were free.

They won because they removed the friction.

No sales calls. No "contact us for pricing." No validation documents. No account managers. No renewal reminders. No phone trees. No support tickets.

Just: Here's your cert. See you in 90 days.

We'd been so beaten down by the certificate industrial complex that we forgot what simple looked like.

certbot certonly --webroot -w /var/www/html -d example.com

Done. Cert issued. Automatically renewed until the heat death of the universe.

The Panic Was Delicious

Watch a $600 million industry realize it's been disrupted by a nonprofit:

2016: "It's just for hobbyists."
2017: "Enterprises will never adopt it."
2018: "Our Extended Validation certificates are superior."
2019: "We provide better support."
2020: "Our management platform is worth the cost."
2021: "Please?"

The best part? They started offering free certificates too. But with "premium features." Like what? Support for the free certificates that don't need support because they're automated?

DigiCert bought Symantec's certificate business for $950 million in 2017.

That same year, Let's Encrypt was running on a $2.5 million budget.

And winning.

They Fixed the Wrong Problem

The CAs spent years optimizing the wrong thing. Making certificate purchasing "easier." Building better dashboards. Adding more validation levels.

Let's Encrypt realized the problem wasn't purchasing.

It was that certificates existed at all.

Make them invisible. Make them automatic. Make them someone else's problem (specifically: nobody's problem).

Eight years later, Let's Encrypt issues certificates for most of the encrypted web. Your bank, your cloud provider, probably this blog.

All running on infrastructure that the "serious" CAs said would never work.

Turns out "never" is about 8 years in certificate time.

Why Every DevOps Team Has a Certificate Horror Story

Todd H. Gardner — Fri, 19 Sep 2025 15:40:45 +0000

The Certificate That Ruined Christmas

It was December 23rd, 4:47 PM. Sarah was halfway through her third glass of office party punch when her phone exploded. Production was down. Not slow. Not degraded. Dead.

The wildcard certificate had expired.

The one that covered *.api.company.com, *.admin.company.com, and seventeen other subdomains nobody documented. The renewal script? It had been failing silently for six weeks. The logs? Rotated into oblivion. The person who wrote it? Left for greener pastures in October.

Sarah spent Christmas Eve on a Zoom call with three other engineers, manually generating certificates while the CEO asked "how did this happen?" every fifteen minutes.

Every DevOps team has this story. The details change, but the pain is universal.

The Museum of Certificate Disasters

The Demo Day Special

Picture this: Your CEO is presenting to potential investors. Big screen. Lots of money in the room. Click to the product demo and—browser warning. "Your connection is not private."

Turns out that staging environment you spun up six months ago for "just this one demo"? Its certificate expired yesterday. The renewal was handled by Gary's laptop. Gary's in Bali. Gary doesn't check Slack on vacation.

The CEO improvises. The investors are "concerned about technical operations." You update your resume.

The Acquisition Surprise

Your company just acquired a smaller competitor. Congratulations! You now own:

47 domains nobody has a list of
Certificates from three different CAs
At least six that expired last year but "the sites still work somehow"
A WordPress multisite with a cert that expires tomorrow
No documentation

The previous team's solution? A spreadsheet on someone's desktop titled "certs_final_FINAL_v2_actually_final.xlsx". It was last updated in 2021.

The Prometheus Punishment

You built beautiful monitoring. Prometheus, Grafana, the works. Alerts for everything. CPU, memory, disk space, network latency, even that custom metric for coffee machine status.

The monitoring certificate expired on Tuesday.

Nobody knew because... the monitoring was down.

The Load Balancer Lottery

Three identical load balancers. Same config. Same automation. Same certificate renewal script.

Two renewed perfectly. The third didn't.

Why? Nobody knows. The logs show success. The script returned 0. The old certificate is still being served. You check everything twice. Time zones? Permissions? Phase of the moon?

Four hours later you manually replace it and add "investigate later" to a ticket that will never be investigated.

The Forgotten Fleet

That certificate scanner you ran last month found 73 certificates across your infrastructure. You manage 12 of them. The others?

The printer management interface (apparently it has HTTPS?)
Bob's development VM that's somehow internet-facing
A Grafana instance from a hackathon three years ago
The old CEO's vanity project that "we're definitely shutting down next month" for the past two years
Something called "test-server-do-not-delete-important"

Half expired already. The other half expire next month. None are in your renewal automation.

Why This Keeps Happening

We're smart people. We automate everything. We have CI/CD pipelines that would make NASA jealous. So why do certificates keep biting us?

Because certificate management exists in the gap between "too important to ignore" and "too boring to do right."

It's not exciting like Kubernetes. It's not trendy like observability. It's just... certificates. So we cobble together the minimum viable solution and promise to "revisit this next quarter."

Next quarter never comes. Until 4:47 PM on December 23rd.

The Universal Constants of Certificate Pain

Every certificate horror story shares the same elements:

It's always the one you forgot about. Never the main production cert you monitor obsessively. It's the Jenkins box. The VPN appliance. That API endpoint only accounting uses.

The person who knows is gone. They left for a startup. Or they're on parental leave. Or they just forgot because they set it up three years ago after four beers at the company offsite.

The documentation lies. If it exists at all. That runbook? It references servers that were decommissioned in 2020. The wiki page? Last updated by an intern who "thinks this is how it works."

It happens at the worst possible time. During the big demo. Black Friday. When you're on vacation. When the senior engineer is at a wedding. Murphy's Law was written about SSL certificates.

Breaking the Cycle

Here's the thing: we've all tried to fix this. We've written the scripts. Built the automation. Created the runbooks. Set up the monitoring.

But maintaining certificate infrastructure isn't your job. It's a distraction from your actual job. You didn't become a DevOps engineer to babysit OpenSSL.

That's why we keep having these disasters. We treat certificate management like a side project instead of the critical infrastructure it actually is. We wouldn't run our own power plant. Why are we running our own certificate authority?

Your Horror Story

Every DevOps engineer reading this is nodding along, remembering their own certificate disaster. The one that ruined a weekend. Or a holiday. Or a career.

Maybe it's time to stop collecting these war stories.

Maybe it's time to let someone else worry about whether the certificate renewal script will work next month.

Maybe it's time to stop playing certificate roulette and admit that some problems are worth paying someone else to solve.

But until then? Check your certificates. That Jenkins box is probably expiring next week.

Apple's 47-Day SSL Certificate Plan is Your Next On-Call Nightmare

Todd H. Gardner — Wed, 03 Sep 2025 21:09:04 +0000

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.