CertKit Blog

Agent 1.9 adds remote push updates so you can upgrade your entire fleet from the dashboard, plus first-class support for Google Trust Store as an ACME certificate issuer alongside Let’s Encrypt.

Certificate management vendors use the word “trust” so often it stops meaning anything. They also won’t tell you what the product does, or what it costs, without a sales call first. These are, I should note, security companies.

We launched the beta in July 2025. Over 600 users later, the beta is over. Here’s what we built, what we learned, and a thank you to the early adopters who helped make it real.

Agent 1.8 closes the last gaps in Windows and Java certificate deployment. Write directly into the Windows Certificate Store, auto-detect Remote Desktop and Remote Gateway, drop JKS files for legacy Java applications, and use automatic variables in your update commands. Also: we shipped a retro MS-DOS modal on April Fools Day.

Let’s Encrypt ran their first annual mass revocation drill, shortening ARI renewal windows across 3 million production certificates. Here’s what happened.

CertKit manages your certificates from issuance through deployment. For most organizations, that includes holding your private keys. For some, that’s a hard no. The Local Keystore is for them.

Certbot solved certificate issuance. It’s great at that. The hard part is everything that happens after: getting the certificate file to every server that needs it, in the right format, with the right permissions, and confirming each one is actually serving it. Nobody handed you a solution for that.

When a CA has to revoke hundreds of thousands of certificates on a short deadline, email notifications aren’t enough. ARI is the protocol that lets the CA tell your client directly: renew now. Here’s how it works, and why most ACME clients can’t actually respond in time.

CertKit now polls Let’s Encrypt multiple times a day to check when each certificate should renew. That means mass revocations happen automatically, without you doing anything. We also added support for 6-day certificates for environments where 90 days isn’t short enough.

Certbot ran. The logs show success. Exit code 0. LinkedIn found out the hard way that renewed and deployed are not the same thing. The verify step is the part of certificate automation nobody builds until after the outage.

CertKit now supports team accounts with role-based access, multi-factor authentication, SAML single sign-on, and a weekly email digest. Here’s what shipped and why it matters.

The bar closes March 15. After that, no CA can serve you a 398-day certificate. If you’re still managing commercial SSL certs manually, you have two weeks to grab one last round of full-year runway before the 200-day era begins.

The CertKit Agent now supports Microsoft RRAS for VPN certificate management. We also added deploy windows so you can control when certificate updates happen, and agent locking to protect your infrastructure even if CertKit itself were ever compromised.

A stolen TLS private key sounds catastrophic. But thanks to forward secrecy, it can’t decrypt recorded traffic. The only thing left is server impersonation, and that requires network position that ranges from “be in the same room” to “be a nation-state.” We looked at the data on how often this actually happens.

We wrote about BygoneSSL and the 1.5 million domains with certificates owned by someone else. Then we bought certkit.dev and found one on our own domain. A DigiCert certificate, still valid for 98 days, issued to whoever owned this domain before us. Here’s what we found, what we tried to do about it, and what happened when we tried to revoke it.

CertKit can now deploy certificates directly to your servers. The CertKit Agent is a lightweight service for Linux, Windows, and Docker that detects your software, writes certificates where they need to go, and restarts your services automatically.

Most teams “automate certificates” by installing an ACME client and calling it a day. Then they still ship an outage because the hard parts were never automated: knowing what exists, keeping validation safe, and verifying what’s actually being served.

Your nginx doesn’t need to understand ACME. Your mail server doesn’t need DNS credentials. Your VPN appliance can’t even run CertBot. They just need a certificate file. CertKit handles validation centrally and lets your servers subscribe to certificates.

The CA/Browser Forum set 47-day certificates as the target for 2029. Let’s Encrypt decided to implement it a year earlier. Here’s their roadmap and what it means for your automation.

As your certificate count grows, so does the chaos. Applications let you organize certificates into logical groups with their own API keys and access controls. No more sharing credentials across your entire infrastructure.

Every service you onboard wants proof you control your domain. Most want your DNS credentials to automate that proof. There’s a better approach: CNAME delegation lets you authorize a service once without handing over the keys to your entire zone.

We just published our product roadmap. It’s interactive. Vote on what matters to you, or tell us what we’re missing entirely.

IT teams keep buying certificates from DigiCert and Sectigo because free feels risky. But the assumptions behind that trust are a decade old. Let’s Encrypt now secures 64% of the web, is funded by Google and AWS, and uses the same encryption as your $500 certificate. The real question isn’t whether free is good enough. It’s whether you’ve examined your objections lately.

A new ACME validation standard coming in 2026 lets you authorize a CA once and never touch DNS again for renewals. The security model is defensible, but even its supporters admit the optics are questionable.

You’ve been using wildcard certificates for years because they were simpler. One cert, one renewal, copy it everywhere. But now you’re automating anyway. If certificate management is no longer painful, do you still need wildcards? Or are they solving a problem that no longer exists?

CertKit now supports multi-SAN certificates, letting you cover multiple domains with a single cert. We also improved the certificate creation flow and made error messages actually useful.

HTTPS went from 40% to over 90% of web traffic in a decade and the ACME protocol made that possible. But ACME solved certificate issuance, not certificate operations. Getting a cert is easy now. Getting it onto all your servers is still your job.

We used to treat private keys like plutonium because losing one meant every encrypted conversation ever was compromised. Perfect Forward Secrecy fixed that. Now each connection gets temporary keys that vanish after use, so stolen certificates can’t decrypt old traffic. It makes private keys safe to touch.

In this post we’ll build a Clickhouse database schema to store billions of Certificate Transparency Log entries.

In this post we’ll write Golang code to pull Certificate Transparency Log entries and process them at scale.

Searching Certificate Transparency logs lets you uncover every SSL/TLS certificate ever issued for your domain. You can detect mis-issuance, unauthorized changes, or shadow infrastructure before it becomes a problem. It’s a good way to monitor your digital identity and maintain trust in your organization’s security posture.

SSL Certificate revocation is so broken that browser vendors gave up trying to fix it. Chrome manually curates 24,000 ‘important’ revocations out of 2 million. Firefox uses bloom filters that flag valid certs as revoked. Safari does something nobody can document. The industry’s solution? Pretend 47-day certificates solve the problem.

When domains change hands, old certificates don’t. Two researchers at DEFCON found 1.5 million domains with valid certs owned by someone else. This is the security research that killed long certificates. And why 47-day certificates aren’t just browser bureaucracy. They’re fixing a problem we ignored for 20 years.

For twenty years, Certificate Authorities ran the perfect protection racket. Then SHA-1 got shattered, Apple went rogue, and certificates went from lasting 3 years to 47 days. This is the story of how browsers broke the CA cartel, and why your manual certificate process is about to become your biggest problem.

It started as 47 beautiful lines of bash. Now it’s a distributed certificate system built on thousands of command line incantations nobody understands, running on every server and some of the printers. If someone looks at it the wrong way, a certificate expires.

SSL certificates have always been a pain. Now Apple wants us to renew them every 47 days. We watched a DevOps team waste six hours debugging CertBot, tried every tool from Cert Manager to DigiCert, then said screw it. We built CertKit - certificate management for people with better things to do.