Minneapolis, MN, USA
2025
  |  By Todd H. Gardner
If you run CertKit across multiple collections, September was your month. The new home page lets you search across all of them, the new dashboard surfaces the context you need, and a read-only API pulls it all into your external tools.
  |  By Eric Brandes
Technically: no. In practice: maybe. Lot’s of teams are experimenting with shorter duration certificates from Let’s Encrypt to get ready for the 47-day mandate. Those certs come with a big gotcha: no more Common Name. A modern browser is perfectly happy with a TLS certificate that has no Common Name. Your VPN or mail server might have other opinions. And since those are probably things you’d like to keep working, there’s a little more nuance to the answer.
  |  By Todd H. Gardner
A couple days ago, I told you how a spammer got a certificate for dev-docs.trackjs.com, and that we only found out because Google emailed us. Google knew because the spammer claimed the hostname in Search Console. An attacker running a phishing page wouldn’t have done that, but they would still need a certificate. Every publicly trusted certificate gets written to a public log, and we track that log in our database. We just weren’t watching it. Now we are, and you can too.
  |  By Todd H. Gardner
On August 27, Google sent us an email. We did not. We barely recognized the hostname. None of us had thought about dev-docs.trackjs.com in about ten years.
  |  By Todd H. Gardner
Certificate monitoring from the cloud only sees what the internet sees, like your public websites. But the vCenter console, the internal API, the switch management page, or that thing on db01.corp.internal are invisible to it. Those certificates expire just like public ones. They just don’t warn anybody first. This gap became very clear when we shipped Private PKI. Now CertKit can issue certificates for internal names and IP addresses, deploy them, and install the root into your trust stores.
  |  By Todd H. Gardner
There is a public record of every TLS certificate ever issued for your domain, and anyone can search it. Most people who run infrastructure have never heard of these certificate transparency logs. So I read our own log, and here’s what anyone could learn about CertKit from them.
  |  By Todd H. Gardner
You’re probably running a TLS configuration that the IETF says is “non-conformant”. But you didn’t do anything wrong. In July, the IETF published a pair of RFCs that took away three of TLS 1.2’s key exchange methods and froze the rest of it. The phrase they used is MUST NOT, the strongest thing a specification is allowed to say. Nginx, Apache, and Windows Server all ship with those key exchanges turned on by default. Nothing breaks tomorrow.
  |  By Todd H. Gardner
In May I wrote that you probably don’t need private PKI for internal infrastructure, because DNS validation gets a publicly trusted certificate onto hosts that never touch the internet. In June I pointed out that Apple enforces an 825-day cap on private certificates, so your own CA doesn’t even free you from the browser vendors. Two days ago I told you that public client certificates stop renewing in October, and that the replacement is a private certificate authority.
  |  By Todd H. Gardner
Chrome’s root program decides what certificates will be trusted by Chrome, and what they are allowed to do. Recently, Google decided that client authentication isn’t on the list. Under Chrome Root Program Policy v1.8, every certificate issued on or after March 15, 2027 can assert only one Extended Key Usage (EKU): server authentication. Let’s Encrypt moved early.
  |  By Todd H. Gardner
Every HTTPS connection starts with a TLS handshake. It’s the security check, answering “are you who you say you are?” and “how are we going to keep this conversation secret?”. There’s a lot going on during the handshake, and there used to be even more before it all got hacked and removed. And that’s useful to understand, the modern TLS 1.3 handshake is short because everything else got compromised.

Finally, a GUI for certificate management. No more checking if CertBot actually ran. CertKit gives you one dashboard to see every cert, every renewal, every domain—before they expire and ruin your weekend. Built after the third production outage from a failed ACME challenge that nobody noticed.

Just point a DNS CName at us, and we'll automatically discover, provisioning, validation, renewal, and deployment of certificates. Through an actual UI that can be easily monitored. Supports wildcards, multi-domain, whatever complexity you've accumulated over the years. No DNS API keys to leak. No cron jobs to debug. No Kubernetes required.

Built by the TrackJS team who are known for building simple and reliable tools that Just Work™️.