7 ms·

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 ev

• bemused 7y ago
  set up your own dns-server for wildcard certificate validation on all your domains: https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns quite straightforward to set up - works great here for ~50 domains from various registrars
  • ajphdiv 7y ago
    Wow. Why did I not think of this. Thanks for sharing.
  • _nickwhite 7y ago
    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 7y ago
      this dns server only needs to run for 5 minutes every 4 weeks while renewing certs - no open ports otherwise
• b3lvedere 7y ago
  Niel Pang's acme.sh script works perfect for me: https://github.com/acmesh-official/acme.sh https://github.com/acmesh-official/acme.sh
  • nickjj 7y ago
    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.
• igetspam 7y ago
  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.
• throw0101a 7y ago
  > 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://dan.langille.org/2019/02/01/acme-domain-alias-mode/ * https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo... * https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation 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 7y ago
    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.
    • tehlike 7y ago
      Well known registrars wouldhave a maintained code. Sounds fine to me. Someone has to maintain it, but it is amortized over the population
    • zAy0LfpBZLC8mAC 7y ago
      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.
• Aaargh20318 7y ago
  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 7y ago
    Another option for e.g. network devices is to run your own CA, i.e. issue your own root certificate.
  • alwillis 7y ago
    BuyPass uses ACME to issue free certificates that expire in 180 days: https://www.buypass.com/ssl/products/acme https://www.buypass.com/ssl/products/acme
• hannob 7y ago
  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 7y ago
    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 7y ago
    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/#why-a-new-hostname-for-every-session-rather-than-for-every-document 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.
  • peterwwillis 7y ago
    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.
• captncraig 7y ago
  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 7y ago
    Pretty sure he meant the dns provider. If he was talking about the domain registrar he would have said domain registrar.
• YesThatTom2 7y ago
  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 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 7y ago
    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 7y ago
  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 7y ago
    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.
• PretzelFisch 7y ago
  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.