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

151–160 of 164 posts

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

#151

Post by plagiat0r »

tialaramex wrote: post #150
plagiat0r wrote: post #139

Earlier quoted context omitted.

X509 certificates published in CT logs are "pre-certificates". They contains a poison extension so you don't be able to use them with your private key. The final certificate (without poison and with SCT proof) is usually not published in any CT logs but you can submit it yourself if you wish.

Although the poisoned pre-certificates† are logged as a necessary part of offering the least hassle product which is the business Let's Encrypt are in, they, like most CAs, also log the finished certificate shortly after. Here's the pre-certificate for this web site's current certificate: https://crt.sh/?id=23696530376 and here, just a few later in the log, is the finished certificate: https://crt.sh/?id=23696528656…

All I'm saying is that publishing final certificate is not required for the process, so just assuming it will be there is premature. User may end up putting precert on his https server and find the hard way.

Happy to see LE publish both, but others do not. Here is an example: https://crt.sh/?id=17293798014

Your won't find final certificate from digicert/globalsign in the CT logs.

Unless the owner publish it himself, API is opened for submission I think for everybody.

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

#152

Post by tialaramex »

plagiat0r wrote: post #151
tialaramex wrote: post #150

Earlier quoted context omitted.

Although the poisoned pre-certificates† are logged as a necessary part of offering the least hassle product which is the business Let's Encrypt are in, they, like most CAs, also log the finished certificate shortly after. Here's the pre-certificate for this web site's current certificate: https://crt.sh/?id=23696530376 and here, just a few later in the log, is the finished certificate: https://crt.sh/?id=23696528656…

All I'm saying is that publishing final certificate is not required for the process, so just assuming it will be there is premature. User may end up putting precert on his https server and find the hard way. Happy to see LE publish both, but others do not. Here is an example: https://crt.sh/?id=17293798014 Your won't find final certificate from digicert/globalsign in the CT logs. Unless the owner publish it himself,…

The comment I made was explicit that this works for Let's Encrypt, you replied that it doesn't, apparently without checking the logs because if you'd glanced at them it's like 1:1 pre-certificates to actual certificates from Let's Encrypt and I explained that you're wrong.

I'm not disputing that there could be a world where you're correct, but, it's not this world, which is why I even made that comment. That doesn't make relying on the logs for this a brilliant idea, it's just an observation that in fact it could work.

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

#153

Post by pests »

plagiat0r wrote: post #140
pests wrote: post #115

Earlier quoted context omitted.

Google, Cloudflare, Let's Encrypt, DigiCert, GlobalSign and others run logs. Here is the list Chrome checks: https://www.gstatic.com/ct/log_list/v3/log_list.json While they do not have direct SLAs, they still have to comply with rules enforced by browser vendors, as they will remove you from CT checks and you'll be marked retired/untrusted (you can find some in the above list). This means a 99% uptime on a 90 day rol…

X509 certificates published in CT logs are "pre-certificates". They contains a poison extension so you don't be able to use them with your private key. The final certificate (without poison and with SCT proof) is usually not published in any CT logs but you can submit it yourself if you wish. OP idea won't work unless OP will submit final certificate himself to CT logs.

I didn't realize this detail, thank you.

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

#154

Post by mcpherrinm »

tialaramex wrote: post #152
plagiat0r wrote: post #151

Earlier quoted context omitted.

All I'm saying is that publishing final certificate is not required for the process, so just assuming it will be there is premature. User may end up putting precert on his https server and find the hard way. Happy to see LE publish both, but others do not. Here is an example: https://crt.sh/?id=17293798014 Your won't find final certificate from digicert/globalsign in the CT logs. Unless the owner publish it himself,…

The comment I made was explicit that this works for Let's Encrypt, you replied that it doesn't, apparently without checking the logs because if you'd glanced at them it's like 1:1 pre-certificates to actual certificates from Let's Encrypt and I explained that you're wrong. I'm not disputing that there could be a world where you're correct, but, it's not this world, which is why I even made that comment. That doesn't…

Note that we only do best-effort submission of final certs, so it's not actually guaranteed that they end up being logged.

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

#155

Post by Hetzner_OL »

amluto wrote: post #134
Hetzner_OL wrote: post #121

Earlier quoted context omitted.

Hi there, Hetzner here. Thanks for mentioning us. For anyone who is interested: - https://www.hetzner.com/dns/ - https://docs.hetzner.com/networking/dns - https://docs.hetzner.cloud/reference/cloud#tag/zones --Katie

Are there docs for how to create and configure the API keys?

Hi there, Please see: https://docs.hetzner.com/cloud/api/getting-started/generatin... --Katie

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

#156

Post by cube00 »

muvlon wrote: post #53
cube00 wrote: post #49

Earlier quoted context omitted.

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.

If you’ve hit a rate limit, we don’t have a way to temporarily reset it. [1]

From your link

move the adjustments to production twice monthly.

I don't know about your use case but I couldn't risk being unable to get a new certificate for at least a fortnight because my container was stuck in a restart loop.

[1]: https://letsencrypt.org/docs/rate-limits/

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

#157

Post by redleader55 »

Ajedi32 wrote: post #136
solatic wrote: post #119

I'm surprised that this doesn't require DNSSEC or at the very least actively encourage configuring DNSSEC. While I used to be fully in the camp that DNSSEC was way more trouble than it was worth, in particular when access was de-facto secured by trusted CA certificates, more and more DNS record types (CAA, CERT, SSHFP, these TXT records) are responsible for storing information that can be manipulated in MITM attacks…

DNS has always been a single-point-of-failure for TLS cert issuance. The threat is real, but not at all unique to this validation method. (For example, an attacker with control of DNS could switch the A record to their server and use that to pass HTTP-01 or TLS-ALPN-01 validation, or update the _acme-challenge TXT record and use that to pass DNS-01.)

While this is true, improvements in the TLS issuance process should also improve security. When the eventual deprecation of TLS-ALPN-01 and DNS-01 comes, this new method would be completely secure.

Here, the record could for example contain a signature from the same key pair used to authenticate the account. The alternative is DNSSEC, but that's avoided by a lot of domains.

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

#158

Post by mcpherrinm »

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)?

It does mean Unix timestamps. The blog post doesn’t have the full details.

You can read the RFC draft at https://datatracker.ietf.org/doc/html/draft-ietf-acme-dns-pe...

It says: CAs MUST properly parse and interpret the integer timestamp value as a UNIX timestamp (the number of seconds since 1970-01-01T00:00:00Z ignoring leap seconds) and apply the expiration correctly.

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

#159

Post by TrueDuality »

liambigelow wrote: post #42
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).

The accounturi is an optional extension. Email, and phone are also optional. This is the first challenge that publicly requires you to specify your account ID publicly. There may be implementations that require it but neither Let's Encrypt or the protocols require them.

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

#160

Post by TrueDuality »

gsich wrote: post #7
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…

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

This is publicly publishing the account ID. There is an optional extension in RFC8659 that extends it but it isn't required by any implementer. This puts that ID into a public well known location that is easy to scrape and will be (this is exactly the kind of opsec info project like Maltego love to go lookup and pull in).
Post reply on HN