Live data from Hacker News

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

letsencrypt.org

51–60 of 164 posts

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

#51
post #47
post #12

Earlier quoted context omitted.

I mean, the reason not to do DANE is that nobody will DNSSEC-sign, because DNSSEC signing is dangerous.

Come on. It's not dangerous, it's just inconvenient and clumsy. So nobody is really using it.

Ok, it's inconvenient and clumsy in ways that make it easy to shoot oneself in the foot. But that's not dangerous?

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

#52
post #33
post #25

Interesting. Think a lot of the security headaches went away for me when I discovered providers like CF can restrict the scope of tokens to a single domain and lock it to my IP.

Even CF cannot restrict the scope of a token to a single host.

Or a single DNS record.

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

#53
post #49
post #37

I've changed my mind about the short lived cert stuff after seeing what is enabled by IP address certificates with the HTTP-01 verification method. I don't even bother writing the cert to disk anymore. There is a background thread that checks to see if the current instance of the cert is null or older than 24h. The cert selector on aspnetcore just looks at this reference and blocks until its not null. Being able to d…

Pretty risky given the rate limits of Let's Encrypt are non negotiable with no choice but to wait them out.

They are quite literally negotiable: https://isrg.formstack.com/forms/rate_limit_adjustment_reque...

There are also a bunch of rate limit exemptions that automatically apply whenever you "renew" a cert: https://letsencrypt.org/docs/rate-limits/#non-ari-renewals. That means whenever you request a cert and there already is an issued certificate for the same set of identities.

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

#54
post #4

I really like and hate this at the same time. Years ago, I had a really fubar shell script for generating the DNS-01 records on my own (non-cloud) run authoritative nameserver. It "worked," but its reliability was highly questionable. I like this DNS-PERSIST fixes that. But I don't understand why they chose to include the account as a plain-text string in the DNS record. Seems they could have just as easily used a ra…

> they could have just as easily used a randomly generated key

Isn't that pretty much what an accounturi is in the context of ACME? Who goes around manually creating Let's Encrypt accounts and re-using them on every server they manage?

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

#55
This is going to make it way easier to get publicly trusted certs for LAN servers that aren't internet facing.

I'm looking forward to every admin UI out there being able to generate a string you can just paste into a DNS record to instantly get a Let's Encrypt cert.

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

#56
post #38

Is it possible to create an ACME account without requesting a certificate? AFAICT is is not so you cannot use this method unless you have first requested a certificate with some other method. I hope I am wrong!

An account needs to be created before you can request a certificate. Some ACME clients might create the account for you implicitly when you request the first certificate, but in the background it still needs to start by registering an account. `certbot register` followed by `certbot show_account` is how you'd do this with certbot.

Great, thank you!

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

#57

I'm really excited for this. We moved 120+ hand renewed certs to ACME, but still manually validate the domains annually. Many of them are on private/internal load balancers (no HTTP-01 challenge possible), and our DNS host doesn't support automation (no DNS-01 challenges either). While manually renewing the DCV for ~30 domains once a year isn't too bad, when the lifetime of that validity shrinks, ultimately to 9 days…

For the love of god, switch to a DNS provider with an API. Whatever legacy behemoth you’re working with doesn’t justify a gap this wide.

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

#59
post #5

Earlier quoted context omitted.

Those who choose to use DNS-PERSIST-01 should fully commit to automation and create one LetsEncrypt account per FQDN (or at least per loadbalancer), using a UUID as username.

There is no username in ACME besides the account URI, so the UUID you’re suggesting isn’t needed. The account uri themselves just have a number (db primary key). If you’re worried about correlating between domains, then yes just make multiple accounts. There is an email field in ACME account registration but we don’t persist that since we dropped sending expiry emails.

It’s still a valid point IMHO - why not just use the public key directly? It seems like the account URI just adds problems instead of resolving any.

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

#60
post #51
post #47

Earlier quoted context omitted.

Come on. It's not dangerous, it's just inconvenient and clumsy. So nobody is really using it.

Ok, it's inconvenient and clumsy in ways that make it easy to shoot oneself in the foot. But that's not dangerous?

When you shoot yourself in the foot with DNSSEC, you typically end up with a non-working setup.

The biggest problem is that DNS replies are often cached, so fixes for the mistakes can take a while to propagate. With Let's Encrypt you typically can fix stuff right away if something fails.

Post reply on HN