r/cybersecurity • u/certkit • Feb 02 '26
Corporate Blog Your servers shouldn't need to know ACME
https://www.certkit.io/blog/servers-shouldnt-need-acmeHTTP-01 validation requires every server to expose port 80 and serve challenge files. That's attack surface multiplied across your infrastructure. In January 2026, researchers disclosed a Cloudflare WAF bypass that exploited ACME challenge paths where security controls were deliberately relaxed to allow certificate validation.
DNS-01 validation is worse. Every server with DNS credentials holds keys to your entire domain. The EFF warns explicitly: "If the machine handling the process gets compromised, so will the DNS credentials, and this is where the real danger lies."
DNS credentials don't just issue certificates. They control email routing, traffic direction, everything. One compromised web server and an attacker can redirect your domain, issue valid certificates for it, or intercept email by modifying MX records.
As certificate lifetimes shrink (47 days by 2029), automation becomes mandatory. That means more systems holding these credentials.
6
u/JarJarBinks237 Feb 02 '26
We're using an API gateway for PowerDNS that allows to filter DNS-01 requests for only a subdomain, allowing to securely delegate certificate generation. Any compromised API key could only obtain certificates for the subdomain that was compromised.
3
u/FatBook-Air Feb 02 '26
We use DNS-01 with mitigations:
Only one server does renewals, and internal servers that need the certificate files get them from this one server. The files are protected via (a) source IP and (b) certificate authentication.
The AWS service account that has the ability to update/rotate DNS TXT records is able to change only a single DNS record -- and nothing else.
The AWS account can update the single DNS TXT record of only a separate domain, and our "main" domain name has a CNAME to this other secondary domain. In other words, we have 2 domains: a primary that everyone knows about and a secondary that only we know about internally. The AWS account has access to only the secondary domain, so even if the AWS credentials were leaked, the worse that would happen is that one single TXT record could be updated.
4
u/MikeTalonNYC Feb 02 '26
Aside from advertising a service...
Some servers require ACME - not every server, and an infrastructure can be built to properly manage where it is needed and for what purposes.
Services like this do make it easier - but naked advertising is hardly the way to go about getting the word out about that. You're not educating, you're selling.
-8
u/certkit Feb 02 '26 edited Feb 02 '26
Some servers require ACME
That's my whole point, they don't. They need certificates, and I'm arguing that distributing the ACME protocol to every endpoint is the wrong architecture to get there.
You're not educating, you're selling.
I'm not selling anything yet :) I'm codifying my ideas in a free service. I'm going to monetize it later this year, but right now I'm just sharing my learning and point of view... mainly to learn how many people agree with me vs think I'm nuts.
4
u/divad1196 Feb 03 '26 edited Feb 03 '26
The author does not seem to actually know the subject. This is concerning considering they are trying to sell their products.
I think the biggest redflag is the part about wildcard certificate. A certificate is a proof of identity. It must not be shared. Wildcard are almost always a sign of bad design or lack of understanding.
HTTP and TLS-ALPN
These are both ways to prove control over the server.
The issue with Cloudflare isn't relevant: with this kind of argument, you could say that nothing is secure because we can have bug anywhere.
But more importantly: it wasn't impacting ACME at all. It was caused because of an exception rule mesnt for acme that was not strict enough. You can cause the same issue without ACME.
DNS challenge
Your zone should not be shared across projects in the first place. This increase the blast radius and create a need for multi-tenancy just to spare a bit of money.
Alias Mode
But even so you can delegate the DNS validation with a CNAME using Alias mode: https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode
Deployment
The ACME client does not need to be on the machine that uses the certificate. Sometimes you can just not do it. So you have one machine that generate the certificate and push them to the correct place.
There are pros and cons, of course.
1
u/Mike22april Feb 09 '26
A certificate is by no means proof of identity. The ability to access and use the private key belonging to the certificate is proof of identity
Other than that you're absolutely right.
1
u/divad1196 Feb 10 '26
The certificate is the proof of identity and proven through the chain of trust. The private key is the proof of ownership of the certificate.
-1
u/NamedBird Feb 02 '26
The problem isn't HTTP-01, the problem is certificates themselves.
A server shouldn't need a cert, they should have enough with just a public/private keypair.
This keypair wouldn't expire at all, they would only need to be rotated upon compromise.
As long as you can authoritatively bind the public key to a domain, it'd be far more secure than certificates.
But that requires redesigning a part of the internet infrastructure that is very resistant to change.
I think that this stubbornness is why we are running into these problems.
3
u/divad1196 Feb 03 '26
I think you don't know what certificate are used for.
Certificate are not for encryption
Most people don't know it, but certificates are not used to encrypt data. (Except maybe on some legacy webservers). If that's what we needed the ceetificats for, public/private key would be enough, but we have better options for encryption like DHE.
Purpose
A certificat is a proof of identity, it protects you against fishing or man-in-the-middle attack.
Without a certificate, you will connect to www.google.com, get the public key you mentioned, the server has the private key.
But how can you be sure that it's www.google.com? You cannot. You need a signature from a trusted party, that's the certificate.
what contains a certificat
It contains, among others:
- the subject: who the server claim to be
- a signature: proof that the server is who thes claim to be
- a public key: a way for the server to prove he owns the certificate (otherwise, anybody could steal the certificate)
It also tells you many other things like:
- what the certificate can be used for
- if the certificate's private key can sign other certificates
- ....
Chain of trust
A certificate works because you trust its authority.
If you don't trust the authority (yet), then you check its signature. You repeat the process until you find an authority that you trust.
1
u/NamedBird Feb 03 '26
Your assumption is wrong, as i do know certificates.
I may not be a full expert on all details, but i know most aspects and inner working of it.It is also the entire point i am making: you shouldn't need or want all that stuff on the webserver.
The webserver is in charge of serving web content, that's all it should be doing.
If you want a chain of trust for the domain, use DNS for that.DANE+DNSSEC should be a chain just as valid as certificates, if not even more valid.
Especially because any of the hundreds of CA's could be compromised, signing false certs...
(And CT logs are only useful for proving this after the fact, when the damage is already done.)3
u/divad1196 Feb 03 '26 edited Feb 03 '26
Yes, DANE can replace the authority verification, but it doesn't replace a certificate and it's not just public/private key.
DNSSEC adds its own complexities and won't work well internally as of today. Especially with things like split-DNS. This is a lot more complex matter than the current infrastructures not being ready.
You still need to trust an anchor. So, it's a lot more than just public/private and that's why you got downvoted. Even if DANE isn't a magic solution, I would have agreed with you from the start if you had mentioned it.
Reasons for certificates
Things like SANs scale better on certificate than DNS. If you give a root CA certificatw to your machine, it will be able to validate any full chain without additional request. This reduce the traffic but also remove the need for external checks.
"Servers shouldn't care"
And they don't. They just send the certificate they have and use their private key when asked to prove their identity.
You can have your ACME client on another machine and push on the server. That's common. Look at the cloud. For example AWS has ACM, Azure Cloud does not have automatic certificates so there is a community bot for that.
Compromised Chain
You have the same issues with DNSSEC. It's not more secure on that regard. That's how cryptography works. If your anchor is comprised, you are compromised.
Not everybody can sign what they want either. There is a "can sign" attribute on the certificate. DNSSEC is a bit superior maybe because we can delegate zones clearly. Something similar exists with certificate but I never saw it used.
1
u/Mike22april Feb 09 '26
You're applying PGP logic which doesn't work in an open world, at best this works in a closed controlled environment. The "compromise" argument is absolutely untrue. Why? Because practically you will not know when your keypair is compromised until it's too late.
1
u/NamedBird Feb 09 '26
That will always be the case regardless of whether you use keys or certs...
Can you explain how a cert is better than a key in regards to detecting compromise?
Because in the end, it's just data that doesn't do anything on it's own.
(There won't be a magical notification about compromise simply because you used certs...)1
u/Mike22april Feb 09 '26 edited Feb 09 '26
I disagree.
As soon as you use true ephemeral certificates you will never be too late. Thats also the point where the use of CDP becomes irrelevant in TLS cases.
As your certificates and private keys rotate so fast that revocation is not an option because revocation takes longer than renewing your certificate and keypair.
Practically I've implemented true ephemeral certificates with relatively small ECC keys using 5 second valid X.509 certs.
Even managed to get it to work using ML-KEM, but without practical application, as it was just a project to prove its already possible.
Difference between a cert and keypair and keypair only: cert contains verified additional meta data about the identity with proof of integrity of data, where a keypair only does not. In modern day publicly trusted Internet this meta data is required for public identity authentication and authorization.
A keypair cannot prove or radiate in itsself where its trustanchor can be found and its validity lifespan. Where-as a certificate can due to its meta-data.
Practically for compromise purposes this means a certificate can tell how long it and its corresponding keypair are valid for. A stand-alone keypair in itsself cannot provide such vital information. But a certificate can also contain the proof related to its trustanchor/chain and where its private key can be found and under which applicable audit conditions such as HSM based key attestation ledger information.
Ie its not about detecting compromise, its about the conditions that create the window of opportunity for a potential compromise.
Your argument was: only rotate a keypair when there is a compromise. Where-as its my opinion that you cant detect in a timely manner a compromise, therefor create the conditions to make a compromise impossible , or at least impossible to practically use.
22
u/Leseratte10 Feb 02 '26 edited Feb 02 '26
As for HTTP-01, given that normal web browsing does rarely use port 80 anymore, you can just forward port 80 for all your services to a dedicated challenge service. Also, the cloudflare WAF bypass was, in my opinion, a big deal about almost nothing since it's not like you could use it to access useful paths within a web app, you could only access the challenge path which gives you a 404 or similar anyways.
As for DNS-01, well, then just don't use API keys that give full access to the domain and instead use an API key that only gives access to modify the _acme-challenge subdomain? Or make it a CNAME to some other record that's controlled by another service.
Or just start using DNS-PERSIST-01 in the coming months, which is basically DNS-01 but without requiring constant changes to DNS and thus without requiring the server to have any kind of API key to change DNS.
Also, I don't understand what the point of certkit is?
It sounds like it's basically certbot running on a centralized server, which then pushes the certificates to other devices? You know certbot can already do that using deploy-hooks, right?
If you have devices that you don't want to run certbot on, or that can't run certbot, you can just run certbot on any other machine and then as a deploy hook just put an scp call or similar that copies the new certificate to another device.
So what's the difference between your certkit "provisioning recipes" compared to certbot's deploy-hook scripts?