5 ms·

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

by TekMol 1y ago

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?

matharmin 1y ago
Certificates have a static expiry date by design - it's not "LetsEncrypt expiring the cert". There is no way to avoid expiring a cert if the DNS entry is still there - all you can do is make it easier to renew the cert. That means it must be automated, in which case it doesn't matter if you need to re-create a DNS entry. In my experience, it takes a little effort to set things up the first time, but from then on it just works.
- rjst01 1y ago
  I think the parent commenter would be satisfied if they could authorize their DNS by creating a DNS challenge entry one time, and then continue to renew their certificate as long as that entry still existed. And I'm sympathetic to the concerns that automating this type of thing is hard - many of the simpler DNS tools - which otherwise more than cover the needs for 90% of users - do not support API control or have other compromises with doing so. That said, I do think LE's requirements here are reasonable given how dangerous wildcard certs can be.
  - jeroenhd 1y ago
    > many of the simpler DNS tools -...- do not support API control That's on the DNS provider in my opinion. They can, if they want to, make things easy and automatic for their customers, but they choose not to. There's a whole list of provider-specific plugins (https://eff-certbot.readthedocs.io/en/stable/using.html#dns-plugins https://eff-certbot.readthedocs.io/en/stable/using.html#dns-...) with many more unofficial ones available (https://pypi.org/search/?q=certbot-dns- https://pypi.org/search/?q=certbot-dns-*). Generic ones, like the DirectAdmin one, will work for many web hosts that don't have their own APIs. If you like to stick with whatever domain provider you picked and still want to use Let's Encrypt DNS validation, you can create a CNAME to another domain on a domain provider that does have API control. For instance, you could grab one of those free webhosting domains (rjst01.weirdfreewebhostthatputsadsinyourhtml.biz) with DirectAdmin access, create a TXT record there, and CNAME the real domain to that free web host. Janky, but it'll let you keep using the bespoke, API-less registrar. I imagine you could set up a small DNS service offering this kind of DNS access for a modest fee ($1 per year?) just to host API-controllable CNAME DNS validation records. Then again, most of the time the people picking weird, browser-only domain registrars do so because it allows them to save a buck, so unless it's free the service will probably not see much use.
jeroenhd 1y ago
> 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.
- hn_throw2025 1y ago
  > 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. I took the easier route and let Cloudflare generate and handle certs for my domains. I’m on the free tier. I secure traffic between them and my host with an origin cert. By default those are valid for 15 years. I know CF is frequently criticised around here, but wanted to mention it as an option.
  - jeroenhd 1y ago
    That works too, of course. You don't even need a specific certificate or even an open port by leveraging Cloudflare tunnels, which means you can host your website on a local server behind three layers of NAT if you had to. And it's not just Cloudflare; there are plenty of other redirect-everything-through-a-CDN hosts available. If you don't mind giving Cloudflare control of your website (and barring visitors from countries like India where CGNAT makes everyone fill out CAPTCHAs every page load), this approach will take care of just about everything.
maxnoe 1y ago
Since my DNS provider(IONOS) has an API and there is a plugin for my Webserver (caddy), DNS certificates were completely painless, even for *.<my domain>. The solutions exist, depensa on the providers and your client.
rjst01 1y ago
> 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? An attacker should not gain the ability to persistently issue certificates because they have one-time access to DNS. A non-technical user may not notice that the record has been added. > Also, why not support file based auth in .well-known/acme-challenge/... for domain wide certs? Which attack vector does that prevent? Control over a subdomain (or even control over the root-level domain) does not and should not allow certificate issuance for arbitrary subdomains. Consider the case where the root level domain is hosted with a marketing agency that may not follow security best practices. If their web server is compromised, the attacker should not be able to issue certificates for the secure internal web applications hosted on subdomains.
- TekMol 1y ago
  > An attacker should not gain the ability to > persistently issue certificates because they > have one-time access to DNS. They wouldn't. As soon as the owner of the domain removes the TXT entry that ability would be gone.
  - rjst01 1y ago
    Of course - but that requires the owner to know they were attacked, know the attacker added a TXT verification, potentially overcome fear of deleting it breaking something unexpected, etc.
    - TekMol 1y ago
      If the owner does not find out that someone got control of their DNS server, the attacker can do anything with the domain anyhow. Including issuing certs.
      - rjst01 1y ago
        Yes, but once that access is revoked, that is enough to be certain that the attacker can no longer issue certs. With your proposal, I would then have to audit my TXT records and delete only attacker-created records. (Which in general would be a good practise anyway, because many services do use domain validation processes similar to what you propose)
udev4096 1y ago
We would be better off if people started using DANE. No centralized authority, you control the keys
Mr_Minderbinder 1y ago
> Certificates are still a pain in the butt. One of the most cumbersome aspects of the web. They will likely always be a pain and many aspects of Web security are cumbersome. It is simply a reflection of the fact that the Web, like e-mail, was not designed to be secure in the first place, being used in organisations where you can rely on trust. As a result the security stuff is just bolted on and often only in response to the previous solution failing. The previous layers stick around like zombie flesh until they are unceremoniously deprecated and cut away a decade later. A new system designed from scratch would be less cumbersome.

by TekMol 1y ago

matharmin 1y ago

Certificates have a static expiry date by design - it's not "LetsEncrypt expiring the cert". There is no way to avoid expiring a cert if the DNS entry is still there - all you can do is make it easier to renew the cert. That means it must be automated, in which case it doesn't matter if you need to re-create a DNS entry. In my experience, it takes a little effort to set things up the first time, but from then on it just works.

rjst01 1y ago
I think the parent commenter would be satisfied if they could authorize their DNS by creating a DNS challenge entry one time, and then continue to renew their certificate as long as that entry still existed. And I'm sympathetic to the concerns that automating this type of thing is hard - many of the simpler DNS tools - which otherwise more than cover the needs for 90% of users - do not support API control or have other compromises with doing so. That said, I do think LE's requirements here are reasonable given how dangerous wildcard certs can be.
- jeroenhd 1y ago
  > many of the simpler DNS tools -...- do not support API control That's on the DNS provider in my opinion. They can, if they want to, make things easy and automatic for their customers, but they choose not to. There's a whole list of provider-specific plugins (https://eff-certbot.readthedocs.io/en/stable/using.html#dns-plugins https://eff-certbot.readthedocs.io/en/stable/using.html#dns-...) with many more unofficial ones available (https://pypi.org/search/?q=certbot-dns- https://pypi.org/search/?q=certbot-dns-*). Generic ones, like the DirectAdmin one, will work for many web hosts that don't have their own APIs. If you like to stick with whatever domain provider you picked and still want to use Let's Encrypt DNS validation, you can create a CNAME to another domain on a domain provider that does have API control. For instance, you could grab one of those free webhosting domains (rjst01.weirdfreewebhostthatputsadsinyourhtml.biz) with DirectAdmin access, create a TXT record there, and CNAME the real domain to that free web host. Janky, but it'll let you keep using the bespoke, API-less registrar. I imagine you could set up a small DNS service offering this kind of DNS access for a modest fee ($1 per year?) just to host API-controllable CNAME DNS validation records. Then again, most of the time the people picking weird, browser-only domain registrars do so because it allows them to save a buck, so unless it's free the service will probably not see much use.

jeroenhd 1y ago

> 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.

hn_throw2025 1y ago
> 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. I took the easier route and let Cloudflare generate and handle certs for my domains. I’m on the free tier. I secure traffic between them and my host with an origin cert. By default those are valid for 15 years. I know CF is frequently criticised around here, but wanted to mention it as an option.
- jeroenhd 1y ago
  That works too, of course. You don't even need a specific certificate or even an open port by leveraging Cloudflare tunnels, which means you can host your website on a local server behind three layers of NAT if you had to. And it's not just Cloudflare; there are plenty of other redirect-everything-through-a-CDN hosts available. If you don't mind giving Cloudflare control of your website (and barring visitors from countries like India where CGNAT makes everyone fill out CAPTCHAs every page load), this approach will take care of just about everything.

maxnoe 1y ago

Since my DNS provider(IONOS) has an API and there is a plugin for my Webserver (caddy), DNS certificates were completely painless, even for *.<my domain>. The solutions exist, depensa on the providers and your client.

rjst01 1y ago

> 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? An attacker should not gain the ability to persistently issue certificates because they have one-time access to DNS. A non-technical user may not notice that the record has been added. > Also, why not support file based auth in .well-known/acme-challenge/... for domain wide certs? Which attack vector does that prevent? Control over a subdomain (or even control over the root-level domain) does not and should not allow certificate issuance for arbitrary subdomains. Consider the case where the root level domain is hosted with a marketing agency that may not follow security best practices. If their web server is compromised, the attacker should not be able to issue certificates for the secure internal web applications hosted on subdomains.

TekMol 1y ago
> An attacker should not gain the ability to > persistently issue certificates because they > have one-time access to DNS. They wouldn't. As soon as the owner of the domain removes the TXT entry that ability would be gone.
- rjst01 1y ago
  Of course - but that requires the owner to know they were attacked, know the attacker added a TXT verification, potentially overcome fear of deleting it breaking something unexpected, etc.
  - TekMol 1y ago
    If the owner does not find out that someone got control of their DNS server, the attacker can do anything with the domain anyhow. Including issuing certs.
    - rjst01 1y ago
      Yes, but once that access is revoked, that is enough to be certain that the attacker can no longer issue certs. With your proposal, I would then have to audit my TXT records and delete only attacker-created records. (Which in general would be a good practise anyway, because many services do use domain validation processes similar to what you propose)

udev4096 1y ago

We would be better off if people started using DANE. No centralized authority, you control the keys

Mr_Minderbinder 1y ago

> Certificates are still a pain in the butt. One of the most cumbersome aspects of the web. They will likely always be a pain and many aspects of Web security are cumbersome. It is simply a reflection of the fact that the Web, like e-mail, was not designed to be secure in the first place, being used in organisations where you can rely on trust. As a result the security stuff is just bolted on and often only in response to the previous solution failing. The previous layers stick around like zombie flesh until they are unceremoniously deprecated and cut away a decade later. A new system designed from scratch would be less cumbersome.