Please elaborate on security differences as well.
Let’s Encrypt is automated (unlike most CAs), so you can get and install the certificate without significant human intervention, probably in under a minute. Let’s Encrypt is also not-for-profit and doesn’t charge fees for issuing a certificate (unlike most CAs), so you can get the certificates without paying for them.
Our certificates will be Domain Validated (DV) certificates, which some other CAs issue. With DV certificates, we don’t validate the legal or offline identity of the certificate applicant.
We aim to have good security practices on par with and in line with industry standards, and we hope over time to have extra security precautions in terms of validation that many other CAs don’t have today. We will use the CAA protocol to allow domains to request that we not issue certs for them. We also plan to be much more transparent than many existing CAs in terms of publicly disclosing what certificates we’ve issued through systems like Certificate Transparency.
We also have a precaution that other DV CAs generally don’t, where we won’t issue a certificate for a domain name that has an existing cert from another CA unless the applicant can prove that they control the key that’s the subject of the existing cert. So for example, if there were an existing domain like example.com that had an existing and valid cert in use from Example CA, we would not be willing to issue a new cert for example.com unless the applicant could prove that they had the key that was the subject of the cert issued by Example CA.
@schoen what steps do folks have to go through to prove they they had the key for an existing SSL cert ? what would the process be like ? thanks
@eva2000, this is supposed to be automated by the client if you have access to the old cert’s private key as a PEM file. It will calculate a digital signature over a challenge text from the CA, which proves to the CA that the applicant requesting the new cert possesses the ability to make signatures using the old cert’s key.
I’m not sure whether this is also implemented in the manual mode (to avoid giving the LE client direct access to the old private key). In principle it can be, eventually, if users prefer that option.
Thanks @schoen when you mean manual mode that would be something non-standard Nginx or Apache or LiteSpeed type web servers on say CentOS would need to use right ?
Manual mode can be used when people don’t want to run the client software on the same machine that’s responding to the validation, or don’t want to run it as root. It’s also one of two options when the machine responding to the validation isn’t running a supported web server (the other option in that case is standalone mode, which does run as root).
Thanks for the clarification I can see where manual mode will definitely be useful to me
Just curious about how does Let’s Encrypt know if the domain name already has an existing certificate from another CA before issuing the certificate for the domain.
It doesn’t know, the rules don’t prohibit having certificates from more than one CA.
Ooh, I see @schoen implied it does check this. @schoen is that true today? It looks like no. There certainly seem to be some quite famous examples where somebody changed from Cloudflare (so Cloudflare has the private key corresponding to a certificate for that name) to serving their own pages with a Let’s Encrypt certificate.
@tialaramex, the Let’s Encrypt CA does not check if you have an existing certificate from another CA as a factor in issuance today, despite some earlier plans that it would do so.
The way of checking would have been Certificate Transparency logs plus crawl data from sites like https://scans.io/ (which isn’t necessarily complete but finds quite a lot of the certificates that have ever been publicly deployed, at least where you don’t have to use SNI to get the server to serve them).