# Requested s/Mime support

**URL:** <https://community.letsencrypt.org/t/requested-s-mime-support/8351>\
**Category:** Feature Requests\
**Created:** [January 6, 2016, 8:05am UTC](https://community.letsencrypt.org/t/requested-s-mime-support/8351 "2016-01-06T08:05:53Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![kruisdraad](https://avatars.discourse-cdn.com/v4/letter/k/e19b73/32.png) [@kruisdraad](https://community.letsencrypt.org/u/kruisdraad)\
**Post date:** [January 6, 2016, 8:05am UTC](https://community.letsencrypt.org/t/requested-s-mime-support/8351/1 "2016-01-06T08:05:53Z")

</div>

Hi,

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

---

<div class="post-metadata">

**Author:** ![serverco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/serverco/32/4251_2.png) [@serverco](https://community.letsencrypt.org/u/serverco)\
**Post date:** [January 6, 2016, 8:14am UTC](https://community.letsencrypt.org/t/requested-s-mime-support/8351/2 "2016-01-06T08:14:41Z")

</div>

There was another topic [requesting encryption of email](https://community.letsencrypt.org/t/project-proposal-lets-encrypt-email/4548) As far as I’m aware I’ve seen no official plans.

---

<div class="post-metadata">

**Author:** ![moagm316](https://avatars.discourse-cdn.com/v4/letter/m/b5ac83/32.png) [@moagm316](https://community.letsencrypt.org/u/moagm316)\
**Post date:** [January 9, 2017, 3:56am UTC](https://community.letsencrypt.org/t/requested-s-mime-support/8351/3 "2017-01-09T03:56:20Z")

</div>

I want this as well.

---

<div class="post-metadata">

**Author:** ![josh](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/josh/32/10641_2.png) [@josh](https://community.letsencrypt.org/u/josh)\
**Post date:** [January 18, 2017, 5:24am UTC](https://community.letsencrypt.org/t/requested-s-mime-support/8351/4 "2017-01-18T05:24:50Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![JDW1](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jdw1/32/10111_2.png) [@JDW1](https://community.letsencrypt.org/u/JDW1)\
**Post date:** [February 7, 2017, 1:24am UTC](https://community.letsencrypt.org/t/requested-s-mime-support/8351/5 "2017-02-07T01:24:13Z")

</div>

> **josh**  
> 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?

> **[InstantSSL Official Site | Free Trial SSL Certificate](https://www.instantssl.com/products/ssl-trial-ssl-certificate-tls)**
>
> Our free Trial SSL certificates are not the watered-down versions you might get elsewhere — these are domain-validated, fully functional 256-bit encryption SSL certificates signed by the same 2048-bit root as a paid certificate, giving you the full...

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

Thanks.

---

<div class="post-metadata">

**Author:** ![VS45937](https://avatars.discourse-cdn.com/v4/letter/v/e36b37/32.png) [@VS45937](https://community.letsencrypt.org/u/VS45937)\
**Post date:** [September 24, 2017, 11:39pm UTC](https://community.letsencrypt.org/t/requested-s-mime-support/8351/6 "2017-09-24T23:39:06Z")

</div>

@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.

---

<div class="post-metadata">

**Author:** ![ahaw021](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ahaw021/32/14882_2.png) [@ahaw021](https://community.letsencrypt.org/u/ahaw021)\
**Post date:** [September 25, 2017, 4:16am UTC](https://community.letsencrypt.org/t/requested-s-mime-support/8351/7 "2017-09-25T04:16:58Z")

</div>

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

> **[S/MIME](https://en.wikipedia.org/wiki/S/MIME)**
>
> S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for public key encryption and signing of MIME data. S/MIME is on an IETF standards track and defined in a number of documents, most importantly RFCs 3369, 3370, 3850 and 3851. It was originally developed by RSA Data Security Inc. and the original specification used the IETF MIME specification with the de facto industry standard PKCS#7 secure message format. Change control to S/MIME has since been vested in the IETF and the spe

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.

Andrei

---

<div class="post-metadata">

**Author:** ![Jarod42](https://avatars.discourse-cdn.com/v4/letter/j/fbc32d/32.png) [@Jarod42](https://community.letsencrypt.org/u/Jarod42)\
**Post date:** [November 19, 2017, 10:40am UTC](https://community.letsencrypt.org/t/requested-s-mime-support/8351/8 "2017-11-19T10:40:42Z")

</div>

> [@josh](#):
>
> It's an important but very hard problem to solve.

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.

---

<div class="post-metadata">

**Author:** ![mkwm](https://avatars.discourse-cdn.com/v4/letter/m/87869e/32.png) [@mkwm](https://community.letsencrypt.org/u/mkwm)\
**Post date:** [November 19, 2017, 2:11pm UTC](https://community.letsencrypt.org/t/requested-s-mime-support/8351/9 "2017-11-19T14:11:41Z")

</div>

@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 😉 ).

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.

---

<div class="post-metadata">

**Author:** ![renne](https://avatars.discourse-cdn.com/v4/letter/r/f475e1/32.png) [@renne](https://community.letsencrypt.org/u/renne)\
**Post date:** [February 8, 2018, 9:28am UTC](https://community.letsencrypt.org/t/requested-s-mime-support/8351/10 "2018-02-08T09:28:12Z")

</div>

The IETF has started working on a [S/MIME extension for ACME](https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/)! 😃

---

<div class="post-metadata">

**Author:** ![cguenther](https://avatars.discourse-cdn.com/v4/letter/c/e274bd/32.png) [@cguenther](https://community.letsencrypt.org/u/cguenther)\
**Post date:** [January 3, 2019, 11:18am UTC](https://community.letsencrypt.org/t/requested-s-mime-support/8351/11 "2019-01-03T11:18:32Z")

</div>

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 😁

---

<div class="post-metadata">

**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\
**Post date:** [January 3, 2019, 10:06pm UTC](https://community.letsencrypt.org/t/requested-s-mime-support/8351/12 "2019-01-03T22:06:23Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![joncamfield](https://avatars.discourse-cdn.com/v4/letter/j/c57346/32.png) [@joncamfield](https://community.letsencrypt.org/u/joncamfield)\
**Post date:** [April 29, 2019, 8:10pm UTC](https://community.letsencrypt.org/t/requested-s-mime-support/8351/13 "2019-04-29T20:10:26Z")

</div>

Flagging that Comodo/InstantSSL is discontinuing their free S/MIME support under their new structure (Sectigo?). StartCom’s certs are no longer trusted for good reason, and CACert requires user configuration to trust their certs for all purposes, which is suboptimal. It looks like there is an Italian cert provider (actalis.it) still offering 1-year S/MIME certs, but the space is shrinking.

While I would overall prefer GPG, S/MIME is built in across platforms, including mobile, without having to support a wide variety of different helper applications which don’t interoperate perfectly (and/or get mangled by MS Exchange).

All this to say, I know this is a long-standing ask of LE, which has been reliably rebuffed – but – it could be amazing in terms of normalizing e2e encrypted and authenticated email.

(I am happy to help seek additional sources of funding and provide mountains of uses cases and personas)

---

<div class="post-metadata">

**Author:** ![SilverbackNet](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/silverbacknet/32/1032_2.png) [@SilverbackNet](https://community.letsencrypt.org/u/SilverbackNet)\
**Post date:** [April 30, 2019, 3:05am UTC](https://community.letsencrypt.org/t/requested-s-mime-support/8351/14 "2019-04-30T03:05:37Z")

</div>

It seems like Signal and other messaging platforms designed from the ground up to be e2e have taken over entirely, though. And while nominally supported, built-in S/MIME usability is … woeful, at best.

I’d totally be overjoyed if LE supported it, like any advancement, but S/MIME kind of died on the vine outside of internal networks.

---

<div class="post-metadata">

**Author:** ![lol768](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/lol768/32/31561_2.png) [@lol768](https://community.letsencrypt.org/u/lol768)\
**Post date:** [April 30, 2019, 4:58pm UTC](https://community.letsencrypt.org/t/requested-s-mime-support/8351/15 "2019-04-30T16:58:53Z")

</div>

> [@joncamfield](#):
>
> Flagging that Comodo/InstantSSL is discontinuing their free S/MIME support under their new structure (Sectigo?). StartCom’s certs are no longer trusted for good reason, and CACert requires user configuration to trust their certs for all purposes, which is suboptimal. It looks like there is an Italian cert provider (actalis.it) still offering 1-year S/MIME certs, but the space is shrinking.

Obligatory, 'came here to post this' - but yes, the options are definitely narrowing. It's a huge shame ISRG haven't committed to doing anything in this space.

> [@SilverbackNet](#):
>
> It seems like Signal and other messaging platforms designed from the ground up to be e2e have taken over entirely, though. And while nominally supported, built-in S/MIME usability is … woeful, at best.

I don't see the relevance of Signal, it's an IM platform.

What's the problem with S/MIME usability in modern email clients? It's certainly easy enough to sign and encrypt messages in Thunderbird. OWA supports it, GMail in organisations supports it (and can verify signatures just fine with the consumer version).

> [@SilverbackNet](#):
>
> I’d totally be overjoyed if LE supported it, like any advancement, but S/MIME kind of died on the vine outside of internal networks.

I'd argue adoption has been limited precisely because certificates have been a pain to obtain.

---

<div class="post-metadata">

**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\
**Post date:** [April 30, 2019, 5:14pm UTC](https://community.letsencrypt.org/t/requested-s-mime-support/8351/16 "2019-04-30T17:14:33Z")

</div>

If only someone would make a simple and automated way to obtain such certs…

---

<div class="post-metadata">

**Author:** ![SilverbackNet](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/silverbacknet/32/1032_2.png) [@SilverbackNet](https://community.letsencrypt.org/u/SilverbackNet)\
**Post date:** [May 1, 2019, 5:10pm UTC](https://community.letsencrypt.org/t/requested-s-mime-support/8351/17 "2019-05-01T17:10:21Z")

</div>

> [@lol768](#):
>
> I don't see the relevance of Signal, it's an IM platform.

And I don't see the relevance in splitting messaging into "IM" vs "email" when they're essentially the same thing, merely presented slightly differently in the client. Gmail's web interface famously blurs this line significantly. Signal is a decentralized store-and-forward protocol to exchange encrypted messages.

Signal clients turn all of the steps to get the equivalent to S/MIME working for an individual (who doesn't have an IT infrastructure to do it for them) into a turnkey package, with a few buttons you can click to generate a new encryption key or erase an old (along with any unsaved messages encrypted with it) permanently.

Unless you need your identity verified by real documents ($$$), I don't see the purpose of pursuing S/MIME over currently established secure messaging routes. After all, that was the real original purpose of S/MIME -- identity and organizational verification alongside encryption.

---

<div class="post-metadata">

**Author:** ![lol768](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/lol768/32/31561_2.png) [@lol768](https://community.letsencrypt.org/u/lol768)\
**Post date:** [May 1, 2019, 5:47pm UTC](https://community.letsencrypt.org/t/requested-s-mime-support/8351/18 "2019-05-01T17:47:43Z")

</div>

> [@SilverbackNet](#):
>
> And I don’t see the relevance in splitting messaging into “IM” vs “email” when they’re essentially the same thing, merely presented slightly differently in the client. Gmail’s web interface famously blurs this line significantly. Signal is a decentralized store-and-forward protocol to exchange encrypted messages.

There's a very significant differentiator that immediately comes to mind: adoption. How many organisations do you know of that are using Signal? S/MIME is definitely already in significant use within government and industry. People have email clients which support it out of the box. How many systems have a Signal client pre-installed?

I'd also argue that their is a significant difference between "IM" and email, and the user expectations that go along with the two different forms of communication. This is definitely more of a UX thing, but there's no concept of a 'conversation' thread AIUI. There's much more of an expectation of real-time messaging with these platforms too.

* * *

Anyway, I fear we are straying off-topic. For anyone else interested in this, @josh posted a comment on a HN thread today [re-affirming that S/MIME is not something LE is interested in pursuing](https://news.ycombinator.com/item?id=19796853).

---

<div class="post-metadata">

**Author:** ![FranklinYu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/franklinyu/32/28442_2.png) [@FranklinYu](https://community.letsencrypt.org/u/FranklinYu)\
**Post date:** [August 21, 2019, 5:45pm UTC](https://community.letsencrypt.org/t/requested-s-mime-support/8351/20 "2019-08-21T17:45:48Z")

</div>

> [@ahaw021](#):
>
> 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.

I think this is still possible. Instead of installing certbot (or any ACME client) in the server, we install it in the same machine running email client. We will need the user to interact (like clicking a link in email), but this is no more complicated than current S/MIME certificate issuers like Sectigo (Comodo). In addition, this is pretty scalable on issuer's side, as scalable as current ACME for TLS certificates.

---

<div class="post-metadata">

**Author:** ![Sid](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/sid/32/1565_2.png) [@Sid](https://community.letsencrypt.org/u/Sid)\
**Post date:** [November 19, 2019, 8:19pm UTC](https://community.letsencrypt.org/t/requested-s-mime-support/8351/21 "2019-11-19T20:19:40Z")

</div>

The situation for S/MIME in a private setting is bleak.

**There isn’t a single CA** that will sign your S/MIME certificate for free with a duration of one year or more.

There are two CAs that I am aware of that generate a private key for you (which is a total no-go). They are secorio and wisekey. People who are not knowledgeable will fall for these scams.

This leaves a huge gap for Let’s encrypt to fill.

[Next page](https://community.letsencrypt.org/t/requested-s-mime-support/8351.md?page=2)
