CertKit Blog

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.