What follows is a list of 13 claims made in a customer support email from a large hosting and domain name provider. We believe this same list is being sent to many people who interact with this provider’s customer support regarding Let’s Encrypt, so we want to clarify and correct some inaccuracies.
The provider prefaced their list with the following statements:
Here are their claims with our responses.
1. No OV/EV support or possibility (no possibility to issue a certificate with medium or high assurance and user trust level);
This first one is true - we don’t issue OV or EV certificates (because we are focused on automated high volume issuance), but many people don’t want or need them. If you want them there are many options out there.
2. No Windows/IIS support for now (impossible to issue a certificate on IIS/MSX environment);
Not true. There are a number of ACME clients that work on Windows.
3. Insufficient level of domain validation and the absence of brand validation (All publicly trusted CAs are flagging the certificate containing IT, financial and other public words, brands etc for additional security checks, which is not applicable for LE.)
Our domain validation system is generally agreed to be solid if not significantly better than other systems. We’ve done a lot of work on the ACME specification for domain validation and it has been audited both internally and externally many times. There are no known issues.
As for the branding stuff, we don’t validate legal entities. That isn’t part of domain validation.
4. Multiple machines hosting the same name can’t get a separate cert for each machine (in a nutshell, it is not possible to reissue the certificate, makes the server vulnerable for DROWN attack).
This is entirely incorrect. It is possible to get multiple certificates for the same hostname from Let’s Encrypt. And the DROWN attack has nothing to do with certificate issuance. It is purely a matter of server configuration: If you have servers configured to support SSLv2 (which we don’t recommend), you may be vulnerable. See https://drownattack.com/ for more details. Using Let’s Encrypt doesn’t increase your vulnerability to this attack in the slightest.
5. No policy on automated blacklists: once you are blocked by the system (for hosting malware) you cannot get a new cert for some period of time.
Not accurate. Per our position on phishing and malware, we check the Google Safe Browsing list prior to first issuance. If your domain name is incorrectly blocked by that check, you can follow Google’s documented instructions on how to get de-listed. Once your domain is successfully de-listed, Let’s Encrypt can issue for it effective immediately.
6. Cipher suite configuration is still manual (the certificate installation is automated, all other settings are manual).
This has nothing to do with Let’s Encrypt. If you’re administering your own server then cipher suite configuration is more or less manual no matter who your CA is. If a hosting provider is administering the server they can easily automate this.
7. Root access needed to run ACME-script. Indeed, some plugins can be installed on shared servers, still they do require at least sudo-user access. Users with “jailed” access (non-sudo) do not have rights within Linux shell for such operations.
There are clients available that will run without root. Typically root access is required to configure a web server, store keys with appropriate permissions, or to start a new server that can respond on port 443/80. There are mechanisms by which all of these can be performed without root with sysadmin effort.
8. Script is able to overwrite server configs (such practice is considered insecure due to ability of script to upload, execute, write and read system files, which exposes the server and kernel for multiple vulnerabilities).
(I assume this is talking about Certbot, and it seems to contradict the complaint in #6. If you aren’t manually updating your ciphersuites then a client is able to overwrite the config…) This mode of operation is not required to use Certbot, or Let’s Encrypt. Options exist to simply issue a certificate and leave all server configuration to be done by-hand by the system administrator. No ACME client that exists will expose you to additional kernel vulnerabilities.
9. No wildcard support (impossibility of issuance the wildcard certificate that can cover 1 domain and all same-level subdomains).
This is correct, we don’t support wildcards. However, most people do not need them. Let’s Encrypt makes it easy to get multi-domain certs or different certificates for each subdomain.
10. Exposing the private key to third-party (it is considered as insecure practice, as once the private key is compromised, it is relatively easy to strip HTTPS session and sniff data within decrypted channel).
We have never, ever, encouraged or required people to share their private keys. It is absolutely not necessary to share your private keys with us or anyone else.
11. Multiple vulnerabilities of ACME protocol and attacks on it (for example, MitM-attack on integrity check, signature reuse on ACME-connection itself, DNS injections, DNS attacks etc. More info about that can be found in multiple sources, e.g: https://tools.ietf.org/html/draft-ietf-acme-acme-01 ,https://www.agwa.name/blog/post/duplicate_signature_key_selection_attack_in_lets_encrypt ,https://github.com/letsencrypt/acme-spec/issues/131 etc.)
This is uninformed FUD. ACME has been repeatedly audited by third parties and the cryptography community and there are no known vulnerabilities. The attacks linked to are in out-dated and historic versions of the ACME draft. In this case four draft revisions behind the current draft.
12. Impossibility of adding custom or server-specific OIDs (object identifiers) SSL certificates ( as LE PKI is cross-signed, it is not possible to alter it within given restrictions).
It’s very unusual for subscribers to want this, so much so that it’s an odd thing to even bring up. If you’re in this niche then it’s true, you’ll need to use another CA. We don’t offer this.
13. Validity period (for LE certificates - only 90 days, for all trusted certificate provides - up to 39 months).
Longer certificate lifetimes are dangerous. If your private key is compromised you can be impersonated for as long as your certificate is valid. Revocation is ineffective because OCSP is often not checked (e.g. in Chrome) and it fails open by default. Let’s Encrypt makes it easy to renew certificates so you don’t have to use certificates with dangerously long lifetimes.