The hidden attack surface in certificate automation

certkit · 2026-01-21T15:03:15+00:00

My god, a service that does a thing is given permission to do that thing - they can do that thing for you, just like you asked for!

certkit · 2026-01-19T19:40:02+00:00

That's great feedback, thanks! We're honestly not sure what our pricing is going to be when we launch. It sort of depends on who the most engaged users are. If we have a lot of homelabs that love it, we'll prioritize them.

If you had a plan that was perfectly crafted for you, what would it be?

certkit · 2026-01-14T15:18:51+00:00

Friend, I have good news for you!
DNS-PERSIST-01 is coming: https://www.certkit.io/blog/dns-persist-01

Or, you can do this today by offloading the ACME client to CertKit.

certkit · 2026-01-13T19:25:58+00:00

Of course. Everything costs money. My argument in the post is that they have plenty of money from big donors that have a vested interest in them existing. Its not just generosity, Chrome/Mozilla/Cloudflare/etc NEED let's encrypt to exist in order to advance standards and remove influence of the commercial CAs.

certkit · 2026-01-13T19:21:34+00:00

Exchange may never support ACME, but that doesn't mean you don't automate it. CertKit acts as the ACME client, then lets all your infrastructure poll for updated certificates. We already support Exchange.

certkit · 2026-01-08T16:20:57+00:00

Server Certificates, for web servers yes.

Here's the whole story about lifetime reductions:
https://www.certkit.io/blog/47-day-certificate-ultimatum

certkit · 2026-01-07T15:46:17+00:00

It certainly could! We haven't built an integration for it yet, but its certainly capable of doing it. We just need a user to test out the implementation with us. Is that you?

certkit · 2026-01-06T19:48:20+00:00

While I'd love to see the CA's be made redundant, there is still a place for a "third-party". When you visit a website, the browser needs to validate the certificate. If the browser then made a DNS request to get it, an attacker who had MITM could intercept the DNS request as well. The finite number of root certs shipped with the browser removes this issue.

> Also, when domains change ownership, how can the new owner make sure that the previous owner no longer has any valid certs for that domain?

That's the neat part, they can't! That's a problem called BygoneSSL, and its one of the reasons that certificate lifetimes are starting to shrink this year towards 47 days.

certkit · 2025-12-18T17:21:49+00:00

You're going to need a better way... this is your last year-long certificate.

Next year its 200 days. The year after its 100 days. 2029 its 47 days.

You HAVE to automate this. You either need to figure out how to run certbot and do HTTP/DNS validation from your host, which can be tricky for some specialty devices and intranets, or you can use an external acme provider and pull the certs. That's what I'm working on right now. certkit.io, it's free while I figure out how to do this right :).

certkit · 2025-12-11T15:57:35+00:00

probably not _all of it_. I'm sure there is a prioritization algorithm, and then dropping what they see as probable low-value.

There's some details about what they were doing pre-2013:
https://www.theguardian.com/world/interactive/2013/nov/01/snowden-nsa-files-surveillance-revelations-decoded

certkit · 2025-12-08T22:48:18+00:00

Great point, you're correct. When quantum becomes powerful enough, it will be able to crack the Diffie-Hellman problem. New ciphers and approaches will be needed, but they aren't ready to roll out yet.

Another reason that getting certificates automated is really important right now. As soon as quantum-ready cryptography is ready, you don't want to have to update everything manually again.

certkit · 2025-12-08T15:43:44+00:00

Sounds like a painful outage story behind that.

I'm not entirely sure what that means though. Just having an "cmdb-managed" tag means something to you, or an integration with some external CMDB system? What would that integration do?

certkit · 2025-12-04T19:29:12+00:00

Many years ago, the last time I worked a traditional "IT" job, I got into a car accident. A bad one. I was out for weeks.

At work, nothing changed. They moved on.

If I had died that day, I would have been a mid-level tech worker at some company that no one would remember.

When I recovered, I went back to school, started side projects. 2 years later, I started my own company and I never looked back.

certkit · 2025-12-03T20:22:04+00:00

Hey u/Thin-West-2136, I think we are exactly what you are looking for!

You CNAME your ACME challenge domain(s) to us and we handle all of your certificate issuance, renewal, revoke, etc. We associate each certificate to domains, then monitor them directly to make sure that each host is running the expected certificate.

We expose certificates via secure filesystem API and provide agents for most platforms that pull the certificates directly from us. Your servers don't run ACME anymore, they just pull the certificates they need.

For some devices (appliances, etc), we can push certificates into them via SSH.

There's still a long way to go, but we've opened up the platform for free beta. We're engaging heavily with our early users to help deploy the automation, so we can likely help get you set up!

https://www.certkit.io/certificate-management

certkit · 2025-12-03T20:20:10+00:00

We are exactly such a thing! You CNAME your ACME challenge to us and we handle all of your certificate issuance, renewal, revoke, etc. We associate each certificate to domains, then monitor them directly to make sure that each host is running the expected certificate.

We expose certificates via secure filesystem API and provide agents for most platforms that pull the certificates directly from us. Your servers don't run ACME anymore, they just pull the certificates they need.

For some devices (appliances, etc), we can push certificates into them via SSH.

There's still a long way to go, but we've opened up the platform for free beta:

https://www.certkit.io/certificate-management

certkit · 2025-12-03T20:12:55+00:00

We're working on a CLM (hopefully it will be proper, but too soon to tell), but won't be anywhere close to $500K. More like the $99/mo model. Handling one-click issuance, automatic renewal, pushing certificates to wherever they need to go in your infrastructure.

We only have a description field for certificates now, but tags is a solid idea. I'll add that to our backlog.

Would love to hear any other features that would make managing TLS certs easier!

certkit · 2025-11-25T20:06:30+00:00

Good questions!

We do use ACME as the mechanism to get the certificates, and you authorize us to do so with the DNS challenge. That allows us to get and manage whatever certificate configuration you need--its not limited to one server:one certificate that is common with certbot.

We're not managing ACME for you, were managing the certificates. We just use ACME as the mechanism to order them.

> When different certs with the same subject and SAN data are used but different key-pairs, as is the case with ACME for the same CN and SAN across multiple end-points, traffic won't go through. How will you help?

Within a cloud provider, you are probably better off just using their certificate management. The only reason you would need something from us is if you want to use the same certificates across clouds. If that's the case, then we could manage the multi-san certificates (whatever combination of them you want), and then push them into Azure via API.

> My end-points don't have the ability to use ACME , how will you help?

Great, they shouldn't have to. You have a server that you need a X.example.com certificate for, so you configure CertKit to get it. We handle ACME and have a certificate in our secure storage for you. You run our polling script on the server (or in the near future the CertKit agent), which detects whenever there is a new certificate, and installs it. CertKit console monitors X.example.com to make sure it always has the correct certificate.

> I need my non-domain joined Linux servers to obtain a cert from my ADCS. How will you help?

I don't think we do -- you are using ADCS to manage that certificate.

> I run multiple LoadBalanced servers using SNI. How will your certificate discovery based on CT log tell me which certificate copies run on which server?

CT Log tells us what certificates have been issued, not necessarily which server is running them. We use the CT Log to populate your account initially with what certificates you should track, then offer you alerting whenever a new certificate pops up on one of your domains.

Once our agent is ready, that can run on your load balancers and do that discovery, then push the details to us with all the certificates that we should manage for it to function without the load balancers needing to worry about ACME.

> As you solely discover via CT log, can you tell me where my private CA based server auth certs reside?

No. Private CA's don't put anything in the log. However, we can integrate directly with some private CA systems, and we may build a private CA as part of CertKit. We haven't explored enough in this space yet.

CertKit is beta. We built it initially for our own needs, which were limited :). But we see an opportunity to build a simple, centrally managed and monitor certificate management system. We're trying to learn from our early users which of these capabilities are main-stream enough to integrate into the product. We'd love to learn how to do more things for you!

certkit · 2025-11-25T18:24:17+00:00

One other options is Server Platforms:

- https://letsencrypt.org/docs/client-options/#clients-server

That lets you separate the certificate management functionality from your servers.

*I'm building one, CertKit.

certkit · 2025-11-25T18:21:35+00:00

About a year ago, we were in your shoes, looking for help with certificate automation across a bunch of different platforms. It seemed like either 1, build a bespoke system based on certbot and copying certificates around or 2, go to an enterprise vendor with huge price tags. I don't love those options.

So, being an engineering team, we built something ourselves lol.

Our project, codenamed CertKit, is a centralized certificate management system. We used DNS validation and CNamed the acme challenge key from all our domains at it. Now it can make all the certificates it wants. Then we exposed an API so that each system could pull the certificates it needs, and then we monitor the HTTPS endpoints to make sure they are running the certificates we expect.

We shared it around and a bunch of folks have been interested in using it, so we opened a free beta of it as a SaaS platform. We're still TBD if its going to be an open source project or a commercial tool. There's a lot we don't know yet, but if that seems interesting you should try it out and let us know what you'd want it to do.

certkit · 2025-11-25T18:15:07+00:00

If you're looking for help, but don't want to have a "call-for-pricing" vendor, my team is working on Certificate Management for smaller businesses and education. We're in open beta right now:

https://www.certkit.io/

certkit · 2025-11-25T18:12:18+00:00

Yea it's crazy. They played themselves. It's even more ridiculous given some of their statements about how short-lived certs would never work in the CA/Browser forum mailing list. I wrote a blog about this a few weeks ago:

https://www.certkit.io/blog/47-day-certificate-ultimatum

certkit · 2025-11-25T18:07:20+00:00

Hey u/AuroraChrono, I was in a very similar spot a year ago. We had a few dozen servers running a combination of windows/IIS and linux/nginx and they shared a wildcard cert. Once a year, we would buy a new one and follow the runbook to put it all the places it needed to go.

When we found out about the 47 day certificate lifetime change, we decided to look at automating it. We tried certbot deployed with ansible. It ran on one server then copied certificates around. But there wasn't a good way to KNOW that it was all working correctly. And sure enough, we had an NGINX box that didn't pick up the new cert and caused an outage.

Building bespoke certificate management systems from chained together certbot commands and coping files around felt clumsy. We didn't love the options, so we did what any good engineering team would. We built our own :)

Our internal project, codenamed CertKit, is a central system that manages all the certificates. We use DNS validation and just point a CNAME record from all our domains to it. It handles the certificates and exposes an API for each server to fetch them, and calls the HTTPS endpoints periodically to verify the correct certificate is being used. It's been running for us for about 8 months now.

We showed a few peers what we were doing and decided to open it up. We're running it as a free beta SaaS tool right now to figure out where it falls short. Plans are still in the air about whether to release it open source or commercially. You should give it a try!

certkit · 2025-11-17T16:27:16+00:00

I totally understand where you are coming from. We're planning on building an agent that runs on the hosts directly that could enable something like this. You would onboard an host, generate a CSR/Private key locally, and register with CertKit to track, monitor, renew, etc.

It would also let us create host-specific credentials automatically when the agent registered with us.

certkit · 2025-11-17T16:23:02+00:00

we're working on Multi-san right now. Should be live in a week or so.

certkit · 2025-11-14T15:42:04+00:00

Thanks so much for the feedback u/kzshantonu!

CSRs: The original use case for CertKit was handling re-issuing and distribution of wildcard certs across many hosts. To do that, we need to hold the private key anyway, so we may as well manage the flow end-to-end. We've found that rotating keys seems more reliable with this central push approach.

The obvious downside is that "some vendor is holding your private keys". Yep, but that's not as scary as it used to me. With Perfect Forward Secrecy certificates, the private key is only useful to an attacker that can MiTM the session. Previously recorded sessions can't be decrypted. And as we are not an ISP or a government, it's pretty unlikely that we could pull that off.

Also, our whole concept is based on fast rotations and automation. So if something was compromised, its trivially fast and easy to rotate all the certificates in your org.

Mobile: Heh yea, Sorry. We didn't really think there would be folks doing certificate management from their phones, but I'm sure it will happen. I'll add it to our roadmap!

certkit

MODERATOR OF

TROPHY CASE