Hacker News Reader

Comment by TekMol | Hacker News Reader

Can this one provide wildcard certificates without having to update DNS entries every three months?

That is the one pain point I have with Let's Encrypt.

PS: Yes, you can automate the DNS updates. That is the paintpoint I am talking about. It is one more moving part. One more dependency on a third party. One more thing to set up. One more thing that can break. One more thing that will rot (APIs always change at some point in time).

Many people seem to solve the "automate DNS" by putting their DNS credentials on the server which serves their website. This is the worst thing from a security perspective. Now someone who breaks into your application can take over your DNS, point your domain to wherever they like and get any certificate for it they like. This probably enables them to also overtake your email and then escalate further from there.

View on HN

If you get a 1 year certificate then yeah, but otherwise no. The requirement to re-validate the DNS record comes not from the CA or the use of ACME, but the Baseline Requirements[1] §4.2.1, to prove you are still in control of the domain on a somewhat regular basis to obtain new certificates. Every 3 months is more frequent than is required, but there is still a regular (398 day) DCV requirement.

[1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-...

"Delegated Domains" might interest you [0].

In this mode you manually configure a CNAME record once like "_acme-challenge.important.example => _acme-challenge.lessimportant.example" and then setup your client with DNS API keys for the lessimportant.example domain. You still get valid certs for your important domain without exposing creds for it.

A leaked key would prevent attackers from changing your important DNS records, but they could still generate valid certs for your important domain.

We bought a cheap domain (~$14/y) for this purpose and hooked it up to a DNS provider with a better API than our main provider. It has worked great and gives some peace of mind.

[0]: https://cert-manager.io/docs/configuration/acme/dns01/#deleg...

Neat! Thanks for sharing this.

Even more moving parts you need to set up and maintain.

It introduces a 4th party you depend on. Now you have:

1: The datacenter where your application runs

2: The DNS server

3: Let's Encrypt

4: The "DNS provider with a better API"

use the same provider (but a different account)?

you are unavoidably dependent on 1-3 anyway

The "DNS provider with a better API" can be your own bind9 server on the same machine as certbot, updated with RFC 2136. Completely standard, no changing APIs, no 4th party, no maintenance. I set up a server like this at work and haven't touched it for a year and a half.

bind hasn't exactly had a flawless security history...

(also hope that not touching it means you've automated security updates at least)

What I've done is delegate (NS record) only the subdomain _acme-challenge to a standalone DNS-zone the webserver has write access to. This way it cannot escalate to changing root A/MX.

Me too, but I enabled nsupdate on that zone, while I wanted to keep my first-level domain safe.

Oh that is really smart. Is there a way to build a simple DNS server into a certbot (or other client) plugin? That DNS server doesn't really have to be available outside of the verification time window.

DNS validation has been a thorn in my side for a while. Not only do I use DNS hosts that don't have APIs (like Google Domains), I also don't really want to give every web server access to my entire zone. That seems like a huge attack surface.

I already had Bind on the machine so it was logical to add the zone there and utilize nsupdate : https://gist.github.com/kronthto/893715f12cc0b1cda9fcfdbd8dc...

But what you are suggesting should work just fine aswell - there should be no need for a persistent service. Of course the service would need to run on port 53, so you actually cannot have another nameserver on that machine already, and also require CAP_NET_BIND_SERVICE .

A quick search lead me to this python project that could be an inspiration: https://github.com/pawitp/acme-dns-server

I run this one: https://github.com/joohoi/acme-dns It's super simple and has a REST API for updating records.

> Many people seem to solve the "automate DNS" by putting their DNS credentials on the server which serves their website. This is the worst thing from a security perspective.

Indeed. That's why I have a single machine that I use for running acme. (Maybe people don't realize that you don't have to run the acme client on the same machine where the certificate will ultimately be deployed?) It contains all my keys (ssh keys, acme account keys, API tokens) in an encrypted database and a set of scripts for getting updated certificates and installing them. This machine has no open incoming IP ports, only outgoing SSH and HTTPS connections. It also contains copies of all my source code and deployment scripts. I could in theory tear down my entire production infrastructure and rebuild it with a single command from this machine.

How could you validate wildcards without changing DNS?

And the different value every three months thing is definitely a feature not a bug, because otherwise stale values could lead to mis-issuance.

    How could you validate wildcards
    without changing DNS?

The same way you validate ownership of a subdomain: By putting stuff into the well-known path. Only that you do it for the root domain. I don't know any case where someone has control over the root domain but is not eligible for a wildcard cert.

> I don't know any case where someone has control over the root domain but is not eligible for a wildcard cert.

Companies very very often point their root domain at a hosting company for their marketing site; let's use Netlify as an example.

This does NOT mean that I would expect Netlify to be able to issue wildcard certs for my domain.

Basic "www-izer" (redirection) services are another example where the root domain is pointed somewhere that should not be able to issue wildcard certs.

To deal with this, a DNS entry "Root Domain Controls Wildcarts" could be required for the validation.

This loose allowance is going away. Current BRs allow using 3.2.2.4.18 and 3.2.2.4.19 (Agreed upon change to Website) for wildcards until December 2021. After that:

> For Certificates issued on or after 2021‐12‐01, the CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names.

Let's Encrypt are just ahead of the curve here, this was always unsafe because it means if your corporate site https://big-corp.example/ is on some bulk host that bulk host can get (even though presumably they wouldn't) wildcard certificates that will also match mail.big-corp.example and db2.big-corp.example and auth.big-corp.example and vpn.big-corp.example ...

Having control over the HTTP response for the root domain but not being authorized to have SSL certificates over subdomains is already a veriry dubious concern, but if you are that worried you could define a fixed DNS record saying that for this particular domain ownership verification of the main domain translates to all subdomains.

> Having control over the HTTP response for the root domain but not being authorized to have SSL certificates over subdomains is already a veriry dubious concern

What about marketing/static hosting sites like Netlify/Vercel/etc? I can point my domain there. That does not mean they should be authorized to have wildcard certs over the whole domain.

Hmm, isn't that exactly how they work?

CDNs are a bad example, because they usually deal with DNS as well. They usually want to send different replies in different regions, etc. CloudFlare is the only one I used, but I know you can't set it up before you switch to their name servers.

However say you host your root-name website on GitHub pages or similar. You don't want them to have full DNS control over the rest of your zone (emails, app, etc).

No, they work by being able to issue a cert for the specific domain that is pointed at them.

It does not work by allowing them to issue a wildcard cert for the entire domain.

For example, `nrmitchi.com` is pointed at Netlify. Netlify can obtain a certificate for `nrmitchi.com` (and `www.nrmitchi.com`, which is also pointed at them). It does not allow Netlify to obtain a cert for `*.nrmitchi.com`, nor should it.

Technically today it does allow them to get such a certificate, but they choose not to (and Let's Encrypt has never allowed this because it's unsafe). Ballot SC45 for the Baseline Requirements this year fixed that so that from December they will not be able to get a wildcard certificate based on proving control over the parent domain.

Even if they would the browser CA forum is clamping down on maximum certificate lifetime. While it will be a while before the max allowed lifetime is 3 months for all certs I suspect eventually it will happen.

The main reason being that revocation is a hard problem to solve. For example OCSP creates a single point of failure. And top of that most software doesn't even check it.

Certificates having short lifetimes doesn't have to mean that verification has to happen at the same frequency. And frequent verification doesn't have to mean that dns records need to be updated each time - for example you could have a dns record saying that HTTP-based authentication for the main domain covers all subdomains.

The Ten Blessed Methods (no there currently aren't ten of them, yes I'm going to keep calling them that) do not allow you to just make up rules like "Let's have a DNS record saying it's OK not to verify anything".

Currently methods 3.2.2.4.18 and 3.2.2.4.19 allow you to get a wildcard based on the web site changes, but that's clearly unsafe and is going away from December. Let's Encrypt never allowed it because it would be hypocritical to have people saying "This is unsafe" while also allowing it.

Updating the DNS entries can and should be automated as well. There's different solutions for different DNS setups, but many, including me, do so and don't have to worry every 3 months.

It can, but is quite a bit more complex since most people are not running their own DNS servers - and even if they are, updating records is nowhere near as standardized as dropping files under .well-known.

It depends--some ACME clients have a list of DNS providers they support and take API credentials to automate DNS verification

I use

1. Free Cloudflare DNS 2. Traefik's built-in ACME client

A little off topic, but since most of ACME/Let's encrypt leverages DNS for validation (directly or indirectly to find well known host IP), why can't we just skip all of this nonsense and do validated self signing using DNS via DANE?

You can put certificates (signatures) in DNS so that clients can look up the appropriate record and verify that certificate that the (e.g.) web server is sending matches:

* https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

However, DNS records themselves are not protected by default: they can be fiddled with in transit. So you have to enable DNSSEC to prevent them from being altered.

So yes, there are standards in place to do what you are suggesting. You'll 'just' have to convince people to enable all of this infrastructure and then have TLS clients use it.

Which isn't going to happen; DNSSEC and DANE were introduced in browsers several years ago, and the browser developers withdrew support. These are dead-letter standards.

I have a beta service I set up to issue certs via let's encrypt, which helps you circumvent the requirement to update DNS records yourself: https://certs.bx.tc/faqs

Depends on your domain/dns provider, I use cloudflare so I can add an API key to the config in certbot and the DNS updates are automated then.

Yeah, it’s the same for gandi.net, plug the API key in and you are done.

Great and now your application server has control over your DNS which it otherwise would not need.

You can delegate authentication via a permanent DNS record to another DNS hierarchy and give your certificate software authority to change that for ACME purposes. This fixes both the "My API key is allowed to change anything" problem and the "I can't get an API key for the DNS domains I need certificates for" problem, albeit at the cost of needing that one-time setup to tell ACME where to look in DNS.

To do this you need a CNAME from the _acme_challenge DNS name you're being challenged on, to a DNS name you're going to use for this purpose. It needn't be in the same domain or indeed even the same TLD but of course it does need to be a public DNS name.

Couldn't they just build a DNS responder into the ACME client? That way you can put an NS record delegating _acme_challenge to your application server/web server, so it can reply during validation?

Nobody stops you building an ACME client that does this. However I expect it would mostly accumulate confused bug reports from users who don't know their IP address, or don't even have a public IP address, and certainly can't unblock UDP port 53 on their device.

certbot already has a "stand-alone" authorization mechanism that has all those drawbacks, so doing a similar thing for DNS might not be too terrible...

kro pointed out (in this thread) this plugin that is more or less what I described: https://github.com/pawitp/acme-dns-server

None of what your rant implies is accurate if you follow any kind of security practice.

Reply on news.ycombinator.com