6 ms·

Is it still hard to do wildcard certs with them? That is one of the reasons I don't use let's encrypt.

by founderling 7y ago

throwaway5d097 7y ago
It's easier now with ACME v2 and using DNS for authentication or whatever.
- p4bl0 7y ago
  I can confirm, I recently did it using certbot and it was an easy and smooth process.
josteink 7y ago
It’s easy if you have a DNS provider for which there is a DNS-auth module. This was one of the reasons for me switching to Cloudflare DNS, although many other providers should work too.
- xref 7y ago
  Unfortunately CloudFlare doesn’t provide limited-scope API keys so every server requesting certs needs your global API key which is the keys-to-the-kingdom...so be careful.
  - josteink 7y ago
    I actually have the reverse model: requesting certs is done by its own isolated and dedicated container and scp’d to the server which needs it. Compromising a web-server will thus not compromise my DNS.
    - xref 7y ago
      I like the sound of this idea, happen to have a Dockerfile/scripts for it on GitHub?
      - josteink 7y ago
        Nope. I’m using LXC and have set things up manually. It’s just a basic setup with dehydrated[1], some bash scripts for deployment and cron though. [1] https://github.com/lukas2511/dehydrated https://github.com/lukas2511/dehydrated
  - regecks 7y ago
    You can also CNAME your _acme-challenge record to another zone and perform the updates on the target zone, avoiding overprivileging your webserver. https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns is a server implementation of that, and a number of popular clients support it. Or if you don't want to run acme-dns, some ACME clients support an "alias" mode that essentially does the same thing using generic DNS CNAMEing. Annoyed that Route53 IAM still doesn't let you limit the record label ...
  - dspillett 7y ago
    No need for individual servers, let alone public ones, to have your DNS API key. Have a separate machine that isn't publicly addressable generate the keys and request the certificates, and then push them out to where they need to be. You don't even need to give that box privileged access to the places the certificates need to be, if you arrange things right. Only one box then needs your API key.
    - tialaramex 7y ago
      That separate machine doesn't need the private keys. Depending on your scenario it may well make more sense for the DNS privileged machine not to know the keys, and be given Certificate Signing Requests (CSRs) for the certificates it's to go get from Let's Encrypt. Most good ACME clients will accept a CSR you provide as an alternative to making their own keys or using a private key you generated. A CSR is a signed document like a certificate, but instead of being signed by a CA (Let's Encrypt) to certify something, they're signed by "you" (ie using your private key) to prove you know the key and you want a certificate with these names on it. Under the hood the ACME protocol always uses CSRs, but since tools to make them are often clumsy and nasty clients tend to follow Certbot (the reference client) in defaulting to making their own CSR without you needing to know about it, a client can do this because it knows your private keys. By providing your own CSRs you don't need the box speaking ACME to know your private keys. Let's Encrypt doesn't care if you provide the same CSR repeatedly for renewals, unless your private key is known to them because somebody leaked it, in which case subsequent requests for a certificate will fail, which is what you want since that key is now compromised and you need to replace it. You should rotate keys anyway, but can do so at a pace which is appropriate to your risk factors e.g. once a year is fine for most people, and not dictated by the rate at which Let's Encrypt renewals happen.
      - dspillett 7y ago
        Aye, though I didn't want to complicate the "everything needs my API key" correction with discussion of providing CSRs separately. That and I've not played with doing that myself yet, so while I know it is possible I can't talk about it authoritatively.
watermelon0 7y ago
Hard in what way? Using my favorite client/library (https://go-acme.github.io/lego/ https://go-acme.github.io/lego/) I can generate wildcard cert with: lego \ --email="info@example.com" \ --accept-tos \ --path="./ssl" \ --domains="*.example.com" \ --dns="route53" (AWS credentials need to be available in the environment)
- founderling 7y ago
  So you need to execute 3rd party software on your machine and let it fiddle with your DNS settings? Personally, I would not want to do that.
  - isostatic 7y ago
    Then write your own acme client, it's not a terrible burden -- although I've only personally done it with the normal URL validation method
  - chme 7y ago
    Well, you could use certbot (https://github.com/certbot/certbot https://github.com/certbot/certbot, see https://certbot.eff.org/docs/using.html#dns-plugins https://certbot.eff.org/docs/using.html#dns-plugins), which is from EFF, so not exactly third party, to do that.
  - jlgaddis 7y ago
    Nope, the protocol is well-documented so that anyone who wants to reinvent the wheel can do so.
  - StavrosK 7y ago
    And that's fine. I just let my http server do it automatically.
  - cyphar 7y ago
    They now support wildcards, but in order to verify you are authorised to get a wildcard certificate you need to be able to pass the DNS challenge. Unfortunately there simply isn't another universal, trust-less (and automatable) way of verifying that someone owns a domain -- other than DNS. However, because the DNS check doesn't require writing to the webroot, you could run this on any server you like and then distribute the certificate to your edge nodes (meaning your edge nodes don't need to have access to write to your DNS). Some clients even have scripting hooks which could make this significantly easier. (I assumed the "store my cloudflare API keys on my web host" aspect was your main concern with this method -- not necessarily who wrote the client because there are plenty of other clients.)
zaarn 7y ago
It's not that hard, I've written a fairly short bash script that automatically issues all of the wildcard certs I use with the correct credentials (and switches to normal HTTP verification when a wildcard isn't requested).
cm2187 7y ago
It's not trivial but it's not that hard. In my case I modified AcmeeSharp to handle acmeev2 with a custom script. The problem I found is that you need a DNS provider that not only has an API, but also has a fairly predictable propagation of DNS changes. I noticed through trial & error that contrary to the specs, let's encrypt doesn't wait and retry if it doesn't find the right DNS entries when it validates the DNS authorization request, instead it just fails the whole thing. Which means that you need to be pretty certain the change has propagated before you tell let's encrypt to complete the authorization. In my case I am using OVH, which has two tiers of service, a regular DNS which is fairly predictable, and a "Anycast DNS" offering which I found to be very hard to get let's encrypt to work with. Also a rookie mistake to avoid: “* .domain.com” doesn’t cover “domain.com”. So you kind of need to get two authorizations, one for “* .domain.com” and one for “domain.com” and then get a cerficate that covers both (if that’s your need).
LeonM 7y ago
Is there still a valid use-case for wildcard certificates when using Lets Encrypt? AFAIK wildcards were used for financial reasons and laziness (since the traditional method of acquiring a cert was cumbersome), but with LE none of those arguments make sense. Why not just fetch a different cert for every subdomain you use? It's also better security practice as this allows you to use different key per subdomain and the possibility to revoke bad or unused certs.
- Sahbak 7y ago
  You do have rate limits, so if you need to spin up a lot of subdomains you won't really have a choice
- deadbunny 7y ago
  LE rate limits[1] can be a hassle in large environments. Their solution is SAN certs which are IMHO only mildly better than wildcards. 1. https://letsencrypt.org/docs/rate-limits/ https://letsencrypt.org/docs/rate-limits/
  - LeonM 7y ago
    I did not know about that, thanks for sharing that information!
- TorKlingberg 7y ago
  It's needed if you use a subdomain for each user, like for example Tumblr does.
- isostatic 7y ago
  I have servers that are firewalled off from the wider internet, or indeed not even reachable (rfc1918 ips) I could get around it by hosting split dns, but that’s quite messy Even on those that are reachable I’d have to carve out port 80 and forward it somewhere else to do the cert generation. Another option would be dynamic server names - where the host part contains a lot of information (or no info) https://gafjsisi.slashdot.org https://gafjsisi.slashdot.org I suspect has never been loaded before today. It seems to work from my phone so I assume it’s a wildcard cert
aeorgnoieang 7y ago
From [Rate Limits - Let's Encrypt - Free SSL/TLS Certificates](https://letsencrypt.org/docs/rate-limits/ https://letsencrypt.org/docs/rate-limits/): > If you have a lot of subdomains, you may want to combine them into a single certificate, up to a limit of 100 Names per Certificate. Combined with the above limit, that means you can issue certificates containing up to 5,000 unique subdomains per week.
deleted 7y ago
[deleted]

Is it still hard to do wildcard certs with them? That is one of the reasons I don't use let's encrypt.

throwaway5d097 7y ago

It's easier now with ACME v2 and using DNS for authentication or whatever.

p4bl0 7y ago
I can confirm, I recently did it using certbot and it was an easy and smooth process.

josteink 7y ago

It’s easy if you have a DNS provider for which there is a DNS-auth module. This was one of the reasons for me switching to Cloudflare DNS, although many other providers should work too.

xref 7y ago
Unfortunately CloudFlare doesn’t provide limited-scope API keys so every server requesting certs needs your global API key which is the keys-to-the-kingdom...so be careful.
- josteink 7y ago
  I actually have the reverse model: requesting certs is done by its own isolated and dedicated container and scp’d to the server which needs it. Compromising a web-server will thus not compromise my DNS.
  - xref 7y ago
    I like the sound of this idea, happen to have a Dockerfile/scripts for it on GitHub?
    - josteink 7y ago
      Nope. I’m using LXC and have set things up manually. It’s just a basic setup with dehydrated[1], some bash scripts for deployment and cron though. [1] https://github.com/lukas2511/dehydrated https://github.com/lukas2511/dehydrated
- regecks 7y ago
  You can also CNAME your _acme-challenge record to another zone and perform the updates on the target zone, avoiding overprivileging your webserver. https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns is a server implementation of that, and a number of popular clients support it. Or if you don't want to run acme-dns, some ACME clients support an "alias" mode that essentially does the same thing using generic DNS CNAMEing. Annoyed that Route53 IAM still doesn't let you limit the record label ...
- dspillett 7y ago
  No need for individual servers, let alone public ones, to have your DNS API key. Have a separate machine that isn't publicly addressable generate the keys and request the certificates, and then push them out to where they need to be. You don't even need to give that box privileged access to the places the certificates need to be, if you arrange things right. Only one box then needs your API key.
  - tialaramex 7y ago
    That separate machine doesn't need the private keys. Depending on your scenario it may well make more sense for the DNS privileged machine not to know the keys, and be given Certificate Signing Requests (CSRs) for the certificates it's to go get from Let's Encrypt. Most good ACME clients will accept a CSR you provide as an alternative to making their own keys or using a private key you generated. A CSR is a signed document like a certificate, but instead of being signed by a CA (Let's Encrypt) to certify something, they're signed by "you" (ie using your private key) to prove you know the key and you want a certificate with these names on it. Under the hood the ACME protocol always uses CSRs, but since tools to make them are often clumsy and nasty clients tend to follow Certbot (the reference client) in defaulting to making their own CSR without you needing to know about it, a client can do this because it knows your private keys. By providing your own CSRs you don't need the box speaking ACME to know your private keys. Let's Encrypt doesn't care if you provide the same CSR repeatedly for renewals, unless your private key is known to them because somebody leaked it, in which case subsequent requests for a certificate will fail, which is what you want since that key is now compromised and you need to replace it. You should rotate keys anyway, but can do so at a pace which is appropriate to your risk factors e.g. once a year is fine for most people, and not dictated by the rate at which Let's Encrypt renewals happen.
    - dspillett 7y ago
      Aye, though I didn't want to complicate the "everything needs my API key" correction with discussion of providing CSRs separately. That and I've not played with doing that myself yet, so while I know it is possible I can't talk about it authoritatively.

watermelon0 7y ago

Hard in what way? Using my favorite client/library (https://go-acme.github.io/lego/ https://go-acme.github.io/lego/) I can generate wildcard cert with: lego \ --email="info@example.com" \ --accept-tos \ --path="./ssl" \ --domains="*.example.com" \ --dns="route53" (AWS credentials need to be available in the environment)

founderling 7y ago
So you need to execute 3rd party software on your machine and let it fiddle with your DNS settings? Personally, I would not want to do that.
- isostatic 7y ago
  Then write your own acme client, it's not a terrible burden -- although I've only personally done it with the normal URL validation method
- chme 7y ago
  Well, you could use certbot (https://github.com/certbot/certbot https://github.com/certbot/certbot, see https://certbot.eff.org/docs/using.html#dns-plugins https://certbot.eff.org/docs/using.html#dns-plugins), which is from EFF, so not exactly third party, to do that.
- jlgaddis 7y ago
  Nope, the protocol is well-documented so that anyone who wants to reinvent the wheel can do so.
- StavrosK 7y ago
  And that's fine. I just let my http server do it automatically.
- cyphar 7y ago
  They now support wildcards, but in order to verify you are authorised to get a wildcard certificate you need to be able to pass the DNS challenge. Unfortunately there simply isn't another universal, trust-less (and automatable) way of verifying that someone owns a domain -- other than DNS. However, because the DNS check doesn't require writing to the webroot, you could run this on any server you like and then distribute the certificate to your edge nodes (meaning your edge nodes don't need to have access to write to your DNS). Some clients even have scripting hooks which could make this significantly easier. (I assumed the "store my cloudflare API keys on my web host" aspect was your main concern with this method -- not necessarily who wrote the client because there are plenty of other clients.)

zaarn 7y ago

It's not that hard, I've written a fairly short bash script that automatically issues all of the wildcard certs I use with the correct credentials (and switches to normal HTTP verification when a wildcard isn't requested).

cm2187 7y ago

It's not trivial but it's not that hard. In my case I modified AcmeeSharp to handle acmeev2 with a custom script. The problem I found is that you need a DNS provider that not only has an API, but also has a fairly predictable propagation of DNS changes. I noticed through trial & error that contrary to the specs, let's encrypt doesn't wait and retry if it doesn't find the right DNS entries when it validates the DNS authorization request, instead it just fails the whole thing. Which means that you need to be pretty certain the change has propagated before you tell let's encrypt to complete the authorization. In my case I am using OVH, which has two tiers of service, a regular DNS which is fairly predictable, and a "Anycast DNS" offering which I found to be very hard to get let's encrypt to work with. Also a rookie mistake to avoid: “* .domain.com” doesn’t cover “domain.com”. So you kind of need to get two authorizations, one for “* .domain.com” and one for “domain.com” and then get a cerficate that covers both (if that’s your need).

LeonM 7y ago

Is there still a valid use-case for wildcard certificates when using Lets Encrypt? AFAIK wildcards were used for financial reasons and laziness (since the traditional method of acquiring a cert was cumbersome), but with LE none of those arguments make sense. Why not just fetch a different cert for every subdomain you use? It's also better security practice as this allows you to use different key per subdomain and the possibility to revoke bad or unused certs.

Sahbak 7y ago
You do have rate limits, so if you need to spin up a lot of subdomains you won't really have a choice
deadbunny 7y ago
LE rate limits[1] can be a hassle in large environments. Their solution is SAN certs which are IMHO only mildly better than wildcards. 1. https://letsencrypt.org/docs/rate-limits/ https://letsencrypt.org/docs/rate-limits/
- LeonM 7y ago
  I did not know about that, thanks for sharing that information!
TorKlingberg 7y ago
It's needed if you use a subdomain for each user, like for example Tumblr does.
isostatic 7y ago
I have servers that are firewalled off from the wider internet, or indeed not even reachable (rfc1918 ips) I could get around it by hosting split dns, but that’s quite messy Even on those that are reachable I’d have to carve out port 80 and forward it somewhere else to do the cert generation. Another option would be dynamic server names - where the host part contains a lot of information (or no info) https://gafjsisi.slashdot.org https://gafjsisi.slashdot.org I suspect has never been loaded before today. It seems to work from my phone so I assume it’s a wildcard cert

aeorgnoieang 7y ago

From [Rate Limits - Let's Encrypt - Free SSL/TLS Certificates](https://letsencrypt.org/docs/rate-limits/ https://letsencrypt.org/docs/rate-limits/): > If you have a lot of subdomains, you may want to combine them into a single certificate, up to a limit of 100 Names per Certificate. Combined with the above limit, that means you can issue certificates containing up to 5,000 unique subdomains per week.

deleted 7y ago

[deleted]