CertKit Blog

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.