When will google decide let's encrypt is not secure enough and start giving a warning around that.
Not to mention that Google has been pushing hard for https on all sites, which is exactly LE's goal.
They're probably the most trustworthy CA on the planet.
If you want to passively monitor encrypted traffic on a massive scale and not get caught (other than via their log - and who is reading that to see if every server they have has been issued a cert unnecessarily, anyway?), LetsEncrypt is awesome. It's plausible to do this without LetsEncrypt, but they made it a lot easier.
As opposed to any other CAs? There are plenty of other CAs that will happily grant a certificate if you prove control of a server that the domain resolves to.
>nothing generated has a password on it, I don't know if I would consider them really trustworthy.
If you have root on the server, can't you just dump the certificate out of memory, even if there's a password on it? short of using a HSM, you need the certificate decrypted so the server can use it.
Passwords provide security for data at rest, a properly hardened server makes it very difficult to dump memory in certain circumstances, and hsm are practically a requirement in some environments.
And finally, say I wanted to use LetsEncrypt, but I wanted to manage the keys myself, and require only private key X could be used to sign Y, and manage it myself. They don't really let me set those requirements at the CA level - it's all on my own host + network security, which IMHO is unnecessarily risky.
CAA records. If you want full control over when issuance happens, you can even set the list of allowed CAs to empty and only change it when you actually want a certificate.
> And finally, say I wanted to use LetsEncrypt, but I wanted to manage the keys myself
If someone can submit a CSR and complete the challenges they get a signed cert, yes, just like with other DV-CAs. LE code (certbot or other clients) doesn't have to touch your private keys, as long as you give them CSRs, as with other CAs.
You absolutely can. Let's Encrypt was one of the first CAs to support CAA (and, IIRC, they supported it when they first launched). CAA is a DNS record that lets you specify which CAs are permitted to issue certificates for your domain.
> And finally, say I wanted to use LetsEncrypt, but I wanted to manage the keys myself, and require only private key X could be used to sign Y, and manage it myself. They don't really let me set those requirements at the CA level - it's all on my own host + network security.
I'm not quite sure what you're saying here. Do you want the ability to issue certificates under your own (constrained) intermediate certificate? That's unfortunately not possible under the current Baseline Requirements unless you get audited as a CA.
If you just want to use your own private key, that's of course possible (in fact, there's no way for Let's Encrypt to generate a key for you). Or is it that you want to limit limit issuance for domain X to key Y? What other CA allows you to do that? And how would you prevent some other CA from issuing a certificate for a different key, even if Let's Encrypt would support such a feature? With that in mind, it becomes clear that in the end it's up to your host and network security again, even with such an agreement in place.
> Do you want the ability to issue certificates under your own (constrained) intermediate certificate?
Look at it this way: currently, if you can send network traffic from some IP space, you can create valid domain certs. This is the equivalent of using a hosts file with a list of IPs to authenticate an ssh connection. Yes, I think an intermediary key, and not simply some arbitrary control of a network, should be required to generate a cert. It seems like CAA, or some extension thereof, could help this become a reality.
There's an CAA extension in the works that will allow you to bind domains to ACME accounts (which are protected by your account key). Let's Encrypt has plans to support it. Is that what you're looking for?
1. Webserver requests cert for xyz.com.
1.1. Generates private key
1.2. Generates csr
1.2. Sends csr to ICA.
2. ICA requests cert for xyz.com.
2.1. ICA generates private key
2.2. Signs Webserver's csr with private key
2.3. Sends signed csr to CA
3. CA issues certificate
3.1. CA looks up CCA record for xyz.com
3.1.1. CCA contains ICA's key fingerprint
3.2. CA verifies signature of Webserver's csr with ICA's key fingerprint
3.3. CA verifies Webserver controls domain xyz.com.
3.4. CA issues cert
This is true for the vast majority of all CAs.
> If you want to passively monitor encrypted traffic on a massive scale and not get caught (other than via their log - and who is reading that to see if every server they have has been issued a cert unnecessarily, anyway?), LetsEncrypt is awesome.
Wouldn't you rather pick a CA that doesn't log all certificates publicly? (At least while that's still possible - i.e. till early next year.) If you're doing this on a massive scale with a CA that logs publicly, there is absolutely no way you're not getting caught.
Certificate Transparency Monitoring is fairly easy to set up, by the way. Even Facebook runs a public monitor you can use.
You can generate and handle the private key entirely yourself, without ever having LE code touch it if you want. You only need to generate CSRs from it.
And you now more than ever have tools to control this if you worry about it: CT logs (that you don't have to check yourself, thanks to free services that alert you about each new certificate for your domain) and CAA records
TPMs generally aren't fast enough to do RSA signatures a on busy webserver though, but they're wonderful for protecting VPN certificates (tools for managing this are built into windows Group Policy, I imagine it's very painful on Linux)
Distrusting Symantec is not an arbitrary action as some people seem to believe.
When they start issuing illegitimate certificates.