Are they limitations on who can use Let's Encrypt?

Issuance Policy
1

I haven’t come across anything to suggest that there will be, but will there be limitations on who can use Let’s Encrypt?

Specifically, I’m thinking along the lines of for-profit organizations who are currently paying Tier 1 CAs for their certificates.

1 Like
2

The only limitation is that your use-cases fit in what is being offered: domain-validation certificates, to users who can prove ownership over a domain and a private key, with any number of those domains included in the certificate.

So: No wildcard certs, no OV or EV certs. That’s about it.

2 Likes
3

Commercial users are welcome to use Let’s Encrypt for commercial and for-profit purposes. This is an intended use; we don’t have any desire to restrict the use of our services to non-profit or non-commercial purposes.

3 Likes
4

We’re trying to issue DV certs for some financial institutions and getting push back from cert vendors that these can’t be automated and require a phone call. Will LE make this exception too?

5

It’s worth noting that this is because our primary goal is to protect website users, not necessarily to benefit website operators. If we restricted issuance to non-profit or non-commercial websites, we’d fail to help protect a large number of users who have no control over whether or not websites use TLS, and are typically not well informed about TLS status.

3 Likes
6

@encirca, I’m not aware of any policy that prevents financial institutions from getting DV certs from Let’s Encrypt.

7

This is an excellent question. It is true that certain CAs, like Symantec, will not issue DV certificates to financial institutions. I know that the CA/B Forum Baseline Requirements contains rules related to "high risk certificate requests".

However, I believe that there is nothing preventing automated assessment of so called high-risk certificates.

From the BRs (bold added for emphasis), a definition:

"High Risk Certificate Request: A Request that the CA flags for additional scrutiny by reference to internal
criteria and databases maintained by the CA, which may include names at higher risk for phishing or other fraudulent usage, names contained in previously rejected certificate requests or revoked Certificates, names listed on the Miller Smiles phishing list or the Google Safe Browsing list, or names that the CA identifies using its own risk‐mitigation criteria."

Later, in section 4.2.1, the BRs state:

"The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate’s approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements."

As we can see, these are suitably vague rules. Please note that the term "SHALL" is used as defined in RFC 2119 which establishes the word is synonymous to "MUST".

Let's Encrypt has previously stated they plan to have a few procedures that will would seem to fit the bill of "additional verification activity". They have stated that validation challenges will be performed through multiple network paths to help prevent network impersonation and spoofing (though it seems this may not be ready for launch). They have also described a method called "Proof of Possession" (I believe thats the name anyways...) which will be used when a Let's Encrypt certificate is requested for a domain which already has a certificate through another CA (including Let's Encrypt). This method will require a challenge that will require the signature of the existing certificate's private key.

That being said, EV certificates would still provide additional security which financial institutions should probably take advantage of. The cost of an EV certificate (~$150/year) should not be a problem for them, and the validation should be easy given that they usually have things in order due to other compliance requirements.

Symantec's refusal to offer DVs to financial institutions seems to be a policy they have a adopted which is more strict than the BRs require. This is likely to protect their image and reputation. As far as I know, most CAs dont do this - Comodo for instance does not have this restriction AFAIK.

Let's Encrypt should adopt a list that rejects common phising targets, such as purposeful mispellings of notable brands such as "gmall.com" or "paaypal.com"