Why Letsencrypt certificates are not valid for email?

Issuance Policy
1

The FAQ states that the certificates issued by Letsencrypt are not valid for email or code signing, but I’m curious to know exactly why. What is different?

The think is that I’m planing to run certain project and, after noticing that the chosen hosting doesn’t provide a pre-configured SMTP server for non-managed Dedicated Servers, I started to search how to properly configure one and spotted this guide. On the certificate generation step I don’t see any important difference from the Certificate Signing Request that is used to get Letsencrypt certificates.

2

Let’s Encrypt certificates are perfectly fine for mail servers. You just can’t use them for client side authentication, using it on a server is fine.

Code signing requires OV or EV IIRC, as Let’s Encrypt only issues DV certificates, they can’t be used for code signing.

1 Like
3

That's good to know, thanks for your fast reply. I think the FAQ should be updated to clarify this point.

1 Like
4

Hi,

i must say that @kelunik is not fully correct. The certificate can be used for client authentication.
It is even explicit mentioned in the extended key usage. "TLS Web Client Authentication (1.3.6.1.5.5.7.3.2)"
It can be client or server cert in the SSL/TLS Protocol (Transport Encryption) :grin:
But ic can not be used as s/mime certificate for message encryption. :cry:
This is because there is no email validation in the LE system.

3 Likes
5

Would be kind of a pain to renew your certificate every 3 months, also the web of trust (like gpg) would be harder to maintain. Every cert needs to be signed by its previous certificate or something.

It would be cool if clients like Thunderbird built in that process.

6

Nah, I've set a cron job to run weekly. I won't even notice.

By default, the official client will only renew if your certs are within their last month before expiring. The client also set up an "archive" directory for your certs, which stores your current and previous certificates. But it also sets up a "live" directory containing symlinks to the current certs. Postfix and Apache point to the symlinks, and when the client performs a renewal, the symlinks get updated. You simply need to run a "postfix reload" and you're done (that's part of my weekly cron).

Or every cert would need to be signed by the same key? :wink:

(Which they are! Let's Encrypt is compatible with public key pinning!)

7

Sadly all the points you say are only for the website (HTTPS/SMTPS) part, not for the S/MIME or GPG type email certitficates the OP mentioned.

S/MIME do work with a certificate issuer tree system, but still, renewing those is a pain. In GPG the the Web of Trust part is not entirerly possible with LE.

1 Like
8

Oh, but Let’s Encrypt keys can’t be used for S/MIME anyway.

Sorry, cross-communication. The OP thought the FAQ said LE certs couldn’t be used with Postfix (they can). The FAQ was actually talking about S/MIME encryption, not SMTP encryption. I made the same mistake last year when I first got interested in LE.

Years ago I set up Enigmail with Seamonkey, and went through all that Web of Trust stuff then. You don’t need a centralised authority for that (even if you can), you can set that up yourself. That’s what the web of trust is all about :slight_smile:

9

The certificate works fine in postfix, exim, dovecot and such indeed, plus auto renewal there is not a problem. I do agree that the term ‘email encryption’ is a bit vague here. Plus, the usage of S/MIME is a lot lower than normal certificates.

10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.