Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DNS-Persist-01: A New Model for DNS-Based Challenge Validation

letsencrypt.org

Post reply on HN
Print view View original

21–30 of 164 posts

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#21

Post by csense »

To get a Let's Encrypt wildcard cert, I ended up running my own DNS server with dnsmasq and delegating the _acme-challenge subdomain to it.

Pasting a challenge string once and letting its continued presence prove continued ownership of a domain is a great step forward. But I agree with others that there is absolutely no reason to expose account numbers; it should be a random ID associated with the account in Let's Encrypt's database.

As a workaround, you should probably make a new account for each domain.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#22

Post by Spivak »

micw wrote: post #8

I wonder why they switched from a super-secure-super-complex (in terms of operations) way of doing DNS auth to a super-simple-no-cryptography-involved method that just relies on the account id. Why not using some public/private key auth where the dns contains a public key and the requesting server uses the private key to sign the cert request? This would decouple the authorization from the actual account. It would no…

Because LE keeps a mapping of account ids to emails and public keys. You have to have the private key to the ACME account to issue a cert. The cryptography is still there but the dance is done by certbot behind the scenes.

Prior to this accounts were nearly pointless as proof of control was checked every time so people (rightfully) just threw away the account key LE generated for them. Now if you use PERSIST you have to keep it around and deploy it to servers you want to be able to issue certs.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#23

Post by jsheard »

dextercd wrote: post #18
newsoftheday wrote: post #15

Today I do the following: /usr/bin/letsencrypt renew -n --agree-tos --email me@example.com --keep-until-expiring Will I need to change that? Will I need to manually add custom DNS entries to all my domains? PS To add, compared to dealing with some paid certificate services, LetsEncrypt has been a dream.

This adds a new validation method that people can use if they want. The existing validation methods ( https://letsencrypt.org/docs/challenge-types/ ) aren't going away, so your current setup will keep working.

And to elaborate, the reasons you might want to use a DNS challenge are to acquire wildcard certificates, or to acquire regular certificates on a machine or domain which isn't directly internet-facing. If neither of those apply to you then the regular HTTP/TLS methods are fine.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#24

Post by newsoftheday »

dextercd wrote: post #18
newsoftheday wrote: post #15

Today I do the following: /usr/bin/letsencrypt renew -n --agree-tos --email me@example.com --keep-until-expiring Will I need to change that? Will I need to manually add custom DNS entries to all my domains? PS To add, compared to dealing with some paid certificate services, LetsEncrypt has been a dream.

This adds a new validation method that people can use if they want. The existing validation methods ( https://letsencrypt.org/docs/challenge-types/ ) aren't going away, so your current setup will keep working.

This is good news, not sure I got that from reading the article but even if I had to do it, it wouldn't be the end of the world I guess.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#26

Post by newsoftheday »

jsheard wrote: post #23
dextercd wrote: post #18

Earlier quoted context omitted.

This adds a new validation method that people can use if they want. The existing validation methods ( https://letsencrypt.org/docs/challenge-types/ ) aren't going away, so your current setup will keep working.

And to elaborate, the reasons you might want to use a DNS challenge are to acquire wildcard certificates, or to acquire regular certificates on a machine or domain which isn't directly internet-facing. If neither of those apply to you then the regular HTTP/TLS methods are fine.

OK I was sort of thinking that might be the case but wanted to make sure in case I had to start prepping now, thanks. We use no wildcard domains today, maybe down the road.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#27

Post by agwa »

Ayesh wrote: post #16

I'm surprised the ballot passed, unanimously even! I get that storing the DNS credentials in the certificate renewal pipeline is risky, but many DNS providers have granular API access controls, so it is already possible to limit the surface area in case the keys get leaked. Plus, you can revoke the keys easily. The ACME account credentials are also accessible by the same renewal pipelines that has the DNS API credent…

> It's also not quite clear how to revoke this challenge, and how domain expiration deal with this

CAs can cache the record lookup for no longer than 10 days. After 10 days, they have to check it again. If the record is gone, which would be expected if the domain has expired or been transferred, then the authorization is no longer valid.

(I would have preferred a much shorter limit, like 8 hours, but 10 days is a lot better than the current 398 day limit for the original ACME DNS validation method.)

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#28

Post by Spivak »

csense wrote: post #21

To get a Let's Encrypt wildcard cert, I ended up running my own DNS server with dnsmasq and delegating the _acme-challenge subdomain to it. Pasting a challenge string once and letting its continued presence prove continued ownership of a domain is a great step forward. But I agree with others that there is absolutely no reason to expose account numbers; it should be a random ID associated with the account in Let's En…

You bothered to manage your LE accounts? I only say because when using the other two challenge types with most deployment scenarios you were generating a new account per cert so your account ID was just a string of random numbers.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#29

Post by mcpherrinm »

Ayesh wrote: post #16

I'm surprised the ballot passed, unanimously even! I get that storing the DNS credentials in the certificate renewal pipeline is risky, but many DNS providers have granular API access controls, so it is already possible to limit the surface area in case the keys get leaked. Plus, you can revoke the keys easily. The ACME account credentials are also accessible by the same renewal pipelines that has the DNS API credent…

Yes, you can limit both challenge types and account URIs in CAA records.

To revoke the record, delete it from DNS. Let’s Encrypt queries authoritative nameservers with caches capped at 1 minute. Authorizations that have succeeded will soon be capped at 7 hours, though that’s independent of this challenge.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#30

Post by mcpherrinm »

agwa wrote: post #27
Ayesh wrote: post #16

I'm surprised the ballot passed, unanimously even! I get that storing the DNS credentials in the certificate renewal pipeline is risky, but many DNS providers have granular API access controls, so it is already possible to limit the surface area in case the keys get leaked. Plus, you can revoke the keys easily. The ACME account credentials are also accessible by the same renewal pipelines that has the DNS API credent…

> It's also not quite clear how to revoke this challenge, and how domain expiration deal with this CAs can cache the record lookup for no longer than 10 days. After 10 days, they have to check it again. If the record is gone, which would be expected if the domain has expired or been transferred, then the authorization is no longer valid. (I would have preferred a much shorter limit, like 8 hours, but 10 days is a lot…

We (Let’s Encrypt) also agree 10 days seems too long, so we are migrating to 7 hours, aligning with the restrictions on CAA records.
Post reply on HN