Personal Certificate

[xian]

Hi,
Is it possible to use Let's Encrypt certificates for signing documents and/or emails ?

Thanks,

xian

[JuergenAuer]

Hi @xian

@xian

Is it possible to use Let's Encrypt certificates for signing documents and/or emails ?

no. Please read the FAQ:

FAQ - Let's Encrypt

[xian]

Hi,

Thank you for your reply and your trouble.

It would be really nice to be able to have a CA source like letsencrypt.org for Personal Certificates for signing and encryption of documents, in place of self-signed certificates using opennssl. Right now the only affordable one is Sectigo / Comodo, which you can't download if you don't have Internet Explorer ver 11. Very, very frustrating .

Even if I had to pay a reasonable amount for such a personal key I'd rather deal with letsencrypt.org than Sectigo.

Is it possible that personal keys for signing and encrypting documents in the products development path of letsencrypt.org ?

Best Regards,

Christian Martel, P. Eng. PMP

[griffin]

Welcome to the Let's Encrypt Community, Christian

I see no reason why you couldn't use the private/public key for any application you wish. The only thing a certificate does is provide an authoritative third-party (the CA) who will vouch for the mapping of that private/public key to a domain name. The "abilities"/extensions granted to a certificate by a CA purely mean that the CA will vouch for those "enhancements" if enquired.

[schoen]

@xian

Is it possible that personal keys for signing and encrypting documents in the products development path of letsencrypt.org ?

Hi @xian,

This issue has come up before and it seems very unlikely, because Let's Encrypt's distinctive feature that's allowed it to become the largest CA

Let's Encrypt Stats - Let's Encrypt

while not charging for certificates is complete automation—no human beings are involved in the decision to issue a certificate. This has allowed Let's Encrypt to issue over 2,000,000 certificates every day, because the process can be, and has been, completely automated.

This automation, in turn, is possible because the only thing that Let's Encrypt is attesting to in a domain validation (DV) certificate is that the certificate applicant demonstrated effective control over an Internet domain name. This is something well-suited to being checked by software.

By contrast, a digital certificate attesting to an applicant's legal identity (for S/MIME, code signing, document signing, or other possible applications) probably can't be issued automatically without human intervention, because the means of proving legal identity that we have available all seem to involve human beings, physical documents, photographs, birth certificates, tax documents, affidavits by other individuals, biometrics, etc., which are normally assessed by other human beings at some stage in the process. (For other kinds of web site certificates, that involve greater verification of corporate legal identity, certificate authorities have also used procedures like looking up a corporate entity in a companies registry, and then contacting the entity offline using contact information found there, like FAX, telephone, or postal mail.)

Let's Encrypt's model doesn't map well onto that kind of process, and it would presumably involve hiring staff to review identity documents, and not be compatible with issuance of certificates at no charge to the applicant.

So this kind of service will probably remain a paid offering provided by for-profit certificate authorities, or, in some cases, by government entities.

e-Residency of Estonia

[griffin]

Correct me if I'm wrong, @schoen, but I believe there's nothing stopping someone from "using" the certificate for those purposes, but the CA just won't vouch for it. It's not like the crypto stops working. To me it just means my identity becomes xyz.tld instead of Jonathan Griffin. As long as someone trusts that I control xyz.tld then there's a kind of pseudo-mapping.

[JamesLE]

@griffin

an authoritarian third-party (the CA)

"Authoritative," I hope.

@griffin

The "abilities"/extensions granted to a certificate by a CA purely mean that the CA will vouch for those "enhancements" if enquired.

A lot of client software inspects the X.509 attributes that define the certificate's purpose (see, e.g., RFC 5280), and will not trust a certificate with a mismatched purpose. For example, I think Adobe document management products expect specific key usage attributes, and will not accept a Let's Encrypt certificate for that reason.

[griffin]

That sounds right. It seems purely based on what the software will allow. I mean, securing a mailserver is definitively different in certain ways than securing a webserver and yet that's allowed.

[schoen]

@griffin

That sounds right. It seems purely based on what the software will allow. I mean, securing a mailserver is definitively different in certain ways than securing a webserver and yet that's allowed.

Sure, although here the EKU is just called "Server Authentication" and so every kind of TLS server is already covered.

Conceivably Let's Encrypt could add other EKUs in the future, if that turned out to be useful and not misleading.

@griffin

To me it just means my identity becomes xyz.tld instead of Jonathan Griffin. As long as someone trusts that I control xyz.tld then there's a kind of pseudo-mapping.

The main case where this would work now is client authentication, which is the other EKU that Let's Encrypt has listed.

You could certainly use the subject key for some other purpose that's not covered, or not clearly covered, by a declared EKU, but that raises the question of what software would accept those signatures solely based on the certificate from Let's Encrypt. I don't know the answer!