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

41–50 of 164 posts

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

#41

Post by dextercd »

chaz6 wrote: 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.

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

#42

Post by liambigelow »

TrueDuality wrote: post #2

I think this is solving a real operational pain point, definitely one that I've experienced. My biggest hesitation here is the direct exposure of the managing account identity not that I need to protect the accounts key material, I already need to do that. While "usernames" are not generally protected to the same degree as credentials, they do matter and act as an important gate to even know about before a real attac…

CAA records including an accounturi already expose the account identity in the same manner, so I feel like that ship has already sailed somewhat (and I would prefer that the CAA and persist record formats match).

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

#43

Post by jmholla »

There's a missing part here, and that's validating your ACME account ownership.

I think most users depend on automation that creates their accounts, so they never have to deal with it. But now, you need to propagate some credential to validate your account ownership to the ACME provider. I would have liked to see some conversation about that in this announcement.

I'm not familiar with Let's Encrypt's authentication model. If they don't have token creation that can be limited by target domain, but I expect you'll need to create separate accounts for each of your target domains, or else anything with that secret can create a cert for any domain your account controls.

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

#44

Post by mschuster91 »

jmholla wrote: post #43

There's a missing part here, and that's validating your ACME account ownership. I think most users depend on automation that creates their accounts, so they never have to deal with it. But now, you need to propagate some credential to validate your account ownership to the ACME provider. I would have liked to see some conversation about that in this announcement. I'm not familiar with Let's Encrypt's authentication m…

> There's a missing part here, and that's validating your ACME account ownership.

Why? ACME accounts have credentials so that the ACME client can authenticate against the certificate issuer, and ACME providers require the placement of a DNS record or a .well-known HTTP endpoint to verify that the account is authorized to act upon the demands of whoever owns the domain.

If either your ACME credentials leak out or, even worse, someone manages to place DNS records or hijack your .well-known endpoint, you got far bigger problems at hand than someone being able to mis-issue SSL certificates under your domain name.

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

#45

Post by basilikum »

> The timestamp is expressed as UTC seconds since 1970-01-01

That should be TAI, right? Is that really correct or do they actually mean unix timestamps (those shift with leap seconds unlike TAI which is actually just the number of seconds that have passed since 1970001Z)?

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

#46

Post by mschuster91 »

Ayesh wrote: post #20
gsich wrote: post #7

Earlier quoted context omitted.

The account is the same as you create in any acme client. I don't see potential for a reverse lookup.

I think the previous post is talking about a search that will find the sibling domain names that have obtained certificates with the same account ID. That is a strong indication that those domains are in the same certificate renewal pipeline, most likely on the same physical/virtual server.

Run ACME inside a Docker container, one instance (and credentials) for each domain name. Doesn't consume much resources. The real problem is IP addresses anyway, CT logs "thankfully" feed information to every bad actor in real time, which makes data mining trivially easy.

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

#47

Post by cyberax »

tptacek wrote: post #12
cyberax wrote: post #11

Earlier quoted context omitted.

Sure. It's yet another advantage of doing True DANE. But it still requires DNS to be reliable for the certificate issuance to work, there's no way around it. So why not cut out the middleman? (And the answer right now is "legacy compatibility")

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.

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

#48

Post by mscdex »

After having to deal with VM hosts that do GeoIP blocking, which unintentionally blocks Let's Encrypt and others from properly verifying domains via http-01/tls-alpn-01, I settled on a DIY solution that uses CNAME redirects and a custom, minimal DNS server for handling the redirected dns-01 challenges. It's essentially a greatly simplified version of the acme-dns project tailored to my project's needs (and written in node.js instead of Go).

Unfortunately with dns-persist-01 including account information in the DNS record itself, that's a bit of a show stopper for me. If/when account information changes, that means DNS records need changing and getting clients to update their DNS records (for any reason) has long been a pain.

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

#49

Post by cube00 »

bob1029 wrote: 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.

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

#50

Post by wtallis »

basilikum wrote: post #45

> The timestamp is expressed as UTC seconds since 1970-01-01 That should be TAI, right? Is that really correct or do they actually mean unix timestamps (those shift with leap seconds unlike TAI which is actually just the number of seconds that have passed since 1970001Z)?

Do leap seconds even matter here? Doing anything involving DNS or certificates in a way that requires clock synchronization down to the second would seem to be asking for trouble.
Post reply on HN