Reading through your docs, as I understood it, one will need a new DNS token on every renewal. As you point out perfectly well, storing an API key on the webserver is much too dangerous, especialy since my domain provider also allows tranfers and deletions of domain through it. This means I will have to set up a local DNS server and delegate the challenge there as a zone. Technically possible, but why do you make it so hard? Why not just generate a permanent token from the domain and the user account, that can be set as the TXT record and left unchanged as long as the user wants his domain to have a validated state?
A beginning of explanation: Do DNS Challenge Records have an expiration?
Hi, welcome to the forum! The requirement to have a fresh token on each renewal comes from the Baseline Requirements. It’s there to make sure CAs are verifying an authorization that is “fresh” - that is, that the requester is still actively in control of the domain name. I realize it’s rather complicated and annoying - sorry about that!
No, it is not mandated by the Baseline Requirements. See this post for a description of how the Amazon CA does without it: https://cabforum.org/pipermail/validation/2019-August/001301.html
It would be great if Let’s Encrypt would support something similar.
Ryan Sleevi is extraordinarily smart and very experienced with all things SSL, but I am not sure whether that post is an completely accurate portrayal of what ACM can and can’t do.
Over time I’ve come to believe that the key to how they pulled off the “hands off” approach is in this statement:
ACM renews each certificate before it expires as long as the certificate is in use and the DNS record is in place.
I take this to mean that they will only automatically perform the renewal if your Amazon CA certificate is deployed to an LB or Cloudfront distribution.
In that case, AWS happens to be both the host and CA for your domain. One could compare it to just pointing your domain at Cloudflare and watching them automatically issue certificates as soon as you add your domain (which is indeed what happens). It’s a much stronger authorizing binding than a singular TXT record like in ACME.
That’s all distinct to Let’s Encrypt, who just hand over certificates to be used externally, and don’t happen to also conveniently terminate all your SSL traffic.
In my own experience, ACM failed to renew one of my Amazon CA certificates when the domain itself was no longer pointing at the AWS resource that employed that certificate.
I don’t know what the entire truth with Amazon CA is since that document is all we have to go on, but I do believe that Amazon CA and Let’s Encrypt is an apples and oranges comparison.
I guess it would be possible to come up with something similar, by testing whether HTTPS for the domain still serves a Let’s Encrypt certificate created for the same ACME account for which the original validation was done (and the DNS record for the original validation still exists). This makes revalidation different (and more complex on Boulder’s side) than the original valiation, though. And I’m not sure whether the “uses a Let’s Encrypt cert right now” re-validation is enough, or whether there need to be a set of certificates issued by Let’s Encrypt for this ACME account which covers the domain for the whole time. In any case, implementing this requires a lot of additional state tracking and complexity on Let’s Encrypt’s side.
ACM DNS validation uses one-time-use
TXT records. The trick is that the user sets a static
CNAME to an Amazon-controlled DNS zone, so that Amazon can change the
TXT record without further work from the user.
Let’s Encrypt could add support for something like that, but I don’t know if they want to.
Also, some people don’t like it.
I don’t know how ACM handles renewal for certificates created using email validation. I’ve always suspected that they use some kind of HTTP or TLS validation under the covers, and that the Baseline Requirements might have been looser back in the day.
“Random Value” and “Request Token” are defined in section 1.6.1.
Edit: For that matter, Amazon could probably use 22.214.171.124.8 IP address validation, if they consider themselves to be the Applicant.
I think I will install some DNS server with a MySQL backend, then delegate all the token subdomains there. I might be able to set this up, but it will be huge problem for people with less technical knowledge. Also it takes time to integrate all these things, introduces potential security problems and is a pain in the ass.
I came to Let’s Encrypt out of necessity, but I think it is dangerous to the internet at large, that this CA even exists, because of that necessity. The internet has always been a decentralized network, but since the evil guys at Google decided that every HTTP connection should be encrypted, even those that transmit just public data, and Let’s Encrypt was founded, this organization is a single point of failure that almost has the kill switch to hundreds of thousands of websites. Encryption is good, but not at the expense of a centralized internet. DANE would have been a way out this, but no major browser supports it today, and I think, I know why: Google and Mozilla want the Monopoly, and they want it here at Let’s Encrypt.
Please stop spreading FUD. There are other CAs offering free certificates. And DANE is also not “the way out”.
Please develop. Because yes, you can find a few other CA offering free certificates. But not always automated (and most of the time limited to 3 month, which is low when it’s not automated), or with other limitations, such as “only for nonprofit” or “only for one domain” or “no wildcard”.
And as Let’s Encrypt is under U.S. jurisdiction, it’s means some can’t get a certificate from them. https://github.com/tdelmas/Let-s-Clone/blob/master/WHY.md
If you don’t see the problem with the concentration of Free/Libre CA in U.S. jurisdiction, think about a country you don’t share the same view and try understand how these population must feel.
The apparition of Let’s Encrypt was a good thing. But the current statu-quo is not. There is a need for more CA like that, in a diversity of continent.
Also, could you develop or provide a link with some arguments in that direction?
I’m not spreading FUD, just telling my thoughts on this. Free certificates are great, but are far from an ideal solution for everywhere-encryption. DANE offers a way to give control back to the domain owners and allow them to use whatever certificate they want.
That’s true, but there’s no reason to spread conspiracy theories about evil guys at Google and about Google and Mozilla wanting a monopoly because they don’t support DANE. That’s just BS.
Also, could you develop or provide a link with some arguments in that direction?
DANE only works when you assume that nobody can create fake DNS entries signed with valid DNSsec keys for your domain. Certain state-level actors should be able to (legally) force certain TLDs to provide them with correctly signed entries of their choice. That’s so far the same problem as with classic PKI - but opposed to classic PKI (with Certificate Transparency), there’s no transparent way to find out when this happens.
Yes. But if they can do that, they can get a certificate. The difference is, with a regional tld you can (hopefully) ensure that the laws of your region are respected. If I use, for example, a French tld, it’s not under US jurisdiction.
There is no reason to not require CT with DANE.
(sorry for the off-topic)
in DANE a registry (like Verysign for .com/.net/.org, or government for CCTLD) can silently replace DNSSEC key and records, this will be loged in Certificate transparency in current cert model.
Amazon could be using a number of different validation methods under the hood. But I still think it would be possible without the CA being the host.
Yes, that is how I assume they do it, but I don’t know for sure. I think Let’s Encrypt could do it this way if they want to.
Sure, there are pros and cons with each validation method.
Giving your web server access to modify your DNS has its risks. Maybe you cannot restrict the API key to the validation domain and to TXT records, or maybe you risk misconfiguring that API access, or maybe there is no API. Putting a CNAME to an acme-dns server (https://github.com/joohoi/acme-dns) has its own risks, and hosting this acme-dns server has its own risks too. Putting up a CNAME to a Let’s Encrypt controlled DNS server also has its own risks, which some may consider greater and others may consider lower than the alternatives.
Well, yes, a registry can change domains under their control. That can even happen today and I bet it does in some countries. It can be detected, but of course there’s a weak point everywhere. DNS has a centralization problem itself, but it is still somewhat distributed, scattered across the world, and has some sort of “protection by the masses” on each higher level, e.g, ICANN for example can’t just revoke the key of a TLD because of a single offending subdomain.
We can ban any CA(like wosign/symantec) if it goes rouge, but you just cannot ban .com without destroy 80% of internet as registry don’t publish what records they have. they allow public query of a domain, but it’s only as query form, and don’t allow anyone to get dump of database.
You don’t seem to know how DANE and DNSSEC works. It doesn’t put a registry in the place of a CA, where they can create certificates for any domain. If they go rogue, as you call it, there will be bigger problems than those with DNSSEC. Yes, a registry has control over its own subspace of the DNS. They always had, since they technically own the TLD. This can not be changed by technical measures, as long as you don’t put the DNS on a blockchain. It is a case for regulation and jurisdication.
That you currently
is the bigger problem, because no browser vendor should have the power to decide who is to be trusted.
Who, if not the browser vendors, would decide which CAs the browsers will trust by default?
With DANE? Noone. The domain owner decides what certificates to trust for his servers. CAs are technically obsolete. They may still serve for extended validation. The owner can choose to trust a specific public CA or even his own CA.