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