Requested s/Mime support



any plans to create support for s/Mime / Mail clients and/or application signing?


There was another topic requesting encryption of email As far as I’m aware I’ve seen no official plans.


I want this as well.


We don’t have any plans to tackle email encryption at this time (though you can use Let’s Encrypt certs for TLS between mail servers). We don’t yet know of any email encryption solution that can scale very far beyond a technical elite niche.

It’s an important but very hard problem to solve. We don’t have the answer now but we’re keeping an eye out for promising ideas.


We don’t yet know of any email encryption solution that can scale very far beyond a technical elite niche.

Josh, what advanced technical skill or elite status is required to use Comodo’s free S/MIME solution then?

If one admits no technical skill is required to use the Comodo solution, what are the drawbacks of using it, if any?



@Josh and serverco: Thanks for the great job you guys/gals are doing. Your work is making the internet a better place for everyone.

I can imagine that things are busy right now. If in the future, when you may be exploring new waters, may I second the request for S/MIME?

  • One solution could look like Comodo’s automated process, in which the end user applies for an s/mime cert for their email address by filling out a small form.

  • An alternative solution could be background work with major email providers to issue s/mime certificates by default to each of their customers, but these certs could reside ultimately with LE’s CA, or, LE could act as a middle man for email providers’ own CA servers (which act as subordinate to LE).

Freely available website encryption is probably the single best thing that has happened to the internet in recent years. Thank you for doing the hard work. Email encryption could take that another major step forward.


why not look at PGP encryption?

There are plenty of providers who will allow you to distribute public keys so other can encrypt emails to you

Looking at this there are two aspects of SMIME one which is integrity which is fairly straight forward. The challenge with the encryption component (from what I see) is that you need to distribute certificates ahead of time to trusted parties.

ACME is designed to be automated and require little human intervention. I can’t see how this would be possible when users email clients are involved.



Dear Josh,
as far as I know, S/MIME requires an X.509 certificate like the ones you are already issuing. The difference to a certificate used for an Apache e.g. is a populated eMail field. The CN field can even be empty for S/MIME. So it should not be too difficult to offer a service like that. All it requires is a web interface to upload your CSR. The certificate could then be loaded into the browser or offered as a download.


@Jarod42, I believe it’s not that simple.

Issuing valid S/MIME certificates requires additional trust bits set on root CA certificate and enabling them is on discretion of root CA store operators, such as Mozilla, Microsoft and Apple. This would require Let’s Encrypt to use cross-signed CA to speed up inclusion process (just like with certificates for websites), which would probably require changing their agreement with IdenTrust and/or obtaing separate CA certificate (I guess that IdenTrust is not doing that for free :wink: ).

You cannot simply upload CSR to obtain S/MIME certificate, as CA has to perform validation that you are indeed in control of email address. Let’s Encrypt is based on ACME, so I guess that would require changes to ACME protocol specification (and implementing them in Boulder - CA software). It’s difficult to perform email-only validation securely, as validation message may be intercepted between SMTP servers (some servers are not using SSL/TLS at all, so messages are transmitted in clear text).

I guess there may be also some technical challenges, as more certificates would require more OCSP signing capacity - which may in turn require buying additional HSMs (Hardware Security Modules) to be able to sign responses for all certificates. Let’s Encrypt is still non-profit run for the public’s benefit - and unfortunately HSMs are not cheap.


The IETF has started working on a S/MIME extension for ACME! :smiley:


A lets-encrypt baked acme for smime solution would be really game-changer in my eyes. Imagine those setups running groupwares with central smime store and a lot of e-mail addresses handled. As far as i see, this is the typicall use-case of email in a company context or privatly used by tech-geeks. These groupwares like kopano could integrate acme for smime to retrieve certificates in a centralized manner. So there will be no excuse to have no e-mail end-to-end encryption in company contexts, when this is mechanism is available.

So i would love to see acme for smime baked by letsencrypt :grin:


Although I do enjoy “baked” products…
I think it reads better as “backed” or maybe I’m just not as hungry as you are! - LOL