I am doing a research project on ACME and I need some detail on the policy choices made regarding the identifier validation in certificate renewals. It is my understanding that the current ACME standard requires identifier validation for renewal requests. This means that the client has to go through domain validation again, even though they have already proved that they control the domain. Is there a formal statement that explains why such policy is in effect? And would explain why it is required for the client to prove they control the domain, again?
I do understand that intuitively this is more secure. However, I need a more precise statement that points out the security threats that this policy mitigates. Maybe there is a way that we can gain the same security benefits without having to go through authorization again.
The short of it is that just because I control a domain name today, that doesn't mean that I control it tomorrow. I could switch to a different hosting provider (and thus the prior hosting provider shouldn't keep getting certificates for the domain they were hosting on my behalf), or I could sell the domain name to somebody else.
The rules that all publicly-trusted Certificate Authorities have to follow are codified by the CA/Browser Forum, which may be helpful for you to look at if you're trying to understand the core rules. They currently allow for reusing domain authorizations for a longer time (around a year if I remember correctly), but Let's Encrypt currently only allows reuse for 30 days, though they have at least at one point considered shortening it to as little as 7 hours. The general industry trend has been toward shorter certificates and shorter validation times, to minimizes the chances of someone having a certificate that they shouldn't have anymore.
The premise of this question is a little odd to me. "Going through authorization" should be an easy, automated process, that a human wouldn't even notice. And for those few cases where it isn't, then the shorter lifetimes and needing to reauthorize more often can help incentivize those few holdouts to make it automated.
1- With non-ACME renewals, there is still a need to prove ownership of a domain on renewals. Typically non-ACME certificates were sold with a one-year validity period, so this was not encountered as frequently. The CA/B rules linked to above state many different challenge types that have been approved by the industry, LetsEncrypt only implements a small subset through automation.
What @petercooperjr is touching upon here is that a BIG motivation for shortening the validity period is due to deficiencies in Certificate Revocation. Right now this is largely handled by OCSP stapling and Certificate Revocation Lists, but implementation details across parts of the greater ecosystem have led to a sizable window (10 days?) in which a revoked certificate can still appear to be valid within CA/B Forum rules. This has led to browser vendors using proprietary tools and techniques to push revocation information to their clients.
Yes, but in the model that LetsEncrypt and other CAs are moving towards, the authorization validity will be considerably shortened as well. LetsEncrypt already wants to drop it from 30 days to a target of 7 hours (Soliciting feedback on shortening authorization lifetimes to 7 hours) so it remains consistent with the required timeframe for CAA checks.
It's also worth noting that some CAs won't cache validation at all, and if you repeat an order you will be required to validate again. Choosing to caching validations at all is up to the CA.
Devising an alternative domain validation method beyond what's currently available would be more interesting than requiring less validation. Perhaps something like publishing a nominated domain validation API endpoint (which may be on a different domain) via a DNS record, and an associated API design. We've proven that http validation isn't practical for everyone, and DNS validation via TXT record falls down due to DNS providers being unwilling to implement a single standard API for it [and in most cases requiring potentially wide distribution of privileged DNS update credentials].
On this topic, there are actually various other challenges currently being experimented with, other than the three RFC8555 challenges supported by Let's Encrypt. For instance, there's the device-attest-01challenge, a challenge by Google for device attestation. On the topic of dns-01 being difficult, there's yet another working draft by Google to add the dns-account-01challenge. dns-account-01 is essentially a stateless DNS challenge - you provision a TXT record once, but then it can statically remain there even during renewals. With this challenge, you do not need to deploy nonces to DNS, thus avoiding the complication of dynamic API access to DNS during renewals. The dns-account-01 challenge seems to be currently under active testing at Google, but Let's Encrypt doesn't support it, or has announced anything regarding it.
Thanks @Nummer378 for some reason I thought dns-account-01 was just standard DNS validation but specific to a certain acme account (so you didn't get DNS validation clashes when using proxying dns like cloudlfare etc). I'll look into that again.
Actually, you're right, the authorization value still contains a random token/nonce. So you do have to update the TXT record on renewal, I was wrong. I got thrown off by the fact that newer drafts specifically mention the challenge being "static" or "stable", but that's apparently not what they meant.
(The BRs do seem to allow a static DNS challenge though, so it isn't impossible, but I guess the security implications of a fully stateless thing are not that great)
@Nummer378 I've gone off topic but I guess what I'm pondering is a hybrid of DNS and http challenge. E.g. if your DNS can present a public domain verification key and a nominated challenge response API endpoint, and your challenge response API can prove it knows that private key (or is talking to something that does), and is willing to sign a response for each targeted subdomain identifier, it would seem to me to be robust proof.
Admittedly I haven't given it much thought and there's probably a gotcha somewhere, but I can see the usefulness especially in being able to point elsewhere for challenge response completion.
I think that's basically what a CNAME to something like acme-dns gives you, of delegating to a specific system that has a standard API for answering challenges. It just stays in the DNS protocol rather than mixing DNS and HTTP. And if you do want to mix in HTTP, just have your web server give a redirect response for .well-known/acme-challenge to the centralized challenge response endpoint you're envisioning.
I think you're trying to come up with a solution for people who have control over DNS (at least during setup), and have control to deploy a separate specialized HTTP API endpoint, but somehow don't have permissions to deploy any software to the web server to answer challenges (even during setup to configure a redirect for .well-known/acme-challenge). And while I'm sure the number of sysadmins in that boat isn't zero, it seems pretty specific for wanting to create new challenge types compared to the existing ways one can delegate responses to a centralized specialized system.
Ha, I know it all sounds needlessly complex but no you wouldn't need to host the API yourself. I'm not really talking about web servers, I'm talking about hp-printer-67.nyc.intranet.domain which might be 1 out of 20000 - acme-dns still requires either wildcarding your whole subdomain or an _acme-challenge CNAME entry per subdomain. Your CA may or may not be public, but issuance still requires controls. There are things like device-attestation but that's machine identity, not service domain names.
Are you suggesting something like a normal DNS record to delegate what the HTTP-01 server would be?
e.g. the DNS record might be:
TXT _acme-challenge_endpoint = foo.example.com
then, instead of functioning like a DNS-01 CNAME (in which that DNS record points to another DNS record that contains the DNS-01 challenge), that record is parsed and a HTTP-01 challenge is issued against the endpoint (foo.example.com) ?
Or, are you talking about something like that BUT it would function like a CAA record where it applies to all subordinate domains?
Not quite, the challenge type would be a new one, let's say dcv-challenge-api-01 and it would be that your domain allows a particular nominated challenge API to respond on it's behalf, verified by a stated public key. Possibly optionally acme-account specific, because in fantasy challenge type land why not.
The actual challenge response conversation would be between the CA and that API, whatever that standard API ended up being. The API would have to prove it's the genuine delegated service by signing it's responses.
I haven't really thought it through so just I'm musing. The idea was once you'd setup the records to say "this service officially provides challenge responses for our domain/subdomain". Yes it could be CAA related, or SRV etc and vary by subdomain level.
Sorry @navid_12345 I've hijacked the conversation with my ramblings.
[Edit: I have a vested interest in being able to host/build stuff that makes peoples certificate orders/renewal easier, which is my motivation for easier challenge responses.]
I'll echo the apologies for hijacking this thread.
I do like your general idea.
My immediate concern with this iteration of your idea, is that you'd need to both identify the endpoint and a key - which can be difficult within 255 chars.
If you just identify the endpoint, the key could be implied via an account; as in the accounturi param in CAA records.
@jvanasco thanks, worth considering a little more, really though a CA would have be the driver, I'm not sure if there are any commonly implemented challenge types that weren't linked to requirements for someones CA software.
As an aside to my already off-topic topic, Certify The Web is one of the clients that has implemented tkauth-01 (we use it for STIR/SHAKEN certs).
You can be the driver. You just need one CA to back you. Perhaps that will be LetsEncrypt.
At it's core, your notion is to support the proxying of challenges to a third party system, which is already embraced via redirects in HTTP-01 and CNAME in DNS-01. You are suggesting an improvement to this by democratizing it to a proxy service. If you ever need help drafting a doc for proxy-01, let me know.
Apologies for continuing the off-topic conversation
I'm not sure I see the advantages of a system such as the one you're describing -- in particular, the heavy lift of specifying and implementing both the client and server sides of a brand new protocol -- over CA Assisted DCV which has a ballot in front of the cabforum right now. That proposal lets you put a single DNS CNAME record in place and then never have to worry about responding to a challenge ever again.
