Hacker News Reader

Comment by jdc0589 | Hacker News Reader

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

View on HN

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)

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)

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.

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-enc... for more.

Which means that you can add at most 20 subdomains a week. Any more than that, and you are SOL.

> 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.

You're right, I glossed over that distinction. My use case is provisioning domain names for servers/containers the moment they come up, and it's not really feasable to batch that.

And if other people have control over the resulting containers in that circumstance a wildcard wouldn't be suitable either, unless it is only used for HTTPS (and the local LAN/VLAN can be trusted) in which case you can put a proxy in front of the containers to handle it to avoid each container needing a copy of the private key.

I can see why limits are in place though, it protects them from abuse by badly written integration code and actions that are less accidental. Perhaps they'll lift the the limits a bit as the service grows and stabilises. Or introduce a cheap-but-not-free service for people requiring something beyond the standard submission rate limits.

OV certificates are literally useless (or, rather, they have zero added value over DV certs) and EV certs are only valuable for the UI that browsers use when they're in use.

> EV certs are only valuable for the UI that browsers use when they're in use

Not exactly, you can pin your CA's EV root cert in your mobile app (or website using HPKP). This allows you to roll your cert at will while presenting a very high bar to an attacker to get a cert that will verify.

Or you pin your own CA root cert and keep the keys off the net.

I feel it's important to point out that no one "needs" an EV certificate.

Of course there is the "increased conversion" argument from which some users find it worthwhile. But groups certain groups have long pushed a myth that certain types of websites "need" EV, which only serves to help their profits.

More than one consultant has argued you won't pass PCI compliance without an EV cert (false).

I feel a lot more comfortable logging on to a bank when they have an EV certificate. So for things like finincial institutions, I think there is a huge value in the extra feeling of trustworthiness.

For a random online store or something I don't care and I think there is almost no value...

Hijacking...

BTW I'm trying to get in touch about ct_advisor but don't see an email listed...

Well it would appear you've identified a valid bug.

This has been fixed, and I've placed my email address on the site.

Thanks. Ideally, I would like to be able to update the email address used. I put the wrong email address in and there's no mechanism for correcting to the desired one.

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.

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

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.

I don't think it's too much to expect people to read a single paragraph before jumping to conclusions.

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/vul...

+1 for lego.

It made things a breeze to configure. I'm now just hoping that ACMESharp will incorporate ACME DNS challenge support soon so that I can automate getting certs for individual machines right on the same box. Imagine: no more complaints of certs when RDPing to machine.

> it might be quite hard to configure it.

I want something completely custom and that's hard therefore Lets Encrypt is too hard.

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

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

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/AAAAAAAADq...

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.

Ah, right, forgot about DNS validation.

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.

Well, all domains are internal names, just in the root space .

Not supporting internal domains is understandable, but requiring https for internal things is an issue.

I'm not sure what your last sentence is referring to. Who or what is requiring https for internal things?

For example, Chrome disables several JS features and APIs on non-https pages.

Oh, I thought you were referring to something on Let's Encrypt's end. For "real" internal names, internal CAs sound like the best option, and would work just fine with what browsers call "powerful features." For anything else, Let's Encrypt would work.

Except, you can't use internal CAs anymore on Android devices.

Adding CAs to those is now impossible since Nougat.

AFAIK that is only relevant for apps. It is still possible to import CAs for browser traffic, for example, and it's still possible to opt-in to trusting custom CAs as an app. So this is only really a problem for non-browser apps that a) need to communicate with internal domains and b) are not within the control of the organization the internal domain belongs to. I'm sure use-cases like that exist, but they ought to be exceedingly rare.

Well, such use cases are internal email via IMAP with STARTSSL, they are browser traffic with default browsers (those don't allow custom CAs either, you'll likely have to compile a custom build yourself), etc.

Basically, if you want to use any app - be it IRCCloud, Slack, Locally-Hosted Google Apps for big businesses as a box, etc locally, with a custom CA, you have to customly modify every single one of those apps, or you have to buy a CA.

That's a great fucking piece of shit.

> Well, such use cases are internal email via IMAP with STARTSSL, they are browser traffic with default browsers (those don't allow custom CAs either, you'll likely have to compile a custom build yourself), etc.

Do you have a source for this? Whether non-standard CAs are accepted is up to the individual apps. Android N still has the ability to install custom root certificates. I haven't seen an announcement regarding, for example, the standard mail client or Chrome for Android.

> Basically, if you want to use any app - be it IRCCloud, Slack, Locally-Hosted Google Apps for big businesses as a box, etc locally, with a custom CA, you have to customly modify every single one of those apps, or you have to buy a CA.

"Buy a CA"? There's no publicly-trusted CA that will issue certificates for internal domains, period. Just stop using internal names for this purpose and you're fine. You can get domains and DNS hosting for a total of $ 0.00, so that's not a valid argument in my book.

> That's a great fucking piece of shit.

That's a security trade-off that's meant to help protect regular users while inconveniencing a small number of organizations that chose to still use internal names while ignoring many warnings that this is not a best practice, and who are now unable to get publicly-trusted certificates for these domains.

When I last looked at the DNS-01 challenge type, I couldn't work out how to make it work with my DNS provider, Gandi.

How does the DNS challenge work with the delay in propagation of new records?

lego seems to have a plugin for Gandi's DNS API[1].

Let's Encrypt always sends DNS queries to the domain's authoritative DNS server and doesn't cache any results, so as soon as your authoritative DNS server has the record, you're good.

[1]: https://github.com/xenolf/lego/tree/master/providers/dns/gan...

Aha! The project that was missing Gandi API support was https://github.com/AnalogJ/lexicon - but it now has support.

I'll look into lego, thanks.

Those aren't reasons to use Lets Encrypt, those are reasons not to use HTTPS. In fact in the former case the growing ease of using Lets Encrypt is a reason to look at it if you are in such a hurry.

The latter seems like a pretty big reach. Oh, the user might see a cert related error so lets just toss out all security.

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/

Although they've increased it enough, I'm not sure its still an issue.

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.

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.

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?

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.

Short term certs are only an issue if you have inadequate tooling.

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.

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.

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.

So write your own tool. There are loads you can fork.

Not buying this excuse.

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.

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).

Reply on news.ycombinator.com