Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

In October 2021 the NSA published an advisory titled “Avoid Dangers of Wildcard TLS Certificates.” It reiterated what security consultants had been saying for years: don’t use wildcard certificates. Single-name certificates per host are safer. Five years later, we counted the certificates that are actually used. One in three domains has a wildcard on it. For.bank domains, where you need a security review just to register, it’s four in five. Operators aren’t careless.

Most customers start CertKit with SSL host monitoring. On day one, you point CertKit at the systems you already run and get every certificate and when it expires. You start with confidence that you have everything under control. Then, you automate, letting CertKit take over the certificates as they need to be renewed. Each renewal is the last time you ever have to worry about that certificate.

In February, Let’s Encrypt announced that DNS-PERSIST-01 was coming, “some time in Q2 2026.” It’s October, and it’s nowhere close to ready. We’ve been waiting for DNS-PERSIST-01 since January, along with every other ACME client and lots of organizations. DNS-PERSIST-01 promised to simplify domain validation and make automation easier, but we had to wait on Let’s Encrypt. Let’s Encrypt is waiting on a redesign, a standards body, and maybe one more vote.

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.

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.

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.

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.

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.

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.

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.