[3dfan]

It's still a pain in the ass to manage wildcard certificates with letsencrypt.

Especially when your DNS registrar does not support DNS changes via API.

And even if the registrar supports it, you have to build and maintain the code that talks to the API. Yuck.

I wonder why they don't allow whover controls the domain name to use the domain/.well-known/acme-challenge to create wildcard certs that are valid for all subdomains of that domain.

[throw0101a]

> Especially when your DNS registrar does not support DNS changes via API.

You can point the _acme-challenge record to another domain using a CNAME:

* https://dan.langille.org/2019/02/01/acme-domain-alias-mode/

* https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo...

* https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se...

So if you have example.com at a place which does not have an API, you can point _acme-challenge.example.com via CNAME to _acme-challenge.example.org, which you may have at a place that does.

Or you can point it to a sub-domain, so _acme-challenge.example.com points to _acme-challenge.dnsauth.example.com, and then you have dnsauth.example.com live on a DNS server in your DMZ.

This can be used for internal hosts as well (if you have split-horizon DNS). So if you have websrv1.int.example.com, you can put put _acme-challenge.websrv1.int.example.com as a CNAME that points to _acme-challenge.websrv1.dnsauth.example.com, and dnsauth.example.com live in your DMZ. You do not have to have an A(AAA) record for websrv1 in your external DNS. You'd have to write some glue so that your LE client talks to dnsauth.example.com to add/remove the dns-01 verification records.

[3dfan]

    You can point the _acme-challenge
    record to another domain using a CNAME

Yes. Then you need two domain name servers to serve your domain. And you need to write and maintain code to talk to the API of the second nameserver.

That's what I call a pain in the ass.

[throw0101a]

> Then you need two domain name servers to serve your domain.

Or, as I explained further down, a sub-domain.

> And you need to write and maintain code to talk to the API of the second nameserver.

Which was several dozen lines of shell (used as a hook in our LE client), which we haven't needed to touch since we wrote it a year ago. Hardly a Sisyphean task.

> That's what I call a pain in the ass.

Often less of a pain than dealing with many CAs manually.

[Spivak]

I mean it's a pain but why is this LE's problem? The company hosting your domain doesn't support programmatically updating records so the least-effort path ends up paying someone that does like the $0.20/month to host the records with an easier to use API.

Unless you're using a very obscure DNS hosting service you shouldn't need to write any code. There are already made plug-ins for just about everyone.

[Filligree]

Can you name such a "someone"? I've been searching, but the space seems very spammy.

[Spivak]

I'm gonna focus on certbot since it's the main player in this space but there are other ACME clients that might have better support for other providers.

* Route53. The plug-in is straightforward with the relevant IAM policy to allow a service account to change your records being already written for you. You end up just copying the tokens, and the arn of the zone into the config file and you're off.

* Google CloudDNS. Google's IAM system is a little more complicated if all you want is a DNS hosted zone but once you have a service account with the right permission and the JSON blob in place the plug-in is actually easier to use since it has the ability to programmatically find your zone based on the name instead of copying the arn.

* DNSimple and DigitalOcean. No IAM policy to fiddle with. Just grant an API token from your account, plug it into the config file, and you're done.

* RFC2136. Not super useful unless you're doing on-prem stuff but really nice if you are. The config format for this one is super finnicky and you'll be reading docs to generate the keys but once you have it it's pretty smooth.

[chc]

For another example, Terraform's acme_certificate resource lists 60 DNS services it works with for the DNS challenge.

[throw0101a]

> Can you name such a "someone"?

How about anyone on the list that's supported by the lexicon utility:

> Lexicon provides a way to manipulate DNS records on multiple DNS providers in a standardized way. Lexicon has a CLI but it can also be used as a python library.

* https://github.com/AnalogJ/lexicon

Doing a quick count, they support 60 APIs.

[cpach]

Amazon Route 53 is one example, there are probably other vendors.

[psidebot]

Azure DNS can be scripted from *nix using Azure CLI and from Windows using PowerShell. You can use the certbot verification hooks to run the requisite scripts.

[zAy0LfpBZLC8mAC]

No, you only need an additional name server to serve one name, and it doesn't even have to be particularly reliable or fast or anything for most uses, as long as it's available at some point for a cert renewal before the old cert expires.

So, you can just put that nameserver on any machine that has a static IP address, or even a semi-static address, like, your home router or something.

[Ajedi32]

Additionally, there are pre-built tools designed for exactly this purpose (e.g. acme-dns), so it's not like you even have to write any code to set this up.

[piffey]

More of a pain in the ass then working with a traditional CA's web frontend, generating your signing certificate, waiting for them to call and verify because you want EV, then downloading the bundle from their site and extracting it then putting it into the (hopefully) automation that pushes it out to all of your servers needing the wildcard?

[throw0101a]

> Then you need two domain name servers to serve your domain.

If you are a mega-corp and have multiple country-specific domains that redirect (apple.ca/ -> apple.com/ca/) then having most of your DNS be "static" and your scripts only talk to one 'canonical' (sub-)domain (e.g., dnsauth.apple.com) may be less hassle: instead of dealing with scripting n>1 domains, you only have to deal with n=1.

[tehlike]

Well known registrars wouldhave a maintained code. Sounds fine to me. Someone has to maintain it, but it is amortized over the population

[tzs]

I haven't looked at DNS in depth in a very very long time. My recollection is that it is a pretty simple protocol. Is that still the case?

If it is, I wonder if it would be reasonable to build a small stand-alone DNS server specifically to use with Let's Encrypt for this. You run this on your own server, and it only handles the domains that you need to satisfy Let's Encrypt.

Point the _acme-challenge record there with a CNAME on your "real" DNS server, and whenever you are getting or renewing a Let's Encrypt certificate, bring up the small stand-alone server.

When the certificate issues or is renewed, shut down the small stand-alone server.

Some Googling of the form "simple DNS server $LANG" for various programming languages $LANG turns up a few that could provide nice starting points.

Perl: on meta::cpan there is Net::DNS::Nameserver, meant to provide a local nameserver for testing local client resolvers, but would probably be adaptable.

Python: [1] under 50 lines and using no imports other than "socket". It's very minimal, but shows dealing with the protocol. [2] [3] [4] are all using something called "dnslib". [2] is nearly 150 lines, but it is more complicated than we need. It's even using multithreading. Same for [3]. [4] is much similar, and much smaller (comparable to using Net::DNS::Nameserver in Perl). Another library for simple DNS in Python is pydnserver [5].

PHP: I didn't find anything simple. All I found was much more full featured and many more lines of code than we need.

Go: [6].

Bash: [7]. I'm not sure what disturbs me more. That someone made this, or that I searched for it.

Ruby: [8].

[1] http://code.activestate.com/recipes/491264-mini-fake-dns-ser...

[2] https://gist.github.com/andreif/6069838

[3] https://gist.github.com/pklaus/b5a7876d4d2cf7271873

[4] https://stackoverflow.com/questions/33531551/how-to-create-a...

[5] https://pypi.org/project/pydnserver/

[6] https://gist.github.com/walm/0d67b4fb2d5daf3edd4fad3e13b162c...

[7] https://gist.github.com/CheRuisiBesares/f35f71f028926e65191d...

[8] https://github.com/socketry/rubydns

[hannob]

My personal take on this is that with easy automation wildcard certificates simply shouldn't be used any more.

In the past one reason for wildcards was that it's too annoying to request certs for each subdomains. With automation this reason goes aways.

The other reason is that you can have "secret hostnames". But if your security relies on secret hostnames that's a bad idea to begin with. You still leak the hostnames to the DNS and as long as we don't have ubiquitous DoH+ESNI also to the network.

Wildcard certs on the other hand have certain risks. If you have a vulnerability in the TLS stack on subdomain1.example.org that may compromise the security of subdomain2.example.org if they share the same cert.

[jacobparker]

Wildcards have use cases. An example:

You have a .example-usercontent.com wildcard certificate for domains like user-1234.example-usercontent.com and you have millions of users. A wildcard certificate is appropriate because:

* LetsEncrypt rate limits are a thing

* The domains exist to leverage origin sandboxing in browsers, but are served by the same infrastructure. It's not more secure (but it is more complicated) to have more certificates here.

Generally, the assumption that two subdomains are served by independent infrastructure is often wrong. Think of things like blogger.com/blogspot.com. So the concern about compromising keys doesn't really apply.

[ocdtrekkie]

Sandstorm.io serves each session of each document on a different subdomain, which yes, isn't an all-around "secret hostname" (access control is not managed solely via this strategy, of course), but it defeats a lot of possible dangers or ways to tamper with an app.

https://docs.sandstorm.io/en/latest/administering/wildcard/#...

It would be extremely prohibitive to have to request a certificate for each session of each access to a document, before even discussing the rate limits of Let's Encrypt.

[koffiezet]

I've used wildcards a lot for securing internal servers. Have a public-facing "internal.my.domain", get a wildcard for that, and and handle the "internal.my.domain" internally, so we have valid SSL certificates for internal services, which otherwise is a pain in the ass.

Also, when running something like a kubernetes or openshift cluster, having dynamic ingress/routes is very easy, and offering the ability to your devs to have SSL not only by default but mandatory, with close to zero configuration, is great.

[peterwwillis]

Wildcards can be used to get around problems in managing access to resources in a multi-tenant environment. If you have 10 product teams, and they all serve different products under a single zone, you may need to grant them all access to modify your nameserver as well as be able to create their own certs at will, if they were going to do independent automated certs. But with a wildcard, you simply give them all the same cert and independently configure the nameserver to point the right records at the right ALBs, and now none of them have any access other than to just serve whatever request hits its ALB.

[theptip]

This would be a nice world to live in, but I stand up more domains in a day for review apps than LetsEncrypt will issue in a week. I don’t even have a large engineering org.

It’s 50 certs per week, not very much.

Honestly I’d pay LE happily for a paid tier option; I would love to subsidize this piece of internet infrastructure in return for all the certs I need.

[3r8riacz]

Wildcats certs are also better for simple privacy by not exposing the other alternative names. In addition, you can have only port 443 open.

[b3lvedere]

Niel Pang's acme.sh script works perfect for me: https://github.com/acmesh-official/acme.sh

[nickjj]

This is what I've been using too on new projects from about 6 months ago. It works nicely and it's easy to set up.

[bemused]

set up your own dns-server for wildcard certificate validation on all your domains:

https://github.com/joohoi/acme-dns

quite straightforward to set up - works great here for ~50 domains from various registrars

[ajphdiv]

Wow. Why did I not think of this. Thanks for sharing.

[_nickwhite]

This seems like a good idea... until your self-hosted DNS server starts getting DoS attacked. I've had seemingly innocent servers practically taken off the Internet with UDP/53 floods- very easy for any 12-year-old to execute.

[bemused]

this dns server only needs to run for 5 minutes every 4 weeks while renewing certs - no open ports otherwise

[Aaargh20318]

The most annoying thing about it is the short expiry time.

I'm using a wildcard certificate so my internal services can be accessed without resorting to installing a self-singed CA cert on all my devices. I've set up a script to renew it every month but unfortunately distributing the resulting certificate to all internal services is proving difficult. There is no simple way to update the cert in my managed switches or the IPMI interface on my servers without resorting to custom scripts to upload it via the web interface.

If it was a once-a-year job I could do it manually, but these certificates need to be regularly replaced which makes it a PITA.

[cpach]

Another option for e.g. network devices is to run your own CA, i.e. issue your own root certificate.

[alwillis]

BuyPass uses ACME to issue free certificates that expire in 180 days: https://www.buypass.com/ssl/products/acme

[YesThatTom2]

letsencrypt support for wildcards has improved greatly. Now that DNSControl also manages certs, we use it to manage our wildcard certs... even ones with multiple wildcards. Shameless plug: https://github.com/StackExchange/dnscontrol

That said... every time someone uses a wildcard cert I think it should be considered a bug. It solves a lot of problems, but opens up others. I'd like to reduce our use of them significantly. Now that letencypt lets me create new certs within minutes (seconds?) instead of days in a fully automated manner, it's easier and easier to reduce my need for wildcards certs.

[jabart]

Wildcard certs don't expose your internal host names on the public certificate transparency list. Issue a SSL certificate for a new domain and you immediately get hit with some random requests hoping you left a default open for a split second.

[simonw]

I got this working with Traefik recently, which has code written to work with APIs from a bunch of DNS providers. I had to switch my domain from Google Domains to Digital Ocean to get it to work though (Google Domains is missing an API).

Traefik is a fantastic piece of software.

[BrandoElFollito]

It is.

The docs, however, are terrible. It is because a friend told me that labels in the docker configuration form "groups" where you define everything I finally got it to work (what I mean is that I create a label which covers ho, to match the traffic, what to do with the traffic I matched etc. and all of this relies on one word shared between the different lines).

The community is not very helpful either.

Beside that, once you understand the idea, it works really really well.

[captncraig]

You do not have to use your registrar's dns. You can register wherever you like, and host dns from cloudflare, route53, gcloud or whatever you want.

[byteshock]

Pretty sure he meant the dns provider. If he was talking about the domain registrar he would have said domain registrar.

[igetspam]

I'm using certbot with ansiblw for wildcards and cert-manager+external-dns in EKS. Both work like magic but I'm using route53. Wildcard validation works the same as regular validation, for dns-01. I haven't built or maintained any portion of that code. You may want to take a closer look.

[PretzelFisch]

This is what I was feeling the other week with the last discussion but the core issue is a bad tool. Use a better client side tool that doesn't generate a new hash on every let's encrypt update. When that happens you only touch the domain settings one time.