- 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)
Issues with this approach, complexity of implementation, throttling (only so many certs per I think week are allowed per ip address)
> 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.
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.
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.
It's being worked on and is probably coming someday, but not here yet. Which makes LE infeasible for some use cases. For now.
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.
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).
For a random online store or something I don't care and I think there is almost no value...
BTW I'm trying to get in touch about ct_advisor but don't see an email listed...
This has been fixed, and I've placed my email address on the site.
For me StartSSL was the best offering, but now I need few 3-rd level domains, so letsencrypt seems the only free choice.
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 want something completely custom and that's hard therefore Lets Encrypt is too hard.
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.
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. Fixing the laptop's date is a non-obvious solution for end users.
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...
Now I face an uphill battle to get things corrected. ARGH.
How does the DNS challenge work with the delay in propagation of new records?
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.
I'll look into lego, thanks.
Not supporting internal domains is understandable, but requiring https for internal things is an issue.
Adding CAs to those is now impossible since Nougat.
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.
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.
The latter seems like a pretty big reach. Oh, the user might see a cert related error so lets just toss out all security.
(i.e. If you have a bunch of stuff web services exposed to the internet on separate IP addresses )
Although they've increased it enough, I'm not sure its still an issue.
What OS are you referring to?
Not buying this excuse.
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.