←back to thread

181 points zdw | 1 comments | | HN request time: 0s | source
Show context
TekMol ◴[] No.44420869[source]
Certificates are still a pain in the butt. One of the most cumbersome aspects of the web.

Especially domain wide certs which need DNS auth.

DNS auth would be okish if it was simply tied to a txt entry in the DNS and valid as long as the txt entry is there. Why does LetsEncrypt expire the cert while the acme DNS entry is still there? Which attack vector does this prevent?

Also, why not support file based auth in .well-known/acme-challenge/... for domain wide certs? Which attack vector does that prevent?

replies(6): >>44420913 #>>44421265 #>>44421337 #>>44421359 #>>44421487 #>>44429373 #
jeroenhd ◴[] No.44421265[source]
> Why does LetsEncrypt expire the cert while the acme DNS entry is still there?

That's like saying "why does the government expire my passport/driver's license when I haven't changed my name". That's not how it works; the document is stamped valid for a specific amount of time, and you get a new document with a new expiration time when you renew it.

The certificate from LE will expire automatically 90 days after it was provided, that's why you need to renew it before the 90 days are up.

If you hate setting up automated certificate renewal, you can still get longer-lasting certificates from paid certificate providers. It used to be that you needed to pay a company to generate a certificate for you every year, now you just get the option to have a free one every 90 days.

> Also, why not support file based auth in .well-known/acme-challenge/... for domain wide certs

An ACME challenge file on a web server proves that you control a specific server at a specific domain, so you get a certificate for a specific domain.

A DNS entry proves you control the entire domain, so you (can) get a certificate for the domain.

By uploading a file to tekmol.freewebhost.com, you haven't proven that you control either .freewebhost.com or .tekmol.freewebhost.com. You have just proven that you control tekmol.freewebhost.com.

replies(6): >>44421354 #>>44421633 #>>44421671 #>>44421834 #>>44421863 #>>44422141 #
TekMol ◴[] No.44422141[source]
You now have described the status quo in length. But you have not touched on why it is supposed to make sense. You have not provided attack vectors for the easier alternatives.

    By uploading a file to tekmol.freewebhost.com,
    you haven't proven that you control either
    .freewebhost.com
Who said that putting a file on a subdomain should grant you a cert on the domain? Putting it on domain.com/.well-known/acme-challenge/ should.
replies(1): >>44425752 #
danaris ◴[] No.44425752{3}[source]
They attempted to indicate wildcards there, but HN ate them. That should say "you haven't proven that you control either *.freewebhost.com or *.tekmol.freewebhost.com".

Now, I can definitely see there being a system where the owner of the root domain (eg, freewebhost.com) can set up something in their own .well-known directory that specifies that any subdomains can only declare certs for that specific subdomain, rather than being able to claim a wildcard, and then we can allow certs that sign wildcards in cases where such a limiter is not in place.

In any case, this would only solve the DNS auth hurdle, not the overall expiration hurdle.

replies(1): >>44426631 #
1. TekMol ◴[] No.44426631{4}[source]

    solve the DNS auth hurdle, not the
    overall expiration hurdle
That would already be a big step forward.