7 ms·

someone play devils advocate and tell me reasons I might not want to use LetsEncrypt? (aside from potential issues from short-lived certs).

by jdc0589 10y ago

antonplus 10y ago
The short-term certs is an issue, but LE does automatic renewals and send expiration notices. However, I also use letsmonitor.org for monitoring/expiration alerts.
- serge2k 10y ago
  Short term certs are only an issue if you have inadequate tooling.
  - vizza 10y ago
    True, but if it fails and you don't know it, that could be a major problem. Monitoring with alert escalation helps me sleep at night.
    - serge2k 10y ago
      That's not a problem specific to lets encrypt, or anything else really. If you don't want to introduce complexity, then your problem is that you don't have tooling in place when you run into a situation where you have to rotate certs.
  - superkuh 10y ago
    Sure. And the tooling only exists pre-made for modern operating systems. If you run anything even a handful of years old there's no support and you have to do it by hand.
    - serge2k 10y ago
      So write your own tool. There are loads you can fork. Not buying this excuse.
  - lorenzhs 10y ago
    Or if you want to use certificate pinning in an app. You'd have to force-upgrade everyone every two to three months. Old versions would just stop working.
    - pfg 10y ago
      Just keep using the same key for renewals, or pin to something other than the end-entity certificate (like Let's Encrypt's intermediate certificate, or IdenTrust's root, plus some backup pins).
ulysses 10y ago
If you need a wildcard cert, or need an EV cert.
vbezhenar 10y ago
Contrary to popular belief, it might be quite hard to configure it. I spent few days trying to make it work, but I didn't succeed yet. Though my requirements might be a bit atypical. I'm not going to run their software which does too much for my taste, therefore I'm using letsencrypt.sh, which I briefly inspected and I feel comfortable to have full control over process. I don't want to perform domain validation using HTTP, I want to use DNS validation, so I have to write an additional software layer to integrate letsencrypt.sh and my DNS provider API (vultr). And that turns out not so easy. For me StartSSL was the best offering, but now I need few 3-rd level domains, so letsencrypt seems the only free choice.
- psadauskas 10y ago
  I was in a similar situation a few months ago, I wanted to update my Route53 DNS and didn't want to trust the magic tool. I wrote my own simple script in Ruby using the letsencrypt gem and the AWS SDK. It might be a good starting place, feel free to fork and modify it for your own DNS provider. https://github.com/paul/letsencrypt-route53 https://github.com/paul/letsencrypt-route53
- stephanheijl 10y ago
  To be completely honest, if you're not using the tool Let's Encrypt is creating with the specific intent of making configuration easier, it sounds like a moot point to state that it "might be quite hard to configure it". I'm not saying that your use case is invalid, but starting your comment off with stating that it is hard to configure might throw people off.
  - icebraining 10y ago
    I don't think it's too much to expect people to read a single paragraph before jumping to conclusions.
- pfg 10y ago
  Take a look at lego, it appears to support Vultr's DNS API[1] (and many others). [1]: https://github.com/xenolf/lego/tree/master/providers/dns/vultr https://github.com/xenolf/lego/tree/master/providers/dns/vul...
drdaeman 10y ago
If you need a certificate that Let's Encrypt can't/won't provide. Some examples: - Wildcard certificates - OV/EV certificates - S/MIME or code signing certificates - Certificates with non-DNS SANs (e.g. id-on-xmppAddr or id-on-dnsSRV for XMPP servers)
- mey 10y ago
  There is a conceptual work around on wildcard certs, which is to provision on demand essentially, since the process is automated and free. Issues with this approach, complexity of implementation, throttling (only so many certs per I think week are allowed per ip address)
  - drdaeman 10y ago
    Yes, I know, I've followed IETF ACME WG mailing list on the subject, as well as ACME GitHub account issue tracker. It's being worked on and is probably coming someday, but not here yet. Which makes LE infeasible for some use cases. For now.
  - tokenizerrr 10y ago
    It's actually worse. The current rate limits are: > The current rate limits are 20 certificate issuances per domain per 7 days, 5 certificates per unique set of FQDNs per 7 days, 500 registrations per IP per 3 hours, 300 pending authorizations per account per week and 100 subject alternative names per certificate. See https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769 https://community.letsencrypt.org/t/rate-limits-for-lets-enc... for more. Which means that you can add at most 20 subdomains a week. Any more than that, and you are SOL.
    - dspillett 10y ago
      > Which means that you can add at most 20 subdomains a week. Any more than that, and you are SOL. Though the use cases for needing 21+ new subdomains in a week are few and far between I expect, and probably all cases where a wildcard cert would be a better choice (which LE doesn't yet support). Note that it is 20 certificates though, not 20 sub-domains, and LE lets you include more then sub-domain per certificate. So if you can group the sub-domains together you can get many more then 20 in the period.
paws 10y ago
HTTPS is a good idea for many (most) scenarios, especially when your traffic goes over uncontrolled/public networks, but depending on where you stand, it may not be necessary for _all_ use cases. For example if the boss gives you an hour to e.g. stand up a internal company-facing blog on a controlled network environment where you don't necessarily have hostile actors in your threat model, configuring HTTPS might not be your first priority. Another counterexample you hopefully won't have to experience: if you have to support end users where their device's date and time may be incorrect, e.g. their laptop battery died and NTP hasn't kicked in yet, on page loads users would see a scary 'certificate not trusted' warning[1]. Fixing the laptop's date is a non-obvious solution for end users. 1: https://support.google.com/chrome/answer/98884?hl=en https://support.google.com/chrome/answer/98884?hl=en
- icebraining 10y ago
  Regarding internal sites, Let's Encrypt requires an external accessible domain, which you might not have (either because you use a local domain, or because it's firewall'ed from the net). On the other hand, the device date is less problematic nowadays, since Chrome recognizes this case and shows a specific message: http://4.bp.blogspot.com/-xOOCv0xLMxo/Vdu_Y8XlHeI/AAAAAAAADqA/JmmcXGVhLbo/s1600/your+clock+is+behind.jpg http://4.bp.blogspot.com/-xOOCv0xLMxo/Vdu_Y8XlHeI/AAAAAAAADq...
  - pfg 10y ago
    Domains don't have to be externally accessible, they just can't be internal names (i.e. "made-up" domain names that you do not actually own), which is true for all public CAs. The DNS-01 challenge type does not require that you open any port, you just need the ability to create TXT records.
    - icebraining 10y ago
      Ah, right, forgot about DNS validation.
    - newman314 10y ago
      Unfortunately, there are still idiots (sorry, I feel strongly about this) that somehow thought it was a good idea to use "internal" names. Now I face an uphill battle to get things corrected. ARGH.
fweespeech 10y ago
Their rate limits + short cert lifetimes makes it relatively easy to hit the limit if you are using it for a substantial number of certs. (i.e. If you have a bunch of stuff web services exposed to the internet on separate IP addresses ) > https://letsencrypt.org/docs/rate-limits/ https://letsencrypt.org/docs/rate-limits/ Although they've increased it enough, I'm not sure its still an issue.
- pfg 10y ago
  Short certificate lifetimes should have no implications on rate limiting, as renewals do not count against the rate limits, so whether you need to renew your certificate every 90 days or every year won't matter.
superkuh 10y ago
The available software to do the automatic 90 day cert renewals don't work on anything but the latest operating systems. Go back a handful of years and they just crap out.
- pfg 10y ago
  Certbot supports Ubuntu 12.04+ (14.04+ for the apache plugin), CentOS/RHEL 6+, and Debian 7+. With the exception of CentOS/RHEL 5 (which was released in 2007!), all releases of those distributions that still receive security updates are supported. What OS are you referring to?

someone play devils advocate and tell me reasons I might not want to use LetsEncrypt? (aside from potential issues from short-lived certs).

by jdc0589 10y ago

someone play devils advocate and tell me reasons I might not want to use LetsEncrypt? (aside from potential issues from short-lived certs).

antonplus 10y ago

The short-term certs is an issue, but LE does automatic renewals and send expiration notices. However, I also use letsmonitor.org for monitoring/expiration alerts.

serge2k 10y ago
Short term certs are only an issue if you have inadequate tooling.
- vizza 10y ago
  True, but if it fails and you don't know it, that could be a major problem. Monitoring with alert escalation helps me sleep at night.
  - serge2k 10y ago
    That's not a problem specific to lets encrypt, or anything else really. If you don't want to introduce complexity, then your problem is that you don't have tooling in place when you run into a situation where you have to rotate certs.
- superkuh 10y ago
  Sure. And the tooling only exists pre-made for modern operating systems. If you run anything even a handful of years old there's no support and you have to do it by hand.
  - serge2k 10y ago
    So write your own tool. There are loads you can fork. Not buying this excuse.
- lorenzhs 10y ago
  Or if you want to use certificate pinning in an app. You'd have to force-upgrade everyone every two to three months. Old versions would just stop working.
  - pfg 10y ago
    Just keep using the same key for renewals, or pin to something other than the end-entity certificate (like Let's Encrypt's intermediate certificate, or IdenTrust's root, plus some backup pins).

ulysses 10y ago

If you need a wildcard cert, or need an EV cert.

vbezhenar 10y ago

Contrary to popular belief, it might be quite hard to configure it. I spent few days trying to make it work, but I didn't succeed yet. Though my requirements might be a bit atypical. I'm not going to run their software which does too much for my taste, therefore I'm using letsencrypt.sh, which I briefly inspected and I feel comfortable to have full control over process. I don't want to perform domain validation using HTTP, I want to use DNS validation, so I have to write an additional software layer to integrate letsencrypt.sh and my DNS provider API (vultr). And that turns out not so easy. For me StartSSL was the best offering, but now I need few 3-rd level domains, so letsencrypt seems the only free choice.

psadauskas 10y ago
I was in a similar situation a few months ago, I wanted to update my Route53 DNS and didn't want to trust the magic tool. I wrote my own simple script in Ruby using the letsencrypt gem and the AWS SDK. It might be a good starting place, feel free to fork and modify it for your own DNS provider. https://github.com/paul/letsencrypt-route53 https://github.com/paul/letsencrypt-route53
stephanheijl 10y ago
To be completely honest, if you're not using the tool Let's Encrypt is creating with the specific intent of making configuration easier, it sounds like a moot point to state that it "might be quite hard to configure it". I'm not saying that your use case is invalid, but starting your comment off with stating that it is hard to configure might throw people off.
- icebraining 10y ago
  I don't think it's too much to expect people to read a single paragraph before jumping to conclusions.
pfg 10y ago
Take a look at lego, it appears to support Vultr's DNS API[1] (and many others). [1]: https://github.com/xenolf/lego/tree/master/providers/dns/vultr https://github.com/xenolf/lego/tree/master/providers/dns/vul...

drdaeman 10y ago

If you need a certificate that Let's Encrypt can't/won't provide. Some examples: - Wildcard certificates - OV/EV certificates - S/MIME or code signing certificates - Certificates with non-DNS SANs (e.g. id-on-xmppAddr or id-on-dnsSRV for XMPP servers)

mey 10y ago
There is a conceptual work around on wildcard certs, which is to provision on demand essentially, since the process is automated and free. Issues with this approach, complexity of implementation, throttling (only so many certs per I think week are allowed per ip address)
- drdaeman 10y ago
  Yes, I know, I've followed IETF ACME WG mailing list on the subject, as well as ACME GitHub account issue tracker. It's being worked on and is probably coming someday, but not here yet. Which makes LE infeasible for some use cases. For now.
- tokenizerrr 10y ago
  It's actually worse. The current rate limits are: > The current rate limits are 20 certificate issuances per domain per 7 days, 5 certificates per unique set of FQDNs per 7 days, 500 registrations per IP per 3 hours, 300 pending authorizations per account per week and 100 subject alternative names per certificate. See https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769 https://community.letsencrypt.org/t/rate-limits-for-lets-enc... for more. Which means that you can add at most 20 subdomains a week. Any more than that, and you are SOL.
  - dspillett 10y ago
    > Which means that you can add at most 20 subdomains a week. Any more than that, and you are SOL. Though the use cases for needing 21+ new subdomains in a week are few and far between I expect, and probably all cases where a wildcard cert would be a better choice (which LE doesn't yet support). Note that it is 20 certificates though, not 20 sub-domains, and LE lets you include more then sub-domain per certificate. So if you can group the sub-domains together you can get many more then 20 in the period.

paws 10y ago

HTTPS is a good idea for many (most) scenarios, especially when your traffic goes over uncontrolled/public networks, but depending on where you stand, it may not be necessary for _all_ use cases. For example if the boss gives you an hour to e.g. stand up a internal company-facing blog on a controlled network environment where you don't necessarily have hostile actors in your threat model, configuring HTTPS might not be your first priority. Another counterexample you hopefully won't have to experience: if you have to support end users where their device's date and time may be incorrect, e.g. their laptop battery died and NTP hasn't kicked in yet, on page loads users would see a scary 'certificate not trusted' warning[1]. Fixing the laptop's date is a non-obvious solution for end users. 1: https://support.google.com/chrome/answer/98884?hl=en https://support.google.com/chrome/answer/98884?hl=en

icebraining 10y ago
Regarding internal sites, Let's Encrypt requires an external accessible domain, which you might not have (either because you use a local domain, or because it's firewall'ed from the net). On the other hand, the device date is less problematic nowadays, since Chrome recognizes this case and shows a specific message: http://4.bp.blogspot.com/-xOOCv0xLMxo/Vdu_Y8XlHeI/AAAAAAAADqA/JmmcXGVhLbo/s1600/your+clock+is+behind.jpg http://4.bp.blogspot.com/-xOOCv0xLMxo/Vdu_Y8XlHeI/AAAAAAAADq...
- pfg 10y ago
  Domains don't have to be externally accessible, they just can't be internal names (i.e. "made-up" domain names that you do not actually own), which is true for all public CAs. The DNS-01 challenge type does not require that you open any port, you just need the ability to create TXT records.
  - icebraining 10y ago
    Ah, right, forgot about DNS validation.
  - newman314 10y ago
    Unfortunately, there are still idiots (sorry, I feel strongly about this) that somehow thought it was a good idea to use "internal" names. Now I face an uphill battle to get things corrected. ARGH.

fweespeech 10y ago

Their rate limits + short cert lifetimes makes it relatively easy to hit the limit if you are using it for a substantial number of certs. (i.e. If you have a bunch of stuff web services exposed to the internet on separate IP addresses ) > https://letsencrypt.org/docs/rate-limits/ https://letsencrypt.org/docs/rate-limits/ Although they've increased it enough, I'm not sure its still an issue.

pfg 10y ago
Short certificate lifetimes should have no implications on rate limiting, as renewals do not count against the rate limits, so whether you need to renew your certificate every 90 days or every year won't matter.

superkuh 10y ago

The available software to do the automatic 90 day cert renewals don't work on anything but the latest operating systems. Go back a handful of years and they just crap out.

pfg 10y ago
Certbot supports Ubuntu 12.04+ (14.04+ for the apache plugin), CentOS/RHEL 6+, and Debian 7+. With the exception of CentOS/RHEL 5 (which was released in 2007!), all releases of those distributions that still receive security updates are supported. What OS are you referring to?