We’ve got a boatload of features to show off this week. We knocked out some of the most common requests, user management, single-sign on, and my personal favorite: the weekly email summary.

User management and roles

You can now invite other users to your CertKit account. Administrators get full access. Regular Users get access to one or more application groups, so you can scope what each person can see and manage.

This pairs directly with the Applications feature we shipped in January. If you’ve organized your certificates into application groups already, you can now hand off management of specific groups to the right people without giving everyone the keys to everything.

Users also have a profile page where they can update their name and manage email preferences.

Plus, users can set up Multi-factor authentication with any TOTP authenticator app.

SAML single sign-on

If your organization runs an identity provider, you can now connect it to CertKit. Upload the metadata XML from your IdP and we’ll handle the rest. Your users authenticate through your existing SSO and you manage access from one place.

Weekly email summary

Every week, CertKit will send you a digest of your full account status: certificates, domain monitors, and agents, all in one view.

It’s the thing you’d build yourself if you had time. A quick look each week to make sure nothing is quietly heading toward expiration or already broken. Red means something needs attention. Green means you can move on.

All of these features are live now. If you’re on the beta, you’ll find them in your account settings. Sign up for CertKit to try it free, or book a demo if you want a walkthrough.

CertKit automates certificate lifecycle management so you can stop worrying about who owns the renewal process.

The bell rings. Last call for 398-day certificates is March 15.

After that, every CA is required to cut you off at 200 days. Some have already stopped serving them early. The rest follow in two weeks.

The irony of good certificate management is that when it works, nobody notices. No alerts, no outages, no 2am pages. The only time it gets attention is when something expires. Which means the teams doing it well rarely have the budget or the political capital to fix the process before it breaks.

March 15 is your excuse to fix it anyway. Here’s what to do before closing time.

The 200-day certificate deadline

A certificate issued this week gets you to early 2027, roughly 13 extra months compared to anything issued after the deadline. That’s one fewer renewal cycle to deal with right now, and enough time to get automation in place before the 100-day era arrives in March 2027. This isn’t about avoiding automation forever. It’s about doing it on your schedule instead of in a panic.

Here’s the schedule the CA/Browser Forum set with Ballot SC-081:

• March 15, 2026: 200-day maximum
• March 15, 2027: 100-day maximum
• March 15, 2029: 47-day maximum

A certificate issued after March 15 gets 200 days. The deadline is based on when the certificate is issued, not when you place the order.

The math on doing nothing

Here’s what manual certificate management looks like at each stage of the schedule. These are minimum renewals per certificate per year, assuming you renew right at expiration.

If you have 50 certificates and you’re still handling renewals manually in 2029, that’s 400 renewal events a year. That’s not a process anymore, that’s a fulltime job.

What are you going to do about it?

Go renew any commercial certificates you have. Right now, before March 15 jumps up at you. Even if certs aren’t close to expiring. This buys you time to figure out what to do next.

Do a search for certs you’ve forgotten about. A certificate discovery scan will show you the staging servers, internal tools, and other things you might have forgotten about. Go renew those certificates too.

Use the runway to fix the process. With your new certs, you have until 2027 to figure this out. Get started on a project plan. Figure out the budget you need. You need to figure this out before 100-day certs drop on March 2027.

CertKit can show you every certificate in your infrastructure, what’s expiring, and what you still have time to renew before March 15. Free during beta.

The CertKit Agent 1.6 is out. Three things in this release, all of them coming from the same underlying problem: the shorter certificate lifespans get, the more certificate deployment has to behave like real software deployments.

Microsoft RRAS

The CertKit Agent now supports Microsoft Routing and Remote Access Service (RRAS), which a lot of organizations use for point-to-point VPN.

RRAS is one of those things that’s been running quietly in the background for years, and nobody thinks about it until the certificate expires. At one-year validity that was annoying but manageable. At 47 days it becomes a recurring operations problem.

The wrinkle with RRAS is that it interrupts active connections when a certificate is updated. That’s fine when you’re renewing once a year. It’s a bigger deal when renewals are happening every six weeks.

Which brings us to the next feature.

Deploy windows

Deploy windows let you tell the agent when it’s allowed to renew certificates and run update commands on a given host. You pick the days and a time window. Renewals that happen outside that window will wait until the next allowed slot.

For RRAS and anything else that causes a service interruption during deployment, this means you can confine that disruption to a maintenance window. 2am Tuesday, Saturday morning, whatever fits your environment.

This works at the per-config level, so you can have different windows for different software, even on the same server.

Agent locking

This one is a security feature, and it’s worth explaining why we built it.

The CertKit Agent can run arbitrary commands on your servers. That’s the whole point. You configure a restart command, the agent runs it. It’s convenient, and it’s what makes automated deployment work.

But it also means that if CertKit were ever compromised, an attacker could modify that command through our UI and use the agent as a foothold into your infrastructure. We don’t plan on getting compromised, but “we haven’t been hacked yet” is not a security model.

Agent locking addresses this. Once your agent is configured and working, you can lock it. A locked agent will continue to renew and deploy certificates, but its configuration cannot be changed from the CertKit UI. To make configuration changes, someone needs local admin access to the server to remove the lock file.

This means the blast radius of a CertKit compromise is limited to certificate delivery, not command execution. Your restart commands are frozen in place. We can push a new cert, but we can’t change what happens with it.

If you’re running the agent on production infrastructure, we recommend locking it once setup is complete.

CertKit automates certificate lifecycle management so you can stop thinking about SSL certificates.

Security vendors love the man-in-the-middle attack. It’s the boogeyman of every TLS marketing page. Some shadowy figure intercepting your traffic, reading your secrets, stealing your data.

A man-in-the-middle attack is when an attacker positions themselves between two parties on a network to intercept the traffic flowing between them. In the context of TLS, that means an attacker who can present a valid certificate can read everything in plaintext and proxy it on to the real server.

But when was the last time you actually heard about one happening? Not a phishing attack. Not malware. Not credential stuffing. An actual man-in-the-middle interception of a TLS connection in the wild.

The Verizon 2025 Data Breach Investigations Report analyzed over 22,000 security incidents. Credential abuse accounted for 22%. Ransomware showed up in 44% of breaches. Phishing was in 16%. The “Adversary-in-the-Middle” is less than 4% of incidents, and the vast majority of those are real-time phishing proxies like Evilginx, not someone intercepting TLS connections with stolen certificates.

The attack everyone worries about is the one that almost never happens.

A stolen private key doesn’t get you very far

Let’s say the worst happens. An attacker steals a server’s TLS private key. Maybe they exploited a vulnerability. Maybe they found it in a git repo (please don’t do this). What can they actually do with it?

If you’re running any modern TLS configuration, less than you’d think. Perfect Forward Secrecy means a stolen private key can’t decrypt recorded traffic. Not past sessions or any future sessions. The “record now, decrypt later” scenario is dead for any connection using forward secrecy, which is now about 94% of the web. At least until quantum computing becomes a reality.

What a stolen key can do is let an attacker impersonate your server. They can present your real certificate, complete a valid TLS handshake, and proxy traffic onward to the real server, without any browser warnings.

But there’s a massive catch: To impersonate your server, the attacker has to intercept the connection before it reaches you. They need a man-in-the-middle network position.

Getting ‘in the middle’ is the hard part

The difficulty of getting “in the middle” of a TLS connection varies enormously depending on where the attacker is and who they’re targeting. The spectrum runs from trivially easy to requiring the resources of an intelligence agency.

On a local network, it’s embarrassingly simple. ARP spoofing requires nothing more than a laptop on the same network and a free tool like Bettercap. One command redirects all traffic on that LAN through the attacker’s machine.

Evil twin Wi-Fi attacks are just as easy. A $200 pineapple device or a Linux laptop running hostapd can clone any network name and force nearby devices to connect. In 2024, Australian police arrested a man who ran fake Wi-Fi networks on commercial airline flights, harvesting credentials from passengers.

These attacks are real, but their scope is measured in meters, not miles. The attacker has to be physically present, on the same network, within radio range of their targets. That’s not a scalable attack against your production infrastructure.

DNS hijacking. Compromise a domain’s registrar account and you can redirect DNS queries to attacker-controlled servers. The most notable campaign, Sea Turtle, hit over 40 organizations across 13 countries by going after DNS registries directly. Cisco Talos assessed it as nation-state backed. They didn’t bother stealing private keys. They didn’t need to. They hijacked DNS and got fresh certificates from public CAs.

BGP hijacking. BGP is how internet routers decide where to send traffic. It runs on trust, with no built-in authentication. If an attacker controls a router at an ISP or hosting provider, they can announce false routes and reroute traffic through their own infrastructure. In 2018, attackers compromised a small Ohio ISP, hijacked Amazon Route 53 address space, and redirected MyEtherWallet users to a phishing server for two hours. They stole $150,000 in crypto. The attackers’ wallet already held $27 million. Not a casual operation.

Physical backbone taps are pure nation-state. GCHQ’s TEMPORA program tapped over 200 submarine cables. Hundreds of millions of dollars. Cooperation from telecom providers. You’re not defending against this.

James Mickens put it best in his essay This World of Ours:

you’re either dealing with Mossad or not-Mossad. If you’re not-Mossad, good passwords and basic hygiene will keep you safe. If you are the Mossad, “the Mossad is not intimidated by the fact that you employ https://.”

What actually compromises your TLS connections

The attacks that actually compromise TLS connections happen at the endpoints.

In 2015, Lenovo shipped consumer laptops with Superfish, a pre-installed root CA that intercepted all HTTPS traffic to inject ads. Every affected laptop shared the same private key, protected by the trivially extracted password “komodia.” Once that key leaked, anyone on the same Wi-Fi as a Lenovo owner could silently intercept their banking, email, everything. Dell did the same thing months later with eDellRoot. A root certificate, bundled with its private key, that would reinstall itself if you deleted it.

This is the threat model that actually matters for most organizations. If an attacker compromises a user’s endpoint through malware, phishing, or a supply chain attack, they can install whatever root certificates they want. They don’t need your server’s private key. They don’t need network position. They own the device, so they own the TLS trust chain on that device.

The Verizon DBIR data backs this up. For small and medium businesses, 88% of breaches involve ransomware. System intrusion, social engineering, and basic web application attacks dominate the landscape. Stolen-key MITM doesn’t make the list.

“So I don’t need to protect my private keys?”

Of course you do. They’re still secret, just not life-or-death important.

A compromised key can’t decrypt past traffic, but it could be used for targeted network impersonation. That’s a real risk, just not the five-alarm emergency.

The right response is proportional security. Encrypt keys at rest. Limit who and what can access them. Rotate them regularly. Use short-lived certificates so a compromised key has a smaller window of usefulness.

That’s exactly how we approach it at CertKit. Private keys in our database are encrypted using a key stored in our credential system combined with a salt compiled into the application. Decrypting them requires compromising both, independently. Agent communication is protected by agent-specific keypairs negotiated during authorization on top of TLS 1.3. No shared secrets between agents.

And for organizations that don’t want private keys leaving their network at all, we’re building the CertKit Gateway. Gateway runs on a server or container inside your infrastructure. It generates private keys locally and sends only the CSR to CertKit for validation and signing. The private key never leaves your network.

Spend your security budget on the threats that actually happen

If you’re running a mid-sized business, the honest threat assessment is that this is a minor risk. The chance of someone stealing your TLS private keys and then executing a man-in-the-middle attack against your users is vanishingly small. Not zero. But small enough that it should sit well below credential hygiene, endpoint protection, phishing training, and ransomware preparedness on your priority list.

If you’re running critical infrastructure or a high-value financial target, the risk is real enough to invest in dedicated monitoring, RPKI deployment, hardware security modules, and aggressive key rotation. CertKit Gateway is coming soon for exactly this reason.

For everyone else? Automate your certificates so they don’t expire. Use short-lived certificates so a compromised key has a smaller window of usefulness. And spend your remaining security budget on the attacks that actually happen.

CertKit automates certificate lifecycle management. Start monitoring your certificates for free, or talk to us about CertKit Gateway for on-premises key management.

A few months ago I wrote about BygoneSSL and the 1.5 million domains with valid certificates owned by someone else. Domains change hands but certificates don’t know. The old owner keeps their private key, and the certificate keeps working.

It’s an industry problem, but it turns out it’s our problem too.

We purchased certkit.dev for internal development and demos. I randomly used it as an example for our Certificate Transparency log search and found a valid certificate issued by DigiCert.

Still valid for another 100 days.

Someone we’ve never met holds a private key for one of our domains.

How worried should we be?

Honestly? Not very. At least not in this case.

For someone to actually exploit this, they’d need to man-in-the-middle our traffic with this old certificate. We weren’t running anything sensitive on certkit.dev. It’s a dev domain. And thanks to Perfect Forward Secrecy, even if someone had the private key, they couldn’t decrypt any previously captured traffic. The key only helps you impersonate, not eavesdrop on the past.

The realistic risk to us is close to zero.

But that’s for a small dev domain nobody’s targeting. Now imagine this is your payment processor, like Stripe. The original BygoneSSL research found this exact situation on stripe.com, where someone held a valid certificate for a payment processing domain for over a year after the sale. Same vulnerability, very different stakes.

The uncomfortable truth is that this is incredibly common. The research found that 7% of all domains have valid certificates owned by previous owners.

Trying to get it revoked

So we have a BygoneSSL problem. Now what?

I didn’t issue this certificate and I don’t have a DigiCert account. I have no relationship with whoever owned certkit.dev before us. But I do own the domain now, and there’s a certificate out there that I’d like to not exist.

DigiCert’s documentation has an email address for exactly this situation: revoke@digicert.com. I sent them a clear request with the SHA256 fingerprint and serial number, explained that the organization no longer owns this domain, and asked what validation they’d need from me.

The first response came two hours later, addressed to “Tobb”, asking me to add a note under “this Order” so they could revoke the certificate.

What order? I don’t have an account. I didn’t place an order. That’s the entire point of this email. Someone else ordered this certificate for my domain.

I wrote back explaining the situation. This time DigiCert understood and gave me steps to validate that I owned the domain. Once complete, they said it would be revoked “shortly”.

From first email to revocation approval: about 4 hours across 6 emails. Not terrible once a human understood what I was asking. But the first response was a support agent reading from a script that assumed I was the certificate holder, not the domain owner. If I hadn’t known exactly what to ask for, or had given up after being told to log into an account that doesn’t exist, that certificate would still be sitting there untouched.

Certificate revoked, in theory

DigiCert said the certificate would be revoked “shortly.” So I checked.

It took about 24 hours for the certificate to be revoked on the Digicert’s OCSP and CRL. But as of this writing (72 hours later), the certificate is still trusted by every browser on the planet.

This is certificate revocation in practice. You can do everything right. Find the stale certificate. Contact the CA. Prove you own the domain. Get confirmation that revocation is happening. And the certificate keeps working anyway because the revocation infrastructure is held together with duct tape and good intentions.

Even when revocation eventually propagates to the CRLs, Chrome still only checks its own curated CRLSet covering a fraction of revoked certificates. Firefox’s CRLite updates on a delay. Safari does its own thing. Whether any given browser actually rejects this certificate after revocation depends on which browser, which revocation list, and when they last updated.

This is why certificate lifetimes are shortening

The industry knows this problem exists. Revocation has been broken for years and nobody has a realistic plan to fix it. Their answer is shorter certificates. Under the 47-day certificate timeline coming in 2029, maximum exposure from a domain ownership change drops from over a year to weeks.

Under 47-day lifetimes, our certkit.dev certificate would have expired before I even finished the domain purchase. Instead I spent an evening emailing back and forth with a CA, proved I own my own domain, got a confirmation, and the certificate is still valid in every browser.

47-day certificates won’t fix revocation. But they’ll make it matter a lot less.

What to do when you buy a domain

If you’re acquiring a domain, don’t assume it comes clean. Here’s what we’d recommend.

Search Certificate Transparency logs for the domain before or immediately after purchase. You’ll see every certificate ever issued. If there’s something current that you didn’t request, you know you have a BygoneSSL situation.

Set CAA records on your DNS right away. CAA (Certificate Authority Authorization) records tell CAs which authorities are allowed to issue certificates for your domain. This won’t kill existing certificates, but it prevents new ones from being issued by unauthorized CAs.

File revocation requests with any CA that has outstanding certificates you didn’t authorize. Be prepared for this to be slow and confusing. If it’s a Let’s Encrypt certificate, you can revoke it yourself by proving domain control through ACME. Commercial CAs will make you work for it.

Set up CT log monitoring so you’ll know if anyone issues a new certificate for your domain in the future. This is the one thing you can actually stay on top of.

None of this is hard. But none of it is something anyone thinks about when buying a domain. The registrar doesn’t warn you. The CA doesn’t notify you. You have to go looking, and most people don’t.

CertKit automates certificate lifecycle management. Search your domain’s certificates for free with our CT Log Search tool.

Getting a certificate is the easy part. Getting it onto every server that needs it, in the right format, with the right permissions, and restarting the right services? That’s the part where things fall apart.

The CertKit Agent closes that gap, just released from our product roadmap.

Issue, deploy, verify

I wrote recently about the certificate automation loop: issue → deploy → verify. Most tools only handle issuance. They get the cert signed and drop a file somewhere. Deployment is your problem.

The agent is how CertKit solves deployment. Install the agent on a host, tell it which certificates that host needs, and it handles the rest. When a certificate is renewed, the agent downloads it, writes the files in the correct format, sets ownership and permissions, and runs the restart command for your software. Pair it with CertKit’s domain monitoring and you have the complete certificate automation.

Here’s how it works:

How it works

The agent runs as a background service on your host. On first launch, it registers with your CertKit account using a registration key. After that, it polls CertKit for certificate configurations you’ve assigned to it.

When a certificate changes, the agent writes the new files to the paths you configured, then executes your restart command. systemctl reload nginx, Restart-Service W3SVC, whatever your software needs.

It also auto-detects common web servers so you don’t have to configure paths manually. Right now it recognizes Nginx, Apache, HAProxy, LiteSpeed, and IIS, with more coming.

Install it in one line

Just copy the install snippet from the CertKit UI, which already has your registration key embedded. It looks something like this:

sudo env REGISTRATION_KEY="your.registration_key_here" \
  bash -c 'curl -fsSL https://app.certkit.io/agent/latest/install.sh | bash'

The service will start automatically, and you will see a pending agent for you to configure in the UI. Alternatively, you can deploy it with Ansible, set it up as a scheduled task or cron job, or interact with it via the command line.

Open source

The agent is MIT licensed and on GitHub. You can read the code, audit the security model, or contribute. We think the thing that manages your private keys should be something you can inspect.

Available now

The agent is live for all CertKit users. Head to your CertKit dashboard to generate a registration key and deploy your first agent.

If your web server isn’t auto-detected yet, open an issue or get in touch with us.

CertKit automates certificate lifecycle management so you can stop worrying about deployments. See how it all fits together.

You’ve deployed certificate automation with Certbot and your artisanally-crafted scripts, but you still got paged at 2am for an expired cert. You’ve discovered the difference between issuance automation and certificate automation.

Certificate automation is more than a cron job

Operational certificate lifecycle is a loop. It repeats every renewal, hostname change, or emergency replacement:

issue → deploy → verify

Issue is proving control of the domain and getting the CA to sign the keypair/CSR. This is the “ACME did its thing” moment. If you want the mechanics, I wrote up how ACME automates issuance.

Deploy is the hard part. It is getting the new certificate, in the correct format, to every place that serves traffic. Web servers, mail servers, load balancers, ingress controllers, app servers, sidecars, and that one legacy box you hate touching.

Verify is proving that the endpoint is using the certificate you think it is, for the names you intended. Not “the file exists,” but “real clients see the new cert.” Verification means running a real TLS handshake against the public hostname and checking expiry, SANs, and chain. Almost nobody does this part.

Then the loop starts again because certificates expire, soon every 47 days.

Issuance is easy to automate

Lots of teams are really good at automating issuance. These tools solve getting a valid cert, not getting it live everywhere, or verifying that it works.

You can install Certbot. You can wire up DNS plugins. You can schedule renewals.

But that’s it. The CA says “ok.” The client exits 0. A file got written. It’s up to you to get it where it needs to go. And none of that proves it worked end-to-end.

From issuance automation to certificate automation

You don’t need “more Certbot.” Your servers shouldn’t need to know how ACME works. You need to make deployment reliable, and monitor that it worked.

1. Deployment should be boring A renewed cert that isn’t deployed everywhere is just a file. Build a repeatable rollout path to the places that terminate TLS (CDN, load balancer, ingress, app servers), and standardize the bundle format so you don’t lose hours to chain weirdness.

2. Verification is the success signal Stop celebrating “renewal succeeded.” The loop only completes when an external check proves the public endpoint is serving the expected cert and chain. If you can’t automatically verify it, you didn’t really automate it.

3. Don’t pass out DNS keys If DNS is in the loop, reduce the blast radius. Prefer patterns like DNS delegation, keep credentials scoped and centralized, and keep the TXT record lifecycle boring (create, validate, clean up).

Do those three things and shrinking certificate lifetimes are no big deal. The loop just runs more often, and nobody gets paged for it.

That’s the whole idea behind CertKit, it’s the missing layer that turns “we can renew a cert” into “we can reliably deploy and verify certificates everywhere they’re used.” See how it works.

CertBot assumes every server that needs a certificate should also know how to request one, validate domain ownership, handle renewals, and manage failures.

This makes sense with a handful of servers. One server, one cert, done. But infrastructures grow. Now you’ve got web farms sharing wildcards, load balancers, mail servers, VPN appliances. The “every server for itself” model doesn’t scale and isn’t sustainable.

Even the Let’s Encrypt community knows it. When asked what would make Certbot scale better, a maintainer responded bluntly: “If someone has ‘a large number of certificates’ they should not be using Certbot… Certbot has been positioned as the ‘entry level’ and ‘swiss army knife’ of ACME clients.”

Entry level is not exactly a ringing endorsement for managing your production infrastructure.

How ACME breaks down

With CertBot, ACME is a distributed responsibility model. Each server handles its own validation, each server manages its own renewals, and each server needs to handle its own errors.

Certificate distribution

Dozens of servers often need to share a wildcard certificate. How do you handle that? One server requests it, then you distribute it to the others. The official CertBot guidance for this scenario is basically “figure it out yourself.”

So we build workarounds. Rsync cron jobs. NFS mounts. Ansible playbooks that copy certificates around. You’ve poorly reinvented a centralized certificate manager.

The Let’s Encrypt forums are full of confused admins trying to solve this:

I’ve read through a number of topics but can’t decide on the best approach to use when Let’s Encrypt is to be used with multiple servers.

The problem arrives when I tried to introduce a load balancer and additional nodes… I’m afraid the auto renew process will fail as the challenge might be distributed to a different node.

Nobody has a great answer.

Monitoring a distributed system

Distributed certificate automation has two failure points: renewing the certificate, and getting the running service to use it. Both can fail silently, anywhere in your infrastructure. It’s on you to monitor every system to make sure neither breaks.

Epic Games had certificate monitoring. When a wildcard cert expired in April 2021, they identified the problem within 12 minutes. Recovery still took 5.5 hours.

Why? The certificate was used across “hundreds of internal back-end service-to-service calls.” Renewing it was just the first step. Then they had to roll it out to every service that needed it, verify each one picked up the new cert, and deal with the cascading failures that had already started. They later admitted they “believed that we were more protected than we actually were.”

Knowing about the problem isn’t the same as fixing it when your certificates are scattered across infrastructure.

The skeleton key problem

Distributed validation doesn’t just create operational headaches. It creates security exposure.

HTTP-01 validation requires every server to expose port 80 and serve challenge files. That’s attack surface multiplied across your entire infrastructure. In January 2026, researchers disclosed a Cloudflare WAF bypass that exploited ACME challenge paths, where security controls were deliberately relaxed to allow certificate validation.

DNS-01 validation is worse. Every server with DNS credentials holds keys to your entire domain. The EFF warns explicitly: “If the machine handling the process gets compromised, so will the DNS credentials, and this is where the real danger lies.”

DNS credentials don’t just issue certificates. They control email routing, traffic direction, everything. One compromised web server and an attacker can redirect your domain, issue valid certificates for it, or intercept email by modifying MX records.

Flipping ACME on its head

The issue is that certificate issuance and certificate deployment are different problems. CertBot conflates them.

Your nginx server doesn’t need to understand ACME. Your mail server doesn’t need DNS API credentials. Your VPN appliance probably can’t run CertBot.

They just need a certificate file.

CertKit separates these concerns. CertKit is the ACME client. One system handles domain validation, certificate requests, and renewals. Your servers never talk to the certificate authority. They never hold DNS credentials. They don’t need to understand ACME at all.

Instead of every server renewing its own certificates, CertKit lets your server subscribe to the certificates they need, and pull them automatically whenever they change. You install a lightweight agent that says “give me the cert for example.com” When the cert renews, the agent gets the new one automatically. No special ports. No DNS credentials on the box. No ACME knowledge required.

The certificates exist independently of your servers. Even if you never installed a single agent, CertKit would keep requesting, renewing, and storing valid certificates for your domains. Your infrastructure subscribes to certificates it needs.

This matters more every year

Certificate lifespans keep shrinking. 47-day certificates arrive in 2029. What’s merely annoying with annual renewals becomes impossible at that pace.

One sysadmin’s reaction to the 47-day proposal captured the frustration: “This is somewhat nightmarish. I have about 20 appliance-like services that have no support for automation.” VPN servers, load balancers, proxy servers, network gear. None of these can run CertBot.

But they can all receive a certificate file.

CertKit automates certificate lifecycle management. See how it works. Currently in beta.

The CA/Browser Forum set 47-day certificates as target for 2029. Let’s Encrypt decided to implement it a year earlier.

In December 2025, Let’s Encrypt announced their roadmap to cut certificate lifetimes from 90 days to 45 days by February 2028, a full year ahead of the industry mandate.

It’s exactly what we’d expect from the CA that made automation mandatory from day one.

The timeline

Right now, Let’s Encrypt certificates are valid for 90 days with a 30-day authorization reuse period. That means once you prove you control a domain, you can issue certificates for it without re-validating for the next month.

Here’s how that’s changing:

• May 2026: You can opt-in to 45-day certificates for early adopters and anyone who wants to test their automation can switch now.
• February 2027: Certificate lifetimes drop to 64-days and 10-day authorization reuse.
• February 2028: Certificate lifetimes drop to 45-day with 7-hour authorization reuse. This is the new normal.

Let’s Encrypt is giving you staging environment access about a month before each production date.

Why Let’s Encrypt is going first

Let’s Encrypt was built for automation. They’ve always assumed you’re not manually renewing certificates. Their entire architecture, from the ACME protocol to rate limits to their support model, assumes automated clients.

If your renewals are already automated, going from 90 days to 45 days or even 6 days is trivial detail. Your client just runs slightly more often.

The people who will struggle are the ones who were never really automated in the first place. The ones running certbot manually every few months. The ones with “renew certificates” as a recurring calendar reminder. We can help you.

Authorization reuse is the bigger change

Certificate lifetime gets all the headlines, but authorization reuse going from 30 days to 7 hours is arguably more disruptive.

Today, you can validate a domain and issue multiple certificates over the next month without re-validating. Need a cert for staging? Already validated. Spinning up a new subdomain? Already validated. That flexibility disappears.

With 7-hour authorization reuse, every certificate request essentially requires fresh validation. If your automation assumes you can batch certificate operations across a day, that breaks.

That’s why delegated DNS validation is important. It lets you offload the constant work updating your validation tokens to a dedicated service (like CertKit). You just set up a CNAME once, and your certificate service handles the TXT record updates without needing your DNS credentials.

DNS-PERSIST-01 makes it even easier, letting you set a single DNS record for the entire domain. The new validation method lets you authorize a CA once and skip re-validation entirely. Let’s Encrypt committed to implementing it in 2026, explicitly as an enabler for shorter certificate lifetimes.

What you need to do

If you’re running a modern Certbot with default settings, you’re probably fine. Certbot 4.1.0 (released June 2025) added support for ACME Renewal Information (ARI), which lets the CA tell your client when to renew. With ARI enabled, Certbot automatically adjusts to whatever certificate lifetime Let’s Encrypt issues.

Check your version:

certbot --version

If you’re below 4.1.0, it’s time to upgrade. Or better yet, switch to centralized certificate automation.

The thing that will break you is hardcoded renewal intervals. If your automation says “renew every 60 days” regardless of certificate lifetime, that stops working in February 2028. A 45-day certificate renewed at 60 days is an expired certificate.

CertKit and the 45-day future

CertKit uses Let’s Encrypt as our preferred certificate issuer. When their timelines change, our renewal cycles adapt automatically. You won’t need to reconfigure anything.

We’ve added ARI support to our roadmap to ensure we’re renewing at exactly the right time rather than relying on static intervals. When Let’s Encrypt tells us a certificate needs early renewal (like after a revocation event), we’ll respond immediately.

Certificate lifetimes will keep getting shorter. That won’t matter to you. Certificates in CertKit are always automatically renewed and refreshed. That’s the whole point.

CertKit automates certificate lifecycle management so certificate lifetimes are someone else’s problem.

When you’re managing a handful of certificates, one big list works fine. Add a few dozen more and things get messy. Add multiple teams or projects and you’ve got a problem.

Who should have access to the production certificates? What about staging? Does the contractor working on the marketing site really need to see your internal infrastructure?

CertKit now supports multiple applications from our roadmap to help you sort this out.

What are applications?

Applications are independent groups of certificates, domains, and hosts. Each application has its own storage bucket and access credentials. Think of them like security boundaries for your certificate infrastructure.

You might create separate applications for each product you run. Or split by environment (production, staging, development). Or by team. Whatever makes sense for how you actually work.

Scoped API keys

Access and API keys are managed at the application level.

Before, one API key meant access to everything in your account. Now you can generate keys scoped to specific applications. Your deployment scripts for the marketing site only touch marketing certificates. Your production automation only sees production infrastructure.

If a key gets compromised (or a contractor leaves), you revoke it without affecting everything else.

Available now

All CertKit users can create up to 6 applications today. If you need more, just ask and we’ll enable them for your account.

Head to your CertKit dashboard to start organizing your certificates.

CertKit automates certificate lifecycle management so you can focus on literally anything else.

It seems like every service wants proof you control your domain.

Certificate authorities need it to issue certificates. Email platforms need it to authorize sending. Analytics needs it to gather data. Just add this magic TXT record to your DNS, wait for propagation, click verify.

It works fine when it’s a one-time setup, but certificate lifetimes are dropping to 47 days, and you won’t be able to keep up on that schedule. You’ll have to automate, and now dozens of systems are changing your DNS.

The credential problem

DNS validation works by proving you can modify records in a zone. You add a special TXT record, the service queries for it, validation complete.

To do that automatically, you need API credentials. And most DNS providers don’t offer fine-grained permissions. You can’t say “this token can only create TXT records at _acme-challenge.example.com.” You hand over credentials that can modify your entire zone.

Now multiply that across every system that needs DNS validation to renew its certificate. That’s a huge attack surface. Each one capable of redirecting all your traffic, intercepting all your email, or poisoning your DNS entirely.

What is delegated domain validation?

But there’s a better way! Instead of giving each service credentials to modify your DNS, you can delegate just the validation record to them.

Say a service needs to validate _acme-challenge.example.com. Instead of giving it DNS API access, you create a single CNAME record:

_acme-challenge.example.com.  IN  CNAME  abc123.challenges.certkit.io.

That’s it. One record, set one time.

When a service needs to complete a validation challenge, they don’t touch your DNS at all. They update a TXT record in their own zone at abc123.challenges.certkit.io. When the validating party queries _acme-challenge.example.com, DNS follows the CNAME and finds the current challenge token updated by CertKit.

You’ve delegated the validation, not the zone.

That abc123 is a unique token that binds this delegation to your specific account. If you ever stop using the service and remove the CNAME, nobody else can claim that validation target and start issuing certificates for your domain.

The IETF is formalizing this pattern in an upcoming Best Current Practice document, Domain Control Validation using DNS.

Delegated domain control validation lets a User delegate the domain control validation process for their domain to an Intermediary without granting the Intermediary the ability to make changes to their domain or zone configuration.

You’re proving control of your domain without giving anyone else control of your domain.

Why CNAME delegation is safer

With traditional DNS validation, your certificate service holds credentials that can modify any record in your zone. If those credentials leak, an attacker can do anything: redirect your website, intercept your email, issue fraudulent certificates for your domain.

With CNAME delegation, the worst case is different. If your certificate provider is compromised, an attacker can respond to validation challenges for your domain. That’s bad, but it’s bounded. They can’t redirect traffic that isn’t already going through that provider.

Related, the ACME working group is developing DNS-PERSIST-01, a new validation method addressing the operational and security risks of domain validation. Instead of proving control ‘right now’ with a fresh challenge, DNS-PERSIST-01 lets you set a persistent authorization record once. Combined with CNAME delegation, nothing changes on any renewal. Ever.

How CertKit handles this

CertKit uses CNAME delegation for DNS validation. You point your _acme-challenge record to us once, and we handle every certificate validation from there.

You never give us credentials to your DNS provider. We can’t touch your zone. We can only respond to ACME challenges for domains you’ve explicitly delegated to us.

Your DNS zone stays yours. We just handle the certificates.

CertKit automates certificate lifecycle management.

We just published the CertKit roadmap.

Product roadmap

Most company roadmaps are vague promises about “AI-powered synergies” and “enhanced platform capabilities” that mean absolutely nothing. Ours is different. It’s a list of features we’re actually building.

More importantly, it’s interactive.

Every feature has a vote button. Click it. Tell us if you want it or if you couldn’t care less. We’re a small team, and we’d rather build what you actually need than guess.

Right now we’re working on a Host Agent for distributing certificates to your infrastructure. High on the list after that: SSO, user roles, advanced alerting, and certificate tags for organizing the chaos.

Further out, we’ve got some ideas we’re not sure about yet. Private CA support. Other ACME issuers beyond Let’s Encrypt. A Certificate Transparency Log API for the power users. These might be brilliant or they might be solutions looking for problems. You tell us.

And if the feature you desperately need isn’t on the list at all? Let us know. We’ve added features based on a single email before. We’ll do it again.

The roadmap is at certkit.io/roadmap. Go vote on something.

CertKit automates certificate lifecycle management so you can stop thinking about SSL certificates.

There’s a particular flavor of skepticism that shows up whenever someone suggests using Let’s Encrypt. The security team crosses their arms. “Free certificates? For production? We’re a serious organization. We use Sectigo.”

I get it. You’ve been buying certificates from the same vendors for twenty years. They send you invoices, you pay them, certificates appear. It feels responsible, and free feels like a trap.

But is it?

What is Let’s Encrypt?

Let’s Encrypt is a certificate authority operated by the Internet Security Research Group, a 501(c)(3) nonprofit founded in 2013 by engineers from Mozilla. They started issuing certificates in 2015 and by 2026 holds 60% market share. Internet infrastructure like Cloudflare, Github, and Mozilla use Let’s Encrypt.

You’re not paying for better encryption

A free Let’s Encrypt certificate uses the same encryption as that $500 Extended Validation certificate. The only difference is the paperwork that you are who you say you are. Domain Validation (DV) certificates only verify you control the domain, but it turns out that’s all anyone really cares about.

Organization Validation (OV) verifies your business exists. Extended Validation (EV) adds sixteen additional identity checks. That sounds important until you learn that EV and OV certificates haven’t mattered in over five years.

Chrome killed the green address bar in 2018 and removed company names entirely in 2019. Safari and Firefox followed. Google’s security team published research showing users didn’t make safer choices when EV indicators were present. So they got rid of them.

Amazon, Google, Shopify, ChatGPT, and the IRS all use standard DV certificates. These companies have unlimited security budgets. They chose DV anyway because the other stuff doesn’t actually matter.

Let’s Encrypt is more sustainable than your CA

“But what happens when the free CA goes away? At least DigiCert will be around.”

Will they?

DigiCert is owned by Clearlake Capital, Sectigo is owned by GI Partners. Private equity ownership means the company exists to generate returns for investors. Deliver a locked-in service as cheaply as possible until you’ve extracted every penny from it. Ask Toys ‘R Us how that goes.

Let’s Encrypt, on the other hand, is funded by donations from organizations that depend on the CA ecosystem remaining competitive. Their 2024 financials show $9.56 million in revenue, $5.1 million in net assets, and 27 employees running infrastructure for 762 million websites. Sponsors include Google, Amazon Web Services, Mozilla, EFF, Cisco, IBM, and Shopify.

These sponsors need Let’s Encrypt to exist. A free CA with 60% market share gives them leverage against commercial certificate pricing. Google and AWS aren’t funding Let’s Encrypt out of charity. They’re funding it because the alternative is letting DigiCert and Sectigo set prices and dictate technology requirements.

That’s more sustainable than private equity.

The commercial CAs have the worse track record

Let’s Encrypt has operated since 2015 with no security breaches of CA infrastructure. In 2020, they discovered a bug in their CAA checking code that affected about 3 million certificates. They disclosed it immediately, patched it within hours, and began revocations within days. Their 90-day certificate lifetime meant all remaining affected certificates expired naturally within weeks.

Compare that to the commercial CAs.

In July 2024, DigiCert discovered they’d been issuing certificates with improper domain validation for five years. A missing underscore prefix in their verification system. They gave customers 24 hours to replace 83,000 certificates. CISA issued an emergency alert. Critical infrastructure operators couldn’t meet the deadline. Some customers sued.

That same year, Google, Apple, and Mozilla all announced they would stop trusting certificates from Entrust, one of the oldest commercial CAs. Google cited “a pattern of compliance failures, unmet improvement commitments, and the absence of tangible, measurable progress” over six years. Entrust had delayed revocations, missed deadlines, and failed to meet the standards every CA agrees to follow.

The free nonprofit CA has a cleaner record than the paid alternatives.

When paying actually makes sense

I’m not going to pretend there’s never a reason to buy certificates.

There are some banking and healthcare compliance requirements that dictate OV and EV certificates.

Or maybe you need contractual Service Level Agreements. If your procurement department requires a vendor agreement with guaranteed uptime commitments, Let’s Encrypt won’t sign one.

Or maybe you require a phone number for support. Let’s Encrypt won’t do that either, it just a support forum.

But maybe you should push back on that. In 2026, certificates are a standardized commodity. You don’t need a contract SLA from Lowes to buy a lightbulb. You don’t need to call McDonalds to debug your hamburger. If something’s wrong with your certificate, just generate a new one.

The question you should actually be asking

The objection to Let’s Encrypt usually comes down to “free feels risky.” But the evidence points the other way. They issue 60% of certificates, including ones at companies that sell you security tools.

The real question isn’t whether Let’s Encrypt is good enough for your organization. It’s whether your objections are based on current evidence or just institutional habit.

CertKit automates certificate lifecycle management so you can stop thinking about SSL certificates entirely.

With the ACME protocol, to issue a certificate you have to prove you control the domain. The CA gives you a challenge, you complete it, and they issue your cert.

The trouble is that every validation method has tradeoffs. And as certificate lifetimes get shorter, those tradeoffs will get more painful. DNS-PERSIST-01 is a new approach coming in 2026 that trades proof-of-freshness for easier operations.

ACME validation methods

HTTP-01 is the easiest to understand. The CA gives you a token, you host it in a file at http://example.com/.well-known/acme-challenge/, and the CA fetches it. Proof of control. Done.

But HTTP-01 means opening port 80 to the public internet, and that can be scary. Not everyone wants their certificate validation infrastructure exposed to the world.

DNS-01 lets you hide your internal systems. Instead of serving a file, you create a DNS TXT record at _acme-challenge.example.com. The CA queries DNS, finds your token, and you’re validated. No open ports.

The problem is that changing DNS records can be unreliable at best and risky at worst. DNS is famously problematic due to its slow refresh and caching cycles. Nine times out of ten with any major outage, it comes down to DNS.

For your systems to create DNS validation records, they need API credentials, often with broad permissions. For better or worse, DNS has become a skeleton key can unlock everything and cause lots of trouble if compromised. I really don’t want every system in my infrastructure to have my DNS keys.

What is DNS-PERSIST-01?

DNS-PERSIST-01 is a new ACME challenge type that eliminates the DNS-01 “change DNS on every renewal” problems. Instead of creating a fresh TXT record for each validation, you create one persistent record that authorizes a specific CA and account indefinitely.

_validation-persist.example.com. IN TXT
"letsencrypt.org; accounturi=https://letsencrypt.org/acme/acct/123456; policy=wildcard"

That’s it. You’re telling Let’s Encrypt (or whatever CA you specify) that ACME account 123456 is authorized to get any certificate it needs for example.com. Forever, or at least until the optional persistUntil timestamp expires.

The honest tradeoff

DNS-PERSIST-01 is a different approach to validation than the other methods. It trades real-time validation for operational efficiency.

Aaron Gable, an engineer at Let’s Encrypt, described the tradeoff on the CAB Forum mailing list:

The [DNS-PERSIST-01] security model is sound and has real advantages; but the ergonomics and optics are bad.

While the spec still requires a “random value” in the traditional sense (your account URI is effectively that value), Gable admits that because it doesn’t change this feels like theater:

The fact that it still involves a Random Token even though checking for the presence of that random token achieves nothing feels like pulling the wool over one’s eyes.

This is refreshingly honest for a standards discussion. The people building DNS-PERSIST-01 aren’t pretending it’s a strict improvement. It’s a tradeoff. You get massive operational simplification. You lose proof-of-freshness.

The security model does work. Your ACME account is cryptographically bound to a keypair. If someone compromises that keypair, they can issue certificates for any domain where you’ve set up persistent validation. But that was already true with DNS-01 if they got your DNS credentials. The attack surface is just different, not necessarily larger.

When is DNS-PERSIST-01 coming?

The regulatory path for DNS-PERSIST-01 is already clear. CA/Browser Forum ballot SC-088v3 passed in October 2025 with unanimous support from 26 Certificate Authorities. Chrome, Mozilla, and Cisco all voted yes. The IETF ACME working group formally adopted the draft in October 2025.

Let’s Encrypt committed to implementing DNS-PERSIST-01 in 2026. No specific quarter or month yet, just “2026” with “more to announce soon.” Let’s Encrypt explicitly sees this as an enabler for shorter certificate lifetimes.

When certificate lifetimes drop to 47 days (coming in 2029), you’ll be revalidating constantly. Manual DNS changes won’t cut it. Half-baked automation will break. DNS-PERSIST-01 is designed to make that future survivable.

How CertKit will use DNS-PERSIST-01

Right now, CertKit proxies DNS-01 validation so you don’t have to hand over your DNS credentials. DNS validation will follow CNAMEs, so we can host and update the TXT records for you. That already solves the “skeleton key” problem. But you still need to authorize each certificate request through our system.

With DNS-PERSIST-01, you authorize CertKit once per domain. You can point _validation-persist.example.com to a record we control, and we handle the TXT record on your behalf. We handle every renewal automatically. No per-certificate approval, just create certificates when you need them.

CertKit will support it shortly after Let’s Encrypt does.

CertKit automates certificate lifecycle management so you don’t have to.

You’ve used wildcard certificates for years. It made your life easier. Once a year you’d renew your wildcard certificate, and copy it around to all the servers. It was way too complicated and expensive to get a unique certificate for every system.

But now certificate lifetimes are shrinking to 47 days by 2029 and it’s not going to work anymore. You need to automate your certificates. Soon.

So here’s the question: if you’re automating certificate management, do you actually need a wildcard SSL certificate? Or is it solving a problem that no longer exists?

What is a wildcard certificate?

A wildcard certificate covers a domain and all its subdomains at one level. Buy a cert for *.example.com and it works for foo.example.com, bar.example.com, baz.example.com, and anything else you need.

In practice, nearly every wildcard certificate is issued as a multi-SAN cert that includes both *.example.com and the apex example.com domain. So when you buy a “wildcard,” you’re really getting a SAN certificate with a wildcard entry.

Note that wildcards don’t cover multiple levels. A cert for *.example.com won’t secure dev.api.example.com. That needs its own certificate or another wildcard at *.api.example.com.

What is a SAN certificate?

A SAN (Subject Alternative Name) certificate lists one or more specific domains. Unlike wildcards, these are explicit like app.example.com or api.example.net.

CAs sometimes call these “multi-domain” or “UCC” certificates. They’ll even let you mix completely different domains on one cert. Every domain must be listed at issuance. So if you want to add a new subdomain, you have to re-issue the whole certificate.

Certificate authorities love selling SAN certificates. They typically charge per domain, so a 10-domain SAN costs more than a single wildcard that covers unlimited subdomains. Keep that in mind when you hear CAs recommending SANs over wildcards.

Tradeoffs in wildcard vs SAN certificates

Here’s what to consider with a wildcard vs SAN certificate:

1. Flexibility and future subdomains

Wildcards cover subdomains you haven’t created yet. If you spin up subdomains for projects or customers, having a wildcard can make that faster and easier. With a SAN certificate, you have to issue a new cert for every domain you need. But, if you have certificate automation implemented, issuing a new certificate could just be a few clicks.

2. Key compromise and blast radius

A compromised private key is always concerning, but the scope of damage depends on what that key protects. Lose a single-domain certificate’s key and one service is exposed. Lose a wildcard key and every subdomain is vulnerable. And if you’re not using Perfect Forward Secrecy, attackers could decrypt previously captured traffic too.

The NSA warns that attackers with a wildcard private key can impersonate any subdomain covered by that certificate. They lay out a scenario where a compromised staging server, steal the key, use DNS poisoning or network access to redirect traffic intended for production systems. The NSA calls these “relatively uncommon conditions,”. If the attacker is in your network and changing DNS records, you’ve got bigger problems.

3. Certificate Transparency exposure

Every TLS certificate is logged publicly in Certificate Transparency logs. All of them. You can search for yours right now using our CTLog search tool. Anyone can watch these logs and see what domains you’re creating certificates for.

With single-domain certificates, your infrastructure is visible. Internal project names, customer subdomains, staging environments, or that new product you haven’t announced yet. Hanno Böck demonstrated at DEF CON 25 that attackers can find new WordPress installations within 30-60 minutes of certificate issuance by watching CT logs. He estimated he could have compromised around 4,000 WordPress sites in a month.

Wildcard certificates hide your subdomain names. The CT log shows *.example.com, not the 15 specific subdomains you’re actually running. Some organizations choose wildcards specifically for this obscurity. It’s not perfect security (subdomains can still be discovered through DNS enumeration), but it removes one easy reconnaissance vector.

4. Validation requirements

Wildcard certificates require DNS-01 validation. You have to create a TXT record to prove domain ownership. Single-domain certificates can use simpler HTTP-01 validation where you just drop a file on your web server.

This matters for automation. DNS validation requires API access to your DNS provider. HTTP validation just needs a running web server. If your DNS provider has a bad API (or no API), wildcards become painful.

Here’s one of the ways CertKit makes it easier. Rather than worrying about validation, you just create a CNAME record for _acme-challenge.example.com and point it at us. We handle all the validation from there, so you can get whatever certificates are right for you. It’s called delegated domain validation.

Multi-SAN certificates: the worst of both worlds

Multi-SAN certificates combine the downsides of both approaches.

You get the blast radius of a shared private key. Compromise one server, compromise every domain on that cert.

You get full Certificate Transparency exposure. Every domain is publicly listed.

You lose flexibility. Adding or removing domains requires reissuing the entire certificate. Want to sell off a side project that was on your main SAN cert? You can’t just remove it. Reissue everything.

And you get a unique problem called BygoneSSL. If any domain on your multi-SAN certificate changes ownership (you let it lapse, you sell it, the new owner wants it back), the new owner can request revocation of the entire certificate. Researchers analyzing this found CDN certificates with 700 domains on them. One bygone domain means one person can kill service for 699 other sites with a single revocation request.

There are a few vendor systems that require multi-SAN certificates (looking at you Microsoft Exchange), but you should probably avoid them unless you have to. Don’t choose this architecture voluntarily.

When wildcards still make sense

Even with full automation, wildcard certificates have legitimate uses.

CT log obscurity. If hiding your subdomain structure from public view matters to your threat model, wildcards are the only option. Maybe you’re working on an unannounced product. Maybe you have customer-specific subdomains you’d rather not advertise. Maybe you just don’t want to make reconnaissance easier for attackers.

Load balancers and reverse proxies. A wildcard on your edge proxy doesn’t meaningfully expand blast radius. If someone compromises that proxy, they already have access to traffic for all your subdomains. The NSA guidance specifically calls this out as an acceptable use case.

High-churn environments. If you’re constantly creating and destroying subdomains (dev environments, feature branches, customer sandboxes), wildcards mean one less thing to automate per deployment.

Vendor requirements. Some systems just want a wildcard. Don’t fight it.

Automation changes the question

The wildcard vs SAN debate is stuck in the past. It assumes certificates cost money and management is painful, so minimizing the number of certificates matters. One is easier than fifty. Less to track, less to renew, less to screw up.

But with 47-day lifetimes arriving in 2029, you need automation regardless. And once you’ve automated, issuing 50 single-domain certificates takes the same effort as one wildcard.

The question shifts from “what’s easiest to manage?” to “what fits my security model?”

For most organizations, that’s single-domain certificates per service. You get isolation (compromise one key, lose one service). Independent renewal cycles (one failure doesn’t cascade). Clear inventory of what’s running where.

Wildcards remain useful when CT log obscurity matters.

Multi-SAN certificates listing explicit domains should be avoided unless a vendor specifically requires them.

CertKit just added multi-SAN support for the cases where you need it. But our recommendation? Single-domain certs per service when you can. Wildcards when you need obscurity. Multi-SAN only when you have no choice.

CertKit automates certificate lifecycle management for teams who’d rather not think about certificates. Currently in beta.

We shipped some big updates this week from our roadmap!

Multi-domain certificates

You can now create certificates that cover multiple domains. Mix and match wildcard certificates with specific hostnames, all on a single certificate.

The first domain you add becomes the Common Name. The rest go into the Subject Alternative Names (SAN) list. This matters if you have systems that still check CN instead of SAN.

One thing to know: multi-domain certificates only renew if all domains validate successfully. If one domain’s DNS is misconfigured, the whole renewal fails. The UI warns you about this because we’ve been burned by it ourselves.

The certificates list now shows which certs have multiple domains attached so you can see what you’re dealing with at a glance.

Better error messages

When certificate issuance fails, CertKit now shows you the actual ACME error instead of a generic “something went wrong” message.

You can see exactly what the CA rejected and why. In this case, someone tried to get a wildcard for a domain that doesn’t exist on the public suffix list. (We also prevented this specific thing from happening again by being better at domain validation). The error tells you that, along with when we’ll retry.

No more guessing what went wrong or digging through logs.

Non-sequential identifiers

We replaced all sequential integer IDs with SQIDs. Those short alphanumeric codes you see in URLs and the certificates list (like knmy and b1nw) are now the only identifiers exposed by the system.

Sequential IDs leak information. They tell attackers how many resources exist, when they were created, and provide an easy target for enumeration. Sqids look random but are still deterministic, so your bookmarks and API integrations won’t break.

CertKit automates certificate lifecycle management for teams who have better things to do. Try it free during our beta.

In 2015, only about 40% of websites used HTTPS. Today HTTPS is used over 95% of the time. The ACME protocol made that shift possible.

The Automatic Certificate Management Environment (ACME) protocol enables software to automatically prove domain control to a certificate authority without any human involvement. No more generating CSRs by hand. No more copy-pasting into web forms. No more waiting for validation emails.

ACME largely solved certificate issuance. But it didn’t solve certificate operations. Getting a certificate is trivially easy now, but getting that certificate onto all the servers that need it? That’s still your problem.

What is the ACME protocol?

Before ACME, getting a certificate was a manual slog. The RFC 8555 specification itself describes the old process:

1. Generate a CSR using OpenSSL incantations you copied from Stack Overflow.
2. Paste it into a CA’s web form.
3. Prove domain ownership through some ad-hoc method (usually clicking a link in an email).
4. Download the certificate.
5. Figure out which format your server needs and install it manually.

The spec notes that webmasters needed 1-3 hours to get a certificate installed!

ACME automates all of this. Here’s the ACME protocol explained step by step:

1. Account registration. Your ACME client generates a key pair and registers with the CA. All future requests are signed with this key, so the CA knows they’re from you.

2. Order creation. The client sends a JSON request to the CA’s newOrder endpoint listing the domain names you want on the certificate. The CA responds with an order object containing authorization URLs for each domain.

3. Authorization. For each domain, the client fetches the authorization object, which contains available validation methods (more on that next). The client picks a validation method and implements the expected response, then tells the CA to validate.

4. Finalization. Once all authorizations pass, the client submits a Certificate Signing Request to the order’s finalize URL. The CA issues the certificate and provides a download URL.

5. Download. The client fetches the certificate chain and installs it.

The whole exchange happens over HTTPS using signed JSON messages. No web forms. No emails. No humans. A certificate that used to take hours now takes seconds.

Every major certificate authority supports the protocol today. It’s become the standard way certificates get issued.

ACME validation methods

The ACME protocol defines three validation methods to prove you control a domain, each with tradeoffs.

HTTP-01 is the simplest. The CA gives you a token, you put it in a file at /.well-known/acme-challenge/ on your web server. Works great for a single web server with port 80 open to the internet.

DNS-01 requires you to create a TXT record in your domain’s DNS with a specific value. It’s the only method that works for wildcard certificates. It also works when your server isn’t publicly accessible. But your ACME client needs to modify your DNS, which can be high-risk.

TLS-ALPN-01 validates over TLS on port 443 using a special ALPN protocol identifier. Useful when you can’t open port 80 but can control TLS termination.

The history of ACME

ACME emerged from two teams who discovered they were solving the same problem.

At Mozilla, Josh Aas and Eric Rescorla were designing a free, automated certificate authority. At the University of Michigan and EFF, Alex Halderman and Peter Eckersley were building a protocol for automatic certificate issuance. The teams found each other and merged efforts in 2013, incorporating the Internet Security Research Group as the nonprofit that would operate Let’s Encrypt.

They knew they needed an automated way to issue certificates, so they approached Richard Barnes, then at Mozilla, with the idea for software to automate certificate provisioning. He wrote the first ACME specification draft and the initial Let’s Encrypt CA software (Boulder) on a flight home from an IETF meeting. Some of that original code is still running in production. Barnes shepherded ACME through the IETF standardization process, which completed in March 2019 with RFC 8555.

The standardization process improved the protocol significantly. The IETF discussions led to a redesign where clients request certificates first and then complete required validations, rather than the original flow of validating domains before requesting certs. This made wildcard certificate handling more natural. The community also pushed for all requests to be authenticated, leading to the POST-as-GET pattern in the current spec.

For the full history with interviews from the people who built it, Christophe Brocas wrote an excellent piece worth reading.

A decade later, every major CA supports ACME. ZeroSSL, Google Trust Services, SSL.com, Sectigo, DigiCert. They had to. With a mechanism to automate certificates, the CA/Browser Forum voted in April 2025 to reduce maximum certificate lifetimes to 47 days by March 2029.

ACME keeps evolving

The protocol continues to develop. RFC 9773, published in 2025, adds ACME Renewal Information (ARI). ARI lets certificate authorities suggest renewal windows to clients, which is critical when a CA needs to mass-revoke certificates due to compliance issues. Let’s Encrypt now lets clients who renew via ARI bypass rate limits.

Two new challenge types are on the way. dns-persist-01 will allow you to link your DNS to an ACME issuer one time, so you don’t need to rotate keys. A new dns-account-01 challenge addresses multi-CDN environments. There’s even work on using ACME for device attestation certificates, extending the protocol well beyond its original web server use case.

The challenge is client-side adoption. Most ACME clients are “set and forget.” People install certbot, configure a cron job, and never touch it again. Aaron Gable, interviewed in Brocas’ blog above, notes that even when client projects implement new features like ARI, their massive install bases don’t update. The ecosystem turns over slowly.

What ACME doesn’t solve

ACME handles issuance, and that’s it. The protocol is a conversation between one client and one CA. What happens after the certificate arrives is outside the spec entirely.

Certbot, the original ACME client, works beautifully for one certificate, on one server. But you probably don’t just have one server.

You have a web farm. You have that legacy Windows box running a vendor application. You have staging environments and development servers. You have that one machine under someone’s desk that nobody remembers but is apparently critical to payroll. Should each of them be their own ACME client?

Certbot’s official guidance for multi-server deployments is essentially “figure it out yourself.” So people do. They write rsync scripts. They build Ansible playbooks. They create one-off certificate management systems that operate without monitoring or audit.

Each server needs to have HTTP port 80 open to the internet for validation, or worse hold credentials to update your DNS. DNS API keys scattered across your infrastructure, on every machine that might need a certificate. One compromised server and an attacker has write access to your entire DNS and take over.

There’s a difference between issuance automation and certificate automation.

How CertKit handles ACME

CertKit is a centralized ACME client that runs in one place. It talks to certificate authorities (Let’s Encrypt, Sectigo, your enterprise CA, whatever supports ACME), handles all the validation, manages renewals centrally, and then distributes certificates to wherever they need to go.

You don’t need to expose port 80 on every server, or pass around your DNS credentials. You create a CNAME record pointing the ACME challenge name to us, and we handle the rest. All your certificates are available in a secure file API or pushed where they need to go.

One place to manage ACME protocol certificates. Deployed everywhere they’re needed. Monitored so you know when something breaks before your customers tell you. We’re picking up where ACME left off, automating the rest of your certificate lifecycle management.

For twenty years, a stolen private key was a disaster.

It meant total compromise. Every encrypted conversation, password transmitted, API call ever made was readable.

Traffic was being recorded all the time, “just in case” your private key leaked out. The NSA even had a name for it: “harvest now, decrypt later.” Record all the encrypted traffic today. Steal the private keys tomorrow. Decrypt everything retroactively.

Not a conspiracy theory, it was actual operational doctrine from the Snowden documents.

This is why we used to treat private keys like plutonium. Hardware security modules. Rotations with change advisory boards. Full incident response when someone with access left the company. The idea of letting a vendor hold your private keys was unthinkable.

Then Perfect Forward Secrecy came along, and made everything safer.

The old RSA key exchange

Most folks think SSL/TLS encryption still works like the old RSA key exchange.

In RSA, the client generates a random pre-master secret, encrypts it with the server’s public key, and sends it. The server decrypts with its private key, and both sides derive session keys from this shared secret. The trouble is that the encrypted pre-master secret travels over the network, where anyone can record it. If the private key is ever compromised, that record can be decrypted to reveal the pre-master secret and derive all the session keys.

That’s exactly what the NSA did! As Matthew Green from Johns Hopkins put it: “If the recording entity is powerful enough, they may simply steal the keys — or demand them under court order.”

Using RSA key exchange, one key compromise unravels years of secrets.

What is Perfect Forward Secrecy?

With RSA, the server certificate acted as both authentication (you are who you say you are) and authorization (you are allowed to read this data). Perfect Forward Secrecy (PFS) splits these apart and only uses certificates to authenticate that you are who you say you are.

In PFS, each connection gets its own encryption keys that exist only for that session. This happens during the TLS handshake through ephemeral Diffie-Hellman key exchange.

The client and server each generate and exchange random numbers:

1. Client generates random number a and sends server g^a mod p, where g and p are standard parameters defined by the cipher.
2. Server generates random number b and sends client g^b mod p.
3. Using their random number and the results from the other, both sides can compute g^ab mod p, which becomes the shared session secret.

An attacker watching this exchange sees the public values but can’t derive the session key. That’s the Diffie-Hellman problem and nobody’s solved it in nearly 50 years of trying.

The server certificate signs this initial exchange to prevent man-in-the-middle attacks, but the real session info is encrypted using the derived session key.

Using Perfect Forward Secrecy, a compromised private key could be used to impersonate you, but all previous traffic remains safely encrypted.

How to enable Perfect Forward Secrecy on your servers

Good news: If you’re running TLS 1.3, you already have Perfect Forward Secrecy. It’s mandatory, you can’t turn it off.

RFC 8446 states: “All handshakes in TLS 1.3 provide forward secrecy.” No options. No configurations. Just PFS by default.

But if you’re still on TLS 1.2, you need to configure it properly.

TLS supports two variants: DHE (traditional Diffie-Hellman Ephemeral) and ECDHE (Elliptic Curve Diffie-Hellman Ephemeral). ECDHE is better because it’s faster and uses smaller keys for equivalent security. Look for cipher suites with DHE or ECDHE in the name. Those provide forward secrecy.

Note that ECDHE describes the key exchange, not the certificate type. Your server certificate can be RSA or ECDSA regardless of which key exchange you use.

For Nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;
ssl_ecdh_curve X25519:secp384r1;

For Apache:

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder off

For IIS, you need to mess with the registry or use IIS Crypto. Because Windows.

Test your configuration, change www.example.com to your domain

echo | openssl s_client -connect www.example.com:443 -tls1_2 2>/dev/null | grep "Cipher"

See “ECDHE” in there? You’re good.

SSL Labs will give you a detailed report. Search for “Forward Secrecy” in the results page. Should say “Yes (with most browsers)”.

What EC certificates actually improve

Switching to an EC (ECDSA) certificate is a separate decision from enabling ECDHE key exchange. EC certificates don’t give you PFS, but they do give you a faster, leaner handshake.

A 256-bit EC key provides roughly equivalent security to a 3072-bit RSA key, so certificates are smaller and the cryptographic operations are cheaper on the server. On high-traffic systems or constrained hardware, that adds up. You get smaller payloads during the TLS handshake, lower CPU overhead on your servers, and better performance on mobile and IoT clients where compute is limited.

Why your certificates are safe to automate

Without PFS, certificate automation is scary. Your private keys lived on disk. In memory. In backups. Every automated system that touched certificates became a potential catastrophic breach vector.

With PFS, that entire threat model disappears.

A compromised private key can’t decrypt past traffic. Can’t even decrypt current traffic from sessions that already completed their handshake. The blast radius shrinks from “all of history” to “new connections if the attacker can man-in-the-middle, but only until we notice and revoke the certificate.”

This is why Google turned on PFS in 2011. Not for the marginal security improvement. For the operational freedom.

We can sleep better knowing that the private keys we have on our servers, if compromised, can’t be used to decrypt past sessions.

When Heartbleed hit in 2014, sites with PFS had dramatically different breach notifications. Without PFS: “All traffic from the past two years may be compromised.” With PFS: “Traffic after March 2014 may be at risk until you patched.”

That’s a $100 million difference in breach costs according to Ponemon Institute data.

The risks of private key compromise from Certificate automation becomes reasonable with PFS.

Perfect forward secrecy and quantum computing

Quantum computers will eventually break Perfect Forward Secrecy.

Shor’s algorithm can solve both the discrete logarithm problem (breaks Diffie-Hellman) and integer factorization (breaks RSA) when we have big enough quantum computers.

The NSA is probably recording traffic now to decrypt later with quantum computers. They’re betting on having the capability within 10-20 years.

So even if you’ve already enabled ECDHE key exchange and switched to EC certificates, you’ll need to update your cipher suites again soon with quantum-safe algorithms. When post-quantum becomes mandatory (and it will), you’ll need to reissue every certificate with new cipher suites.

With proper certificate management? It’s a config update. Change your cipher preferences. Click reissue. CertKit handles the rest. Every cert gets the new algorithms on its next renewal cycle. No special migration project. No weekend work. No explaining to the CEO why you need six months to “upgrade cryptography.”

Turn on PFS this week

Perfect Forward Secrecy has been available since 1999. TLS 1.3 made it mandatory in 2018. If you’re not using it, you’re running decades-old cryptography.

Check your servers:

echo | openssl s_client -connect www.example.com:443 -tls1_2 2>/dev/null | grep "Cipher"

Fix the ones using RSA key exchange. Update your load balancers. Configure your CDN. Test with actual browsers.

Once you’ve got PFS, your private keys are a lot safer. You can automate them, or trust a vendor like CertKit to manage them for you.

Turn it on. This week. Before you’re explaining to the board why last year’s traffic just got decrypted.

CertKit manages certificates in the PFS world. Where keys aren’t scary and 47-day rotation isn’t insane.

Clickhouse is an incredible database. Here at Certkit, we’ve long worked in the world of “No SQL” databases like Elasticsearch precisely for their ability to query large amounts of data. But for every database, there’s an amount of data that’s “Too big”. Too big to query quickly or too big to store affordably. Clickhouse manages to thread the needle by efficiently storing truly ridiculous amounts of data while still providing impressive query performance.

Certkit is building Certificate Transparency (CT) log monitoring for our customers. In previous posts, we learned what CT logs are and how to pull data from them. Now, we need to store all that data in Clickhouse. This is no small task. About 100 million new certificates enter the CT logs every week!

This is the final post in a series on how we built a fast, reliable Certificate Transparency Search for CertKit.

What Is Clickhouse?

In case you missed it the first time, Clickhouse is a remarkable database. While it is SQL based, don’t let that fool you, Clickhouse is not your father’s database. Its performance is what we’ve come to associate with No SQL databases in recent years.

Column Based

Clickhouse tables are column based as opposed to the usual row based SQL database. A “column-orientated” database simply means all data for a column is stored together, separate from other columns in the same table. Clickhouse uses this column orientation to do two big things: store data efficiently and query it quickly.

Efficient Storage

A column’s data is all the same type and entries are often similar to each other. Clickhouse takes advantage of this fact to run compression over each column individually. These compression rates can range from no compression with random data up to 1000x or more with highly repetitive data.

Fast Queries Over Large Data Sets

Querying a column also benefits from Clickhouse’s columnar nature. Because all the data is co-located, data can be read very efficiently. The impressive data compression often helps as well. When size on disk is so small, it’s easy to read a large number of rows with a relatively small amount of disk activity.

This only touches the surface of what makes Clickhouse unique but suffice to say, it can hold lots of data in a small amount of space, and query it very quickly.

Goals

We have three main goals for our CT monitoring. These goals greatly impact our database schema. Our database must:

Fast Search

Both CT log alerting and searching depend on one main feature: fast domain name searches. Without fast result results, interactive searches will be too slow and alerts will be delayed or broken. Our schema needs to sell out to make search fast (Foreshadowing!).

Completeness Needed For Alerts

We want to alert the customer when certificates are created for their domain. Completeness is important, otherwise alerts won’t sent when they should be. Therefore, we need to store any and all recently issued certificates.

Affordable

We have a unused server that would be a great start for this service. Unfortunately, it only has 2.5TB of SSD disk space. A space efficient schema is needed to fit all 3+ Billion certificates issued in the last year into this small amount of space.

Using Clickhouse To Store Every SSL Certificate

We’d like to know about every certificate that is issued. The potential size of this dataset greatly influenced our decision to use Clickhouse.

ReplacingMergeTree

A certificate has many entries spread across different CT Log servers. These entries are purposely stored in multiple logs for redundancy. For our purposes, it is good enough to have just one reference to a CT log for every certificate. Deduplicating these entries saves on table size and query time. Both of which we care about very much.

Clickhouse offers an easy way to deduplicate our overly numerous log entries. The ReplacingMergeTree table engine deduplicates rows using the table ordering as a uniqueness key. One catch: deduplication is not guaranteed and is performed in the background or not at all, depending on the situation. This is usually a fine tradeoff, but needs to be kept in mind when writing queries.

Table Ordering

Table ordering determines how the ReplacingMergeTree will determine duplicates. It also has storage size implications: sorting similar rows near each other gives more opportunity for efficient compression.

We settled on ordering by SerialNumber and IsPrecert ORDER BY (SerialNumber, SHA256).

Certificate Serial numbers

Primarily sorting by SerialNumber enables fast lookups of specific certificates and increases compression ratios by placing all rows about a single certificate next to each other. It has the added bonus of letting us correlate pre-certificate and issued certificate log entries.

However, there is one catch: A certificate’s serial number is not guaranteed to be globally unique. It is only required to be unique for a specific issuer. From our data, serial numbers are relatively unique and collisions are uncommon. We can verify we’ve gotten the correct certificate by checking that the returned row has the expected issuer or SHA256 hash. This inconvenience is outweighed by the ability to associate a certificate’s pre-certificate and final certificate entries.

SHA256

Log entries come in two types: Pre-certificate and Issued certificate. Only a pre-certificate entry is guaranteed to appear in a log, but many final certificate entries also exist. We’d like to keep one example of each for every certificate. We are doing this in practice by secondarily ordering the table by SHA256. This ensures we keep at least one entry for the pre-certificate and issued certificate.

Partitioning and Deletes

Because completeness is not one of our goals, we’re perfectly happy to save space by deleting data for old, expired certificates. Here lies a small problem: Clickhouse deletes are very expensive because rows are immutable once written. The only way to update or delete a row is to rewrite the entire file containing the row. This is very expensive and slow.

What is fast for Clickhouse is deleting an entire file containing many rows. Partitioning tells Clickhouse how rows should be divided between files. Our table is partitioned by the certificate’s expiry date (PARTITION BY toYYYYMM(CertificateExpiryDate)), letting us easily drop a month’s worth of certificates without thrashing the disk.

(Not) Storing Raw Certificates

TLDR: We don’t store the raw certificate bytes. This might seem odd, because the whole point is to know about every issued certificate. The problem is, certificates are HUGE.

A single certificate is just a few KB in size, but multiplying a few KB by 3 billion certificates results in a very large database. We avoid the storage costs by not storing the certificate at all.

Retrieving A Certificate

We do need the original, raw certificate from time to time. Luckily, the full certificate is stored as part of each CT Log entry. The Leaf Index (which we DO store and is just a single integer) allows us to ask the log for the entry along with the original certificate.

Searching Every SSL Certificate In Clickhouse, Very Quickly

So we’ve stored a CT log entry for every certificate, but we have not addressed how to quickly search certificates by their associated domains. Running a domain query on our large log entries table results in a full table scan. We need something much faster than that.

Skip Indexes Have Limits

Skip Indexes are Clickhouse’s solution to secondary indexes where the table sort order is not conducive to the query. We could use a Skip Index for the domain names column. Clickhouse uses these indexes to skip blocks of data where it knows a value does not exist. Skip indexes still result in some table scanning, but it is greatly reduced. This almost works for our use case but results in unpredictable query times for large result sets. For example, UPS.com has generated over 3 million certificates in the last year. A query for UPS takes many times longer to complete than a domain with just a few certificates.

A Table Optimized For Search

When in doubt, make more tables. To get consistent query times, we opted for a denormalized table created specifically for domain name searching. This additional table is denormalized to a row per SAN(aka domain names) and is also ordered by SAN. That means there is often several rows in the search table for a single certificate in our main table. Ordering the entire table by domain name lets us take the most advantage of the primary table indexes.

Reversing Strings for Performance

Storing a string in reversed order increases the performance of some LIKE queries. Our search patterns generally look like: “Find all certificates where the domain is *.example.com,” or “Find all certificates ending with *.vpn.example.com. In SQL, this query looks something like WHERE Domain LIKE '%example.com' or WHERE Domain LIKE '%vpn.example.com'. Clickhouse reverts to table scanning instead of using the primary index because Clickhouse doesn’t know how the domain begins!

Clickhouse can use the primary index in LIKE queries when the wildcard is at the end. Storing the domains in reversed order lets us run queries where the wildcard is at the end of the string. example.com is stored as moc.elpmaxe and the query changes to: WHERE Domain LIKE 'moc.elpmaxe%'. To make a more readable query, Clickhouse will happily reverse the string for you: WHERE Domain LIKE reverse('%example.com').

Significant Domains

When we search domain names, we don’t think it’s useful to match a search like “*.com”. We need to match at least the whole first “significant domain”. A simple test of whether something is a significant domain is, “Could I buy this domain at a registrar?”. nyt.com or bbc.co.uk are both significant domains even though one contains an additional level.

Clickhouse has a built in function to extract the significant domain. However, doing it on the fly will again effect how well we can use the table’s indexes. Saving off the significant domain into its own column lets us improve our query performance:

SELECT cutToFirstSignificantSubdomain('www.nyt.com');
SELECT cutToFirstSignificantSubdomain('www.bbc.co.uk');

-- RESULT --
'nyt.com'
'bbc.co.uk'

Materialized Views

We’d rather not change our processing code to insert every entry into two tables. Clickhouse can do it for us with materialized views. Materialized views take new data from one table and inserts it in some modified way into second table.

Conclusion

So far, we’ve stored Billions of certificates which Clickhouse has easily handled. If anything, this amount of data is small by Clickhouse standards and we often see domain query times under a tenth of a second. You can use it yourself in our free Certificate Transparency search tool.

We built this tool as part of Certkit: a simple certification issuance and management tool. It’s just a small part of what makes Certkit great. Check us out if you’re tired of manually issuing certificates or fighting with Certbot.

In the last post we discussed why we’re building our own Certificate Transparency (CT) search tool. There’s good background on the CT ecosystem in that post, so check it out if you haven’t. This post assumes a certain understanding of terminology covered previously.

Now that we know where the CT logs live, and the different kinds of logs, we need to start reading them. This post will cover code examples to read log entries from both tiled and RFC 6962 logs, and discuss options for running at scale.

Golang is the language of Certificate Transparency

We’re C#/.NET guys by disposition (yeah, yeah) but we’re also pragmatists. While it’s possible to consume CT logs with any language, the guys writing the Web PKI plumbing are mostly writing in Golang (Go, from here on).

And if you’re willing to play in the Go sandbox, there are some nice client libraries available to consume both types of logs.

RFC 6962 Log Client

For all things RFC 6962 you should check out Google’s certificate-transparency-go library. In addition to containing a great client for interacting with log APIs, it contains some code to handle parallel scanning for you (more on that later).

Tiled Log Client

The tiled/static-ct logs are still pretty new, and we only found a single client implementation worth using. It’s written by the guy who proposed the tiled logs in the first place, so probably as good as it gets for now.

Two logs, two examples each

Let’s start calling the CT log APIs and see what we’re working with. Remember, there are two types of logs, and the read paths for each log are different. So for most things there will be two code examples - one for the RFC 6962 logs (the OGs) and one for the newer tiled logs.

RFC 6962: Getting the Signed Tree Head

RFC 6962 logs publish a Signed Tree Head (STH). This is a cryptographic snapshot of the Merkle tree root. Its purpose is to prove the tree hasn’t been tampered with, but for our puposes we primarily care about the tree_size value.

The tree_size is simply how large the log is currently. How many certificates and precertificates are in it. This is useful when scanning the logs - so if you stop or have to restart you know where you left off, and how far you are from completion.

STH In the Browser

You can actually get the signed tree head in the browser for most logs. For example, here’s the STH for Google’s Argon 2026h1 log:

https://ct.googleapis.com/logs/us1/argon2026h1/ct/v1/get-sth.

STH Using Go

But of course for any kind of real log scanning we’ll want to get it programmatically. Something like this will do the trick (but yours should have actual error handling):

import (
  // There are ambiguous "client" packages in the library so specify
  ctclient "github.com/google/certificate-transparency-go/client"
)

func main() {
  logUrl := "https://ct.googleapis.com/logs/us1/argon2026h1/"
  client, err := ctclient.New(logUrl, http DefaultClient, jsonclient.Options{})
  signedTreeHead, err := client.GetSTH(ctx)

  // Let's see how big the log is!
  fmt.Printf("Tree size: %d\n", signedTreeHead.TreeSize)
}

Tiled Logs: Getting the Checkpoint

Tiled logs don’t have a signed tree head. Instead they have a checkpoint. It’s not quite the same thing, but for our purposes it is - since it contains the log size!

Checkpoint in the Browser

Let’s Encrypt runs several tiled logs. As of November 2025 they are qualified for inclusion in Chrome, which means they’re ready for primetime. Let’s look at the checkpoint for Sycamore’s 2026h1 log:

https://mon.sycamore.ct.letsencrypt.org/2026h1/checkpoint

It’s also worth calling out that Sunlight logs have a little bit of UI to go with them. Here is Sycamore’s web UI: https://log.sycamore.ct.letsencrypt.org/

You can add items to the log right from your browser. There’s also helpful links to the checkpoint, and perhaps more importantly for later - the public key is also shown.

Checkpoint Using Go

We can get the checkpoint fairly easily in Go as well, but it’s a little more effort with the public key involved.

import (
	"filippo.io/sunlight"
)

func main() {
  // First up, we gotta turn the base64 key in to something usable.
  publicKey: "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEfEEe0JZknA91/c6eNl1aexgeKzuG
QUMvRCXPXg9L227O5I4Pi++Abcpq6qxlVUKPYafAJelAnMfGzv3lHCc8gA=="
  bytes, _ := base64.StdEncoding.DecodeString(publicKey)
  key, err := x509.ParsePKIXPublicKey(bytes)

  // Then we can make the client
  // for many of these logs the UserAgent is not optional.
  logMonitoringUrl :="https://mon.sycamore.ct.letsencrypt.org/2026h1/"
  client, err := sunlight.NewClient(&sunlight.ClientConfig{
    MonitoringPrefix: logMonitoringUrl,
    PublicKey:        key,
    UserAgent:        "YourUserAgent (you@yourdomain.com, +https://yourdomain.com)",
  })

  // Get the checkpoint (plumb in your context as available)
  checkpoint, _, _ := client.Checkpoint(context.TODO())

  fmt.Printf("Log size: %d\n", checkpoint.N)
}

RFC 6962: Scanning Entries

Now for the most important part: ripping through the log with reckless abandon, processing entries pell-mell. While the client in the Google CT library is useful, they’ve also helpfully included a scanner that will do the heavy lifting for you. It saves quite a bit of faffing.

Certificates vs. Precertificates

Before we see the code to scan through an RFC 6962 log, remember that there are two kinds of “things” in the logs. Precertificates and certificates. This distinction is important as we’ll see when scanning both kinds of logs.

Using the Scanner in Go

import (
  ctclient "github.com/google/certificate-transparency-go/client"
  "github.com/google/certificate-transparency-go/scanner"
)

func main () {
  logUrl := "https://ct.googleapis.com/logs/us1/argon2026h1/"
  client, err := ctclient.New(logUrl, http DefaultClient, jsonclient.Options{})
  s := scanner.NewScanner(client, scanner.DefaultScannerOptions())

  s.Scan(context.TODO(), func(raw *ct.RawLogEntry) {
		// this is the callback for certificates
		le, _ := raw.ToLogEntry()
		fmt.Printf("Cert common name: %s", le.X509Cert.Subject.CommonName)
	}, func(raw *ct.RawLogEntry) {
		// this is the callback for precertificates
		le, _ := raw.ToLogEntry()
		fmt.Printf("Precert common name: %s", le.Precert.TBSCertificate.Subject.CommonName)
	})
}

Processing at Scale

There are hundreds of millions (or sometimes billions) of items in large certificate transparency logs. Unfortunately, many operators of RFC 6962 logs throttle traffic heavily (looking at you Google). You can change the number of parallel threads fetching log entries in the scanner options, but in our experience you will get throttled very quickly at anything above 2 parallel threads.

The Cloudflare Nimbus logs were the most performant RFC 6962 logs we found. Google and Digicert both either throttled heavily, or had very slow to respond logs. Scanning tiled logs is an order of magnitude faster, so hopefully those become the standard (they’re a cost/performance win for log operators too!)

Tiled Logs: Scanning Tiles Like a Boss

The reason the read path differs for tile logs is because they’re optimized to be stored in object storage (think S3). This makes it easy for CDNs to front these logs and allows for blazing fast (relative to RFC 6962, anyways) log retrieval.

Let’s see how it works.

Scanning Tiled Logs in Go

import (
	"filippo.io/sunlight"
)

func main() {

  client := GetSunlightClient()
  checkpoint, _, _ := client.Checkpoint(context.TODO())

  for i, entry := range client.Entries(context.TODO(), checkpoint.Tree, 0) {
    if entry.IsPrecert {
      cert, err = x509.ParseCertificate(entry.PreCertificate)
      isPrecert = true
    } else {
      cert, err = x509.ParseCertificate(entry.Certificate)
    }
  }

  fmt.Printf("Log size: %d\n", checkpoint.N)
}

func GetSunlightClient() *sunlight.Client {
  // First up, we gotta turn the base64 key in to something usable.
  publicKey: "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEfEEe0JZknA91/c6eNl1aexgeKzuG
QUMvRCXPXg9L227O5I4Pi++Abcpq6qxlVUKPYafAJelAnMfGzv3lHCc8gA=="
  bytes, _ := base64.StdEncoding.DecodeString(publicKey)
  key, err := x509.ParsePKIXPublicKey(bytes)

  // Then we can make the client
  // for many of these logs the UserAgent is not optional.
  logMonitoringUrl :="https://mon.sycamore.ct.letsencrypt.org/2026h1/"
  client, err := sunlight.NewClient(&sunlight.ClientConfig{
    MonitoringPrefix: logMonitoringUrl,
    PublicKey:        key,
    UserAgent:        "YourUserAgent (you@yourdomain.com, +https://yourdomain.com)",
  })

  return client
}

The client.Entries() returns an iterator that we can just loop over to get the log entries. As with the RFC 6962 logs, there is a distinction between certificates and precertificates. The client itself does a decent job of multithreading.

Processing Tiled Logs at Scale

We were able to process over a hundred million records from each tiled log per day. This stands in stark contrast to the paltry low millions we could retrieve from the RFC boys.

There are a number of tiled log providers who are either usable or qualified in modern browsers, and Let’s Encrypt is going to switch to tiled logs exclusively at some point. From a scanning perspective they are clearly superior!

Conclusion

Using pre-built Go libraries, you can start scanning CT logs quickly. Though there are billions of certificates in the logs, if you parallelize your scanning, and run multiple logs at a time, you can fairly quickly scan a reasonably comprehensive chunk of the data. You can check out how it works using our free Certificate Transparency search tool.

In the next post we’ll talk about storing the certificate transparency logs in Clickhouse. Certainly we can’t enumerate every log every time there’s a search query!

Every TLS certificate issued by a root Certificate Authority (CA) ends up in one more more publicly accessible logs. These logs, collectively, make up the Certificate Transparency (CT) ecosystem. Unfortunately the logs are not very searchable. You can’t easily type in a domain and find all associated certificates.

At CertKit we’re building CT monitoring capabilities to notify our customers when a new certificate is issued. For that reason, and others, we need fast and reliable CT search capabilities.

There are tools available that store the logs in a search-friendly format. Probably the most well known is crt.sh. It’s eminently comprehensive (and free!), but does suffer from some issues. The biggest is that searching is slow. If your query matches many log entries, you will only get a truncated result set back. And fairly frequently the site just fails to respond or is hard down.

That’s why we built our own free certificate transparency search tool!

This series of posts focuses on how we went about building this faster, more reliable Certificate Transparency search for CertKit.

What is Certificate Transparency used for?

The primary use case is to make SSL/TLS certificate issuance visible and auditable. Basically to hold CAs accountable and ensure they’re not mis-issuing certificates.

In addition, end users can find forgotten or outdated infrastructure that’s still getting certificates, see who’s issuing certificates on their behalf, and even figure out if they’re about to miss a certificate renewal by looking at historical records.

You might be surprised at how much the certificate transparency logs can tell you about your own applications!

There are some potential “off-label” uses of CT logs as well.

Because every publicly trusted certificate is recorded, you could also monitor when competitors launch new products, test staging environments, or stand up new services, all by watching the domains they register certificates for. I’ve even heard people hypothesize you could use the logs as a signal when considering stock trades.

How did Certificate Transparency start?

In 2011 a Dutch CA named DigiNotar was compromised and the attacker issued rogue certificates for over 500 domains. The fake certificates were used to perform man-in-the-middle attacks.

Following this and other high profile CA issues, the IETF created RFC 6962, which established the certificate transparency protocol (and resulting logs).

How does Certficate Transparency work?

There’s a comprehensive explanation of the certificate transparency protocol on the main CT website, but the important points are these:

• Before a real certificate can be issued, a CA needs to submit a precertificate to at least 2 CT logs. The precertificate contains the same data as the real cert, along with a “poison” extension that prevents it from being used.
• Upon submitting the precertificate to a log, the log returns a “Signed Certificate Timestamp” (SCT), which is a promise to include the certificate in the publicly accessible log.
• The resulting SCTs from each log are included in the final certificate.
• When a browser reads the certificate, it checks to make sure the included SCTs are from trusted logs before it considers it valid.

Where are the Certificate Transparency logs?

By design, the certificate transparency ecosystem is distributed. The idea is to ensure there are enough folks hosting and monitoring the logs to catch any bad actors. Many companies in the web PKI space run logs, including Let’s Encrypt, Google, Sectigo and Digicert. As mentioned earlier, Chrome and other browsers require a minimum of 2 SCTs to consider a certificate valid.

Each browser vendor has a list of CT logs that it considers usable or qualified.

You can find them here:

• Chrome
• Safari
• Firefox - Uses the same list as Chrome, but the link goes to the header file containing them in source.

Log Shards

Because there are so many certificates issued every day, the logs are broken in to shards. The shards are broken up by date. For example, you’ll see that Google’s Argon log has a 2026h1 and 2026h2 shard. This roughly corresponds to the first half and second half of the year. The NotAfter date of the certificate is used to decide which log it goes to.

Types of Logs

There are two types of CT logs. The OG logs are called RFC 6962 logs and the new logs are variously called tiled logs, static-ct logs or sunlight logs, depending on context and how old the information you’re looking at is. Both are based on Merkle trees.

It’s beyond the scope of this post to get in to the nitty gritty, but if you are interested you can do worse than read Russ Cox’s post on the subject. Let’s Encrypt also wrote a blog post explaining the rationale for switching to tiled logs.

The old RFC 6962 logs suffered from scalability issues and large hosting costs. Tiled logs are a response to those problems. The downside is the read-path for each kind of log is different - which means different approaches are required to scan them. (More on this in the next post)

How big are the logs?

The short answer is very big. There are billions of certificates stored in the various logs, and there will be even more when certificate lifetimes fall to 47 days. You can explore the data a bit using Cloudflare’s helpful Radar website. At the time of this writing there were 96 million unique certificates and 103 million unique precertificates issued in the last 7 days. It’s a lot of data.

Conclusion

There’s a lot of interesting data in the Certificate Transparency logs, but it’s not stored in a very searchable format. Our goal in the next post is to start scanning the logs and pulling the data. Given the sheer volume of data in the logs this is not a trivial task. The fact that there are two separate types of logs also makes things more complicated.

In part 2, we’ll write Golang code to pull Certificate Transparency Log entries and process them at scale. Then in part 3, we’ll figure out how to store them in Clickhouse.

Last week, someone commented on my post about 47-day certificates:

users need to stop being stupid .. and revoke the certs … i mean you can go online and look at every cert issued … replace and revoke them .. that’s the users fault don’t force 45 day certs on the rest of us.

This perfectly captures our collective delusion that SSL certificate revocation works. You click a button, the certificate stops working.

And why wouldn’t we believe that? Every CA has a big “Revoke Certificate” button right there in the dashboard. It must do something, right?

Here’s the dirty truth: most revoked certificates keep working. We’ve known this for years, but we just keep the security theater going.

The revoked certificate that (mostly) still works

Let’s say you have a website called revoked.badssl.com. You suspect the private keys were compromised, so you want to revoke the certificate. Easy right? There’s a command line for that:

certbot revoke --cert-path /path/cert.pem

Success! It returns “Congratulations! You have successfully revoked the certificate”. Great! Go check it. Really, go load that URL. I’ll wait.

Depending on which browser you’re using, you’ll see different results. Chrome shows a scary “Your connection is not private” page, but Safari and Firefox loaded it just fine.

This isn’t because Safari and Firefox are broken or inferior. Every browser handles revocation differently. Chrome caught this one because someone at Google manually added this high-profile example to their CRLSet. Firefox and Safari might catch a different revoked certificate that Chrome misses.

Three browsers, three different revocation systems, three different results for the same revoked certificate.

This isn’t some obscure edge case. This is a certificate explicitly revoked for key compromise, the most serious reason possible. And whether it gets blocked depends entirely on which browser you happen to be using and whether that particular certificate made it into that browser’s proprietary revocation list.

A brief history of failing at revocation

CRLs: the small-scale solution

What is a certificate revocation list? Certificate Revocation Lists (CRLs) were simple. A X.509 standardized list of bad certificate serial numbers. When a certificate gets revoked, add it to the list. Browsers download the list and check if the certificate is on it. Easy.

This worked great when the internet only had hundreds of certificates.

But just a few years later, CRLs were already becoming unwieldy. Some CRLs grew to hundreds of megabytes. Imagine every browser downloading a 300MB file from every Certificate Authority, multiple times per day. On dial-up.

In addition to the size problem, CRLs were also constantly unavailable and hopelessly out of date as Certificate Authorities (CAs) struggled to scale their infrastructure with the exploding scope of the web.

OCSP: the cure is worse than the disease

In 1999, the IETF published RFC 2560 introducing OCSP (Online Certificate Status Protocol). Instead of downloading entire lists, browsers can query for specific certificates as needed. Real-time revocation checking.

Unfortunately, the CAs weren’t any better at keeping OCSP online than they were at CRLs. Mozilla’s reported that nearly half of their system failures were due to OCSP service outage or malformed OCSP responses. Google’s data showed median OCSP checks taking 300ms, with means approaching a second. Load a modern website with resources from 20 domains? That’s potential seconds of delay just for revocation checking.

OCSP was too slow and unreliable enough to count on for certificate checking. So what do we do when its offline?

1. Hard-fail: Block the connection. Sounds secure, except now every OCSP outage breaks the internet. One CA has an outage and millions of users can’t access sites.

2. Soft-fail: If OCSP doesn’t respond, allow the connection anyway. This is what browsers actually do.

That doesn’t sound so bad until you realize that the only time you really need OCSP is when you are being attacked, and the attacker can probably block OCSP requests if they are sending you an invalid certificate.

As Google’s Adam Langley said,

Soft-fail revocation checks are like a seat-belt that snaps when you crash. Even though it works 99% of the time, it’s worthless because it only works when you don’t need it.

As one final nail in the OCSP coffin, the architecture has a huge privacy problem. Every OCSP query tells the CA exactly which websites you’re visiting in real-time. Your browser checking the certificate for adultwebsite.com? The CA knows. Maybe the ISP too. Get ready for some uncomfortable targeted ads.

The industry tried to band-aid these problems with OCSP stapling. Let the webserver fetch its own OCSP response and include it with the certificate. No more privacy leaks. No more performance hit. No more soft-fail dilemma.

Clever solution, except it requires server operators to actually configure it. According to Netcraft’s SSL Survey, less than 5% of sites have OCSP stapling properly configured. Even when stapling is configured, it’s often broken. The stapled response expires, doesn’t get refreshed, and browsers fall back to soft-fail OCSP. We’re right back where we started.

Browsers gave up on OCSP and reinvented CRLs

The CRL vs OCSP debate is pointless when both proved fundamentally broken. Here’s where it gets absurd. After abandoning CRLs for being too big, then abandoning OCSP for being broken, browsers went back to… downloading lists of revoked certificates.

But instead of fixing the problem, they each built their own thing.

Chrome created CRLSets. As Adam Langley explained in the announcement, Chrome would crawl CRLs, compress them, and distribute updates through Chrome’s update mechanism. Except they only include “important” revocations.

How many is “important”? About 24,000 certificates. Meanwhile, crawling actual CRLs reveals over 2 million revoked certificates in the wild. That’s 98% of revoked certificates that Chrome simply ignores.

Google’s Adam Langley defended this saying CRLSets are “primarily a means by which Chrome can quickly block certificates in emergency situations.” Not comprehensive revocation checking. Just emergency response.

Firefox tried harder with CRLite, using Bloom filters to compress the full CRL dataset into about 10MB. Clever engineering, but the false positive rate means some valid certificates get flagged as revoked. The update lag means recently revoked certificates still work for days weeks.

Apple? They aggregate CRLs at the OS level. The details are fuzzy because Apple doesn’t document it, but your Mac is quietly downloading revocation lists in the background. The implementation is opaque and inconsistent.

Three major browsers, three different revocation approaches, three different sets of revoked certificates they’ll actually block. That certificate you revoked? Maybe it stops working in Chrome next week. Maybe Safari blocks it next month. Maybe Firefox never notices.

Everyone went back to CRL-style lists. Just proprietary, incompatible versions that work differently across browsers. A revoked certificate might be blocked in Chrome but work fine in Safari. Security theater at its finest.

The CA/Browser forum knows revocation is broken

The best part? Everyone knows this is broken. The CA/Browser Forum discussions are filled with admissions of defeat.

In a 2017 discussion, Ryan Sleevi from Google stated bluntly: “Revocation checking doesn’t work. It’s not a matter of opinion, it’s a matter of fact demonstrated through data.”

The Mozilla CA policies contain thread after thread of CAs reporting OCSP failures, arguing about CRL sizes, and generally acknowledging the whole system is held together with prayer and duct tape.

My favorite is from the discussion about shorter certificates: “Given that revocation is fundamentally broken and we have no realistic path to fixing it, shorter certificate lifetimes are our only option.”

There it is. The admission. We can’t figure out how to revoke certificates, so let’s just make them expire faster.

The industry’s “solution”: just give up

And that’s exactly what we’re doing. Can’t revoke certificates? Just make them expire before compromise becomes a problem.

The timeline tells the story:

• 2011: Certificates could be valid for 5+ years
• 2015: Maximum drops to 3 years
• 2018: Down to 2 years
• 2020: 398 days (just over 1 year)
• 2026: 200 days coming soon
• 2027: 100 days
• 2029: 47 days

The browsers pushed for 47-day certificates because they knew they couldn’t make certificate revocation work correctly. If we can’t revoke a compromised certificate, at least it’ll expire soon. 47 days of exposure is better than a year.

Except now everyone needs automated renewal. The same organizations that couldn’t configure OCSP stapling now need to rotate certificates every month and a half.

Living in a post-revocation world

So here we are. The entire SSL certificate revocation system is broken. Everyone knows it’s broken. The browsers gave up trying to fix it. The CAs keep the infrastructure running because compliance requires it. And we all pretend it works.

That “Revoke Certificate” button in your CA dashboard? It updates some lists that mostly nobody checks. Your revoked certificate goes into a CRL that’s too big to download, gets flagged in OCSP that browsers ignore, and maybe, eventually, possibly, gets added to Chrome’s CRLSet if Google feels like it.

The one silver lining? If you’ve got Perfect Forward Secrecy enabled, at least that compromised certificate can’t decrypt your historical traffic. Broken revocation means the attacker can still impersonate you, but they can’t read last year’s secrets. Small victories.

This is the broken system we’re protecting with 47-day certificates. Not fixing revocation, just making certificates expire fast enough that we can pretend revocation doesn’t matter.

The future isn’t better certificate revocation. It’s accepting that revocation failed and building systems that assume it doesn’t exist. That’s why we built CertKit. If we’re stuck renewing certificates every 47 days anyway, might as well automate it properly.

Because the one thing worse than broken certificate revocation is manually managing certificates that expire every month and a half.

CertKit automates certificate lifecycle management for the post-revocation world. Since we can’t revoke certificates, we might as well make sure they never expire.

Turns out the scariest thing about SSL certificates isn’t when they expire. It’s when they don’t.

I wrote about the CA/Browser fight that led to the 47-day certificate mandate. CAs crying about lost revenue, browsers flexing their root program authority, enterprises stuck in the middle.

But nobody talks about the security research that started it all: BygoneSSL at DEFCON 2018.

Two researchers mining Certificate Transparency Logs found something surprising. When domains change hands, the old owners keep their certificates. Still valid and still trusted. Over 1.5 million domains with stale “bygone” SSL certificates. Even one of our own certificates.

These domains came from startups that pivoted. Projects that got sold off. Subdomains delegated to vendors. Expired domains someone else bought. All with valid certificates owned by someone else.

This is why we’re getting 47-day certificates. Not because browsers hate us. Because certificates that last years are fundamentally broken when domains change hands in months.

The Stripe problem that should scare everyone

Stripe (the payment processor) bought stripe.com in 2010. Started processing payments. Built the payment infrastructure for half the internet.

The previous owner’s certificate was valid until 2011.

For an entire year, someone else had a perfectly legitimate SSL certificate for Stripe’s payment processing. Trusted by every browser. No warnings. No errors. Just a valid cert for someone else’s billion-dollar payment system.

They didn’t use it. But they could have.

This wasn’t a Stripe’s screwup. Nobody thought about old certificates when they start a new project. It wasn’t on anyone’s checklist to revoke the old certificates. BygoneSSL found them everywhere: Big companies, small companies, that side project you sold last year. All vulnerable to the same temporal trust problem.

Certificate validation checks if you control the domain right now. Not if you’ll control it next year. Or if you controlled it last year. Just now.

Then it gives you a certificate that lasts for years. And that’s the problem.

What BygoneSSL actually found

Ian Foster from UC San Diego and Dylan Ayrey (now CEO of Truffle Security) did what security researchers do. They were curious about how things worked. They analyzed 3 million random domains. Just a 1% sample of the internet. The results:

• 0.45% had valid certificates owned by previous owners. Extrapolating that out, 1.5 million domains globally where someone else has your keys.

• 2.05% shared certificates with bygone domains. Those multi-domain certificates everyone uses? If one domain changes hands, the new owner can revoke the entire certificate. Seven million domains vulnerable to denial of service.

• 41% of these certificates were still valid. Not expired. Not revoked. Just floating around. Waiting.

CDN certificates were the worst. One cert with 700 domains. One bygone domain on that list means one person can kill service for 699 other sites. With a single revocation request. That’s a massive Denial of Service attack waiting to happen.

Here’s the weird part. No documented attacks. No CVEs. No breach notifications.

Foster and Ayrey dropped this research at DEFCON. Released detection tools immediately. CertGraph to map certificate relationships. BygoneSSL scanner to find vulnerabilities. Modified CertSpotter for continuous monitoring.

Free tools. Open source. Available before any bad actors could weaponize the research.

The security community ran with it. Started scanning. Started fixing. Started freaking out about what they found.

But the CAs? They called it theoretical. A non-issue. Nothing to worry about.

Right. Tell that to the 1.5 million vulnerable domains.

Why revocation doesn’t save you

You might think: “Just revoke the old certificates when domains change hands.”

Yea, certificate revocation doesn’t actually work. It’s been broken for years. OCSP checks fail open. Browsers cache responses for days. CRLs are too big to download. Chrome doesn’t even check revocation for most sites anymore.

Even if revocation worked perfectly, who’s tracking which certificates to revoke? The previous owner who sold the domain? They’re gone. The new owner? They don’t know what certificates exist. The CA? They have no idea the domain changed hands.

The only reliable way to kill a certificate is time. Let it expire naturally.

That’s why shorter certificates matter. Not for convenience. For security.

At least with Perfect Forward Secrecy, those bygone certificates can’t decrypt historical traffic. They can only impersonate you going forward. Small comfort, but it’s something.

With three-year certificates, a domain could change hands and the old owner keeps cryptographic authority for up to three years. Add domain validation reuse periods and you get 4.5 years of exposure.

With 398-day certificates (what we have now), it’s better but still bad. About two years of vulnerability.

With 47-day certificates? Maximum exposure drops to 57 days. Domain changes hands on Monday. By the end of next month, old certificates are already dying. Zane Ma quantified this in 2024. His research showed 45-day certificates would reduce domain takeover attacks by 95%.

That’s why we are getting 47 day certificates.

Your certificates are everywhere

Check your Certificate Transparency logs sometime. You can use our free Certificate Transparency Log search. Count how many certificates exist for your domains.

Now think about where they all came from:

• That marketing agency you worked with two years ago
• The CDN you tried and abandoned
• Your previous hosting provider
• That contractor who set up your staging environment
• The vendor who managed your subdomain
• Your predecessor at the company

Every one of them might still have valid certificate for your domain. Right now. Especially if you have any multi-domain certificates.

What if your company sold off one of those domains?

This isn’t paranoia. It’s the reality of how WebPKI works.

Certificate management is now a requirement.

BygoneSSL didn’t replace the old problems. It added new ones.

You still need to prevent downtime. Certificates still expire. Sites still go down. The CEO still notices before you do.

But now? Now you also need visibility into certificates you didn’t even know existed.

That spreadsheet tracking expiration dates? You still need something like that. But it’s not enough anymore. Doesn’t show you the certificate your former vendor still has. Or the one issued to that subdomain you forgot about. Or the 15 certificates in CT logs that you definitely didn’t request.

Manual processes were already failing at the basics. Now they’re completely outmatched.

You need automated renewal. Obviously. 47-day certificates mean monthly rotations.

But you also need discovery. To find certificates you didn’t issue.

And monitoring. For the things that go wrong.

Used to be you just worried about your own certificates expiring. Now you worry about everyone else’s certificates not expiring.

Fun times.

What happens next

March 2026: Maximum certificates drop to 200 days.
March 2027: 100 days.
March 2029: 47 days.

The timeline’s set. Automation is mandatory now. The certificate that wouldn’t die is finally getting an expiration date that matters.

Time to make sure you’re ready.

CertKit automates certificate management because BygoneSSL proved that manual processes are a security vulnerability. Not because we love certificates. Because ignoring them is no longer an option.

For twenty years, Certificate Authorities ran the perfect protection racket.

Nice website you got there. Shame if it was “Not Secure.” That’ll be $300 a year.

The CAs had a beautiful monopoly. Browsers needed them to keep users safe. Websites needed them to look legitimate. Everyone paid up, nobody asked too many questions. Then the cryptography of most certificates (SHA-1) got shattered, and the browsers realized they’d been played.

This is the story of how certificate lifetimes went from 3 years to 47 days, why the CAs fought every second of it, and what it means for your certificates.

How server certificates work

It’s called the WebPKI: the Public Key Infrastructure. Companies called “Certificate Authorities” (CA) create a Root Certificate. From that root, they sell you a certificate that proves you are who you are, and you use it to secure your website.

For that to work, the Root Certificate needs to be included with Chrome, Firefox, Safari, and all the other browsers and certificate consumers out there. Here’s how it works:

1. Joe opens mysite.com in Firefox
2. mysite.com says, “ExampleCA said I’m cool”
3. Firefox has the ExampleCA Root Certificate, so shows Joe that mysite.com is indeed cool

For Firefox to trust the ExampleCA Root Certificate, they needs to meet a set of security and operational standards called the Baseline Requirements. This is the common rulebook that CAs are audited against for compliance.

The Baseline Requirements are created and maintained by the CA/Browser Forum, a self-regulating organization of CAs and Browser vendors that try to improve the security of the internet through consensus votes on changes to the Baseline Requirements.

But here’s where it gets interesting: Each browser also maintains its own Root Program with additional requirements beyond the Baseline Requirements. Chrome has one. Apple has one. Mozilla has one. If a CA wants their root certificate trusted, they need to follow both the Baseline Requirements AND each browser’s specific rules.

For years, this system worked. CAs issued certificates that lasted up to three years. If something went wrong, there was supposedly a certificate revocation system (CRL), but everyone knew it was broken. Too slow, too unreliable, too privacy-invasive. Chrome doesn’t even check revocation lists. So if a certificate was compromised, you just waited for it to expire. In three years.

This delicate balance held until SHA-1 showed everyone what “waiting” really cost.

The SHA-1 Betrayal

Each certificate is based on a cryptographic algorithm, and one of the most popular algorithms was SHA-1, developed by the NSA.

But in 2005, the first attack was published against SHA-1, showing that it could be cracked open, however it would require over $100,000 in processing power to do it.

The CA’s weren’t worried. “It’s only theoretical,” they said. “Too expensive to be practical.” The protection money kept flowing.

In 2015, the severity of the problem escalated when researchers proved that SHA-1 could be cracked in a few minutes with a $2,000 video card in an event named “The SHAppening”.

The response from CAs was predictable: “Our customers aren’t ready. The migration is too expensive. We need more time.”

Microsoft disagreed, and in one of the first major challenges to the CAB forum, unilaterally said that SHA-1 certificates could not be created after 2016. No votes. No discussion. It was insecure for their users and they weren’t going to allow it anymore.

But because certificates were valid for 3 years, that meant that SHA-1 certificates could still be floating around until 2019, nearly 15 years after the algorithm had first been cracked.

Consensus is where progress goes to die

Over the next few years, various people and browser vendors tried to address the underlying problems of long certificate lifetimes, only to be met with stonewalling and frustration.

Ballot 185: Google’s attempt to prevent the next SHA-1 (2017)

Fresh off the SHA-1 disaster, Google’s Ryan Sleevi proposed reducing certificate lifetimes from three years to 398 days (13 months).

The logic was straightforward:

• Broken certificates naturally expire faster
• Annual renewals align with existing IT maintenance cycles
• Problems like SHA-1 can be fixed in one year instead of three
• Since revocation doesn’t work, expiration is our only reliable tool

The CAs protected their turf. Only 8% of Entrust’s customers had automation—that meant 92% were still paying for manual processes and support. DigiCert worried about enterprise customers with complex approval processes. Smaller CAs argued it would drive customers to the big players who could afford automation infrastructure.

When the vote came, the measure had failed due to overwhelming opposition from the CA’s.

Ryan’s frustration boiled over on Twitter:

Carefully consider the commitment to security of any CA who votes No [to Ballot 185].

He was calling out the racket directly. The CAs weren’t protecting users—they were protecting revenue.

Ballot SC22: The alliance of browsers (2019)

Two years later, Google returned with Apple and Let’s Encrypt backing them. They had new evidence:

• Between certificate lifetime and domain validation re-use, stale certificates could persist for up to 4.5 years!
• Domains change hands frequently, but old certificates remain valid
• Support tickets proved customers literally forgot their renewal procedures after two years

The CAs demanded evidence of real-world harm, not theoretical problems. “Show us actual incidents,” the CAs said.

The browsers pointed to SHA-1. That was theoretical until it wasn’t.

The vote split exactly as before. Browsers: unanimous yes. CAs: overwhelming no.

The committee had failed twice.

Apple changes the game (2020)

At the February 2020 CA/Browser Forum meeting in Bratislava, Apple made an announcement that changed everything:

Effective September 1, 2020, certificates valid for more than 398 days will not be trusted in Apple products.

No vote. No consensus. Just a unilateral change to their Root Program requirements. They cited the forum’s failures to pass Ballot 185 and SC22 as reasons they needed to act alone.

The CAs were stunned. Chris from Entrust captured their sentiment: “The Forum was created to set these policies together. This undermines the entire process.”

But Mozilla and Microsoft countered: “We saw the same resistance with SHA-1. After the ballot failed, CAs didn’t move. Sometimes we have to act to protect users.”

Within days, Mozilla and Google signaled they would follow Apple’s lead. The 398-day limit was happening whether CAs liked it or not.

Ballot SC31: Browser Alignment (Late 2020)

The Baseline Requirements were, at this point, very different than the practical rules of the browsers’ Root Programs. To make them useful again, the browsers wanted to update the Baseline Requirements to reflect what was already happening: Apple’s 398-day limit that others were adopting, amongst other things.

This vote became existential. If the Forum couldn’t even update its requirements to match reality, why does the forum exist?

Ryan Sleevi laid out the stakes: If CAs blocked this, browsers may as well abandon the Forum entirely. Instead of one shared audit against Baseline Requirements, each browser could require its own separate audit. The cost multiplication to CAs would be devastating.

Faced with this reality, SC31 passed. But the power dynamic had permanently shifted. Browsers could now make unilateral changes and force the Forum to catch up.

Risks of stale certificates mount

By 2024, there was mounting evidence of the dangers posed by even 398-day certificates. Certificates only represent validation at the moment they’re issued. But that validation was being cached for up to a year, and certificates issued from that cached validation lived even longer.

Ian Foster and Dylan Ayrey coined [this “stale certificate” problem as BygoneSSL. Their research showed a simple but devastating issue: domains change hands constantly (companies switch vendors, contracts end, or subsidiaries get sold) but the certificates remain valid. A fired vendor could have legitimate certificates for your subdomain for over a year after you terminated their access.

Then, Zane Ma from Oregon State University presented research at the October 2024 CA/Browser Forum meeting that quantified exactly how bad this was. His paper found that 7% of all certificates were stale, and that shortening certificate lifetimes to 45 days would reduce the impact of domain takeover attacks by 95%. The difference between 398 days and 45 days wasn’t incremental improvement, it was the difference between massive vulnerability and relative safety.

The Market proved short-term certificates work (2024)

But the final nail in the coffin was market data. Let’s Encrypt grew from 0.1% market share in 2020 to 59% in 2024.

Let’s Encrypt is a non-profit CA launched in 2016, backed by Mozilla, the EFF, and other tech giants who were tired of certificates being a barrier to HTTPS adoption. Their radical idea: give away certificates for free, make the process completely automated, and only issue 90-day certificates. No upsells. No extended validation. No manual processes.

CAs said it would never work. Enterprises couldn’t handle 90-day certificates. The automation was too complex. Customers needed phone support. But 8 years later, Let’s Encrypt issues certificates for the majority of the encrypted web. They process millions of renewals daily. All automated. All 90-day lifetimes. And users don’t know or care about the difference between a free, short-lived cert from Let’s Encrypt and an expensive, year-long cert from Digicert.

The road to 47 days (2025)

Spurred and shamed by Zane Ma’s research and the success of Let’s Encrypt, in January 2025, Apple, Google, and Mozilla introduced Ballot SC081 with a shocking timeline to reduce certificate lifetimes:

• March 2026: 200 days maximum
• March 2027: 100 days maximum
• March 2029: 47 days maximum

The CAs tried to protect their turf: Enterprise customers have change freezes. Government systems require extensive approvals. Legacy applications can’t automate. Please, keep 100 days as the minimum.

But unexpected support came from the customers themselves. Netflix joined the CAB as an “Interested Party” to share: “We need these deadlines to justify automation investment internally. Approval of this ballot is justification enough to resource this work.”

Even Cisco, representing the enterprise perspective, admitted that while five years would be ideal for implementation, the direction was inevitable.

The most telling objection came from a CA: “This proposal seems anti-competitive, giving advantage to companies with better certificate lifecycle management.” They were right, and that was exactly the point. It’s time to automate or get out of the way.

The vote didn’t really matter. If it didn’t pass, Apple or Google or Mozilla was going to do it anyway. But the CAs agreed and 47 day certs became reality.

What happens next

47 Day certificates are happening. The real question is whether your infrastructure will be ready.

Some companies are already there. They’ve been using Let’s Encrypt for years, renewing every 60-90 days automatically. Dropping to 47 days is just a configuration change.

Others are scrambling. They’re evaluating ACME clients, testing automation workflows, and discovering just how many random systems need certificates: that ancient Java application, network appliance, or vendor system that only accepts manual certificate uploads.

And many are just now realizing what’s coming. They’re still on manual processes, still treating certificate renewal as a quarterly maintenance task. They’re about to have a very bad time.

The new certificate business

The same CAs that insisted automation was impossible for their customers are now selling automation platforms: DigiCert CertCentral, Entrust Certificate Hub, Sectigo Certificate Manager. How much extra are they charging for these tools? Contact sales to find out, of course.

The irony is rich. For years, CAs said enterprises couldn’t handle 90-day certificates. Now they’re selling those same enterprises “solutions” to handle 47-day certificates. The certificates themselves? Basically free, thanks to Let’s Encrypt. The management platforms? That’s where the real money is now.

Instead, lots of folks build the automation themselves based on CertBot and bash scripting. But you quickly find that all the features of a Certificate Management System are difficult to debug and maintain when you have a thousand other responsibilities.

The CAs will charge you enterprise prices to manage the complexity they helped create. Or you can build your own solution and discover why certificate management is everyone’s least favorite infrastructure project.

That’s a crappy choice, and it’s why we built CertKit. Because we don’t have conflicting interests. We don’t sell certificates. We just want certificate management to not be your problem anymore.

CertKit is certificate management software built for the 47-day future. Currently in beta for teams who’d rather automate now than panic in 2029.

You were tired of renewing all those certificates, and Certbot looked so easy. Now you have scripts thousands of lines long filled with command line incantations you have to Google every time you open it. The script is running on all the critical servers. And some of the printers.

If someone looks at it the wrong way, a certificate expires.

“It’s just Certbot - How Hard Could It Be?”

47 lines of bash. Beautiful. Clean. Renewed the web cert, sent a Slack message. It was perfect for three whole months.

Then marketing needed wildcards.

Then security demanded monitoring. Not just “is it valid” but “what’s the cipher strength” and “who touched it last” and fifteen other things nobody looks at.

The CEO wanted an email if anything is going to expire soon.

Now it’s thousands of lines long. Running as root. Via cron jobs that fire at different times because “we don’t want to hammer Let’s Encrypt.”

Your script needs OpenSSL 1.1.1 exactly. Bob’s AWS credentials from line 1,847. That Jenkins job nobody remembers. Touch any of it and production goes down.

What Proper Certificate Management Could Do

If only you could do it over again. You could build a proper certificate management system. It would do more than just renew the certificates. It would do useful and professional things like:

Certificate Discovery. Scan your domains and find the certificates you forgot existed–or never knew about. Your script manages a hardcoded list in a text file. Maybe a spreadsheet if you’re fancy.

Certificate Inventory. Proper systems would know every certificate in your infrastructure. Yours? It knows about the ones you told it about. That Jenkins server from 2019? The VPN appliance? That staging environment on Bob’s old laptop? Nobody’s tracking those.

Certificate Transformation. Need to convert PEM to PFX for that Windows server? Your script shells out to OpenSSL with parameters you copied from Stack Overflow. Works great until someone needs PKCS#12 with specific cipher suites.

Certificate Expiry Monitoring. The old script just checks the certificate in the filesystem–not what’s actually running. If something failed to update, you’ll know when users start complaining.

Secure Distribution. Your script has root SSH access to everything. Security loves that. Or it’s copying private keys through a shared folder. Or that one team that uses Git for cert distribution.

The Features You’ll Never Get Around to Building

You tell yourself you’ll add these features “next quarter.” You won’t.

Role-based access control. Right now everyone who needs to manage certs has root access to the script server. That’s fine, right?

Audit trails. Who renewed what when? Who knows. The script doesn’t log that. Check the bash history if it hasn’t rolled over.

Alerting that works. Email alerts go to a distribution list that nobody reads. Slack integration? That’s on the roadmap. Has been for two years.

Backup and recovery. The script is in Git. Probably. Someone might have committed the latest version. The certificates themselves? Hope you have backups.

Multi-region support. Each region has its own slightly different version of the script. They diverged years ago. Nobody knows what the differences are anymore.

It’s Time to Get Help

Look, your homegrown system meant well. You learned what breaks. What matters. What you actually need from certificate automation.

Now let someone else worry about all the ACME protocol changes on the weekend, distribution, monitoring, and other tasks. Get back to the work that you should have been doing. That’s what we’re building with CertKit.

Simple, Centralized, Transparent TLS Certificate Management.

Not a bash script held together with hope and regular expressions.

CertKit is certificate management for companies tired of maintaining their own broken systems. Currently in beta, accepting teams who’ve learned this lesson the hard way.

SSL Certificates have always been a pain in the butt.

From the magical OpenSSL incantations to generate a CSR to the various formats that each webserver requires. Remembering what hardware needs which certificates. Managing scheduled renewals and runbooks for which file goes where.

Screw anything up and your site is “Not Secure”.

And now Apple wants us to do it every 47 days.

Remember when we had HTTP-only websites? Or when certificates lasted three years? Then one? At this rate, by 2030 we’ll be renewing certs for every request.

Our Breaking Point

Last year, I watched a perfectly competent DevOps team spend six hours debugging why their automated certificate renewal stopped working. The culprit? CertBot updated, their ancient Ubuntu install didn’t, and the ACME protocol had “opinions” about TLS versions.

Six. Hours.

That’s when we decided we needed to build something better. Not another command-line tool that works–until it doesn’t. Not an enterprise PKI suite that requires a PhD to operate. Just something that handles certificates and gets out of the way.

We Tried Everything Else First

Trust me, we didn’t want to build another tool. We tried them all.

CertBot? Works great. For one cert on one server.

Need wildcard certificates across a web farm? Now you’re writing special routing rules. Opening port 80. Praying the validation server stays up.

Got the cert? Cool. Now distribute it to 50 other servers. Hope you like rsync. The official CertBot solution for multiple servers is literally “figure it out yourself.”

I’ve seen it all. Dropbox folders full of private keys. Git repos anyone can clone. That one team using Ansible until they accidentally pushed to production instead of staging.

Whoops.

CertBot conflates certificate renewal with certificate distribution.

Cert Manager? Fantastic if your entire infrastructure lives in Kubernetes and you enjoy writing YAML manifestos. For the rest of us living in the real world with legacy systems, Windows servers, and that one critical app running under Bob’s desk? Not so much.

Commercial solutions? DigiCert wants to sell you an “enterprise certificate lifecycle management platform” starting at just $call-for-pricing. What a deal!

So we built CertKit. Here’s what makes it different.

Transparency That Actually Helps

Every certificate management tool claims to offer “monitoring.” What they mean is an email when something expires. Maybe a dashboard if you’re lucky.

CertKit shows you everything. Which certificates are where. When they were last checked. What’s about to expire. What already expired but nobody noticed because it’s on that staging server everyone forgot about. Realtime monitoring the Certificate Transparency logs to know everything happening. Real monitoring means knowing about problems before they become problems.

And alerts? They go where you actually look. Email, Slack, Teams (if we have to).

A GUI That Doesn’t Suck

I know, I know. Real sysadmins prefer their certificate management artisanal. Hand-crafted bash scripts. Locally-sourced cron jobs. Small-batch OpenSSL commands passed down through generations.

But you know what? Sometimes I just want to click a button and add a certificate without writing a config file. Sometimes the new junior admin needs to provision a cert without learning the entire ACME RFC.

CertKit has a dashboard that actually makes sense. Add certificates, remove them, see what’s happening. No need to SSH into three different boxes to figure out why something’s broken.

The SSL Certificates You Forgot About

That Jenkins server from 2018. The VPN appliance. The marketing WordPress site. CertKit discovers certificates across your infrastructure automatically. No more surprise expirations from forgotten systems.

It Just Works™

This is the part where I’m supposed to say “robust enterprise-grade reliability” or some nonsense you’d find in a whitepaper.

Here’s what I mean: CertKit doesn’t break when your Linux distro updates. Or when Let’s Encrypt changes their API. It handles the edge cases because someone’s actually paying attention.

Unlike the bash script Terry wrote in 2019 before he left for a “better opportunity”, someone’s maintaining it. We’re fixing it before you even know it’s broken.

Centralized Without the Single Point of Failure

“But what if your service goes down?”

Fair question. But CertKit isn’t in the critical path. We push certificates to your infrastructure. If we go down, your sites keep running with their current certs. You’ve got time to fix things.

Compare that to distributed setups where every server runs its own renewal process. One fails, you might not notice until customers complain.

DNS Without the Security Nightmare

Want wildcard certificates? Every tool makes you hand over your DNS API keys. Full access to your entire domain. What could go wrong?

CertKit uses delegated DNS validation. We only touch TXT records for ACME challenges. Can’t accidentally delete your MX records. Can’t redirect your domain to a crypto scam–even if it’s going to the moon. Just the minimum access needed for certificate validation.

This will be even easier when the new DNS-PERSIST-01 validation method launches.

The Future’s Getting Worse

How long can digital certificates be valid? If you ask Google, not very long. Right now you can get a 1 year certificate. Next March, you’ll only get 200 days.

March 2027? 100 days.

We’re on the way to 47 day certificates.

Some people are seriously discussing daily certificate rotation.

Daily.

Your full-time job is renewing certificates now.

Manual processes won’t cut it. Half-baked automation will break constantly. You need something built for this insane future we’re heading toward.

That’s why we built CertKit. Not because we love certificates. Because we’re tired of them.

Let Us Worry About SSL Certificates

Look, I’m not going to pretend CertKit’s perfect. Nothing is. But it’s better than what you’re doing now. And it’s getting better with every release from our roadmap.

Stop maintaining your own certificate infrastructure. Stop debugging renewal failures. Stop explaining to management why the certificate expired.

Just let CertKit handle it. Your future self will thank you.

CertKit is TLS certificate management software for people who have better things to do. Currently in beta, accepting users who are tired of SSL certificate hell.