Will you issue S/MIME certificates for secure email communication?
Or can your TLS certificates be used for this purpose, like StartSSL is doing it?
3 Likes
The FAQ has this:
Can I use certificates from Let’s Encrypt for code signing or email encryption?
No. Email encryption and code signing require a different type of certificate than Let’s Encrypt will be issuing.
1 Like
Seems like if Let’s Encrypt ever implements email based validation for domain control - then adding email certs (at least for email-address only with no name information in the cert) would be a trivial next step from that.
BTW StartSSL also just offers S/MIME certs for email encryption. This are no SSL certs. (Both are of course X.509 certs but that's another matter)
Hi, what came into my mind when i always read the discussion about the S/MIME certs / wildcard is an trustchain.
That mean if letsencrypt was “proved” that someone “ownes” an domain, than why not generate on request an certificate that allow:
- issuing certificates for subdomain’s
- issuing certificates for emails under this domain ?
Because no normal people should be able to to issue any certificate. If they would be able to issue certificates they could act like a CA.
And AFAIK there is actually no way in the PKI used by TLS / S/MIME to restrict issuing of certs to subdomains.
Besides this a subdomain does not always have to be under the control of the owner of the main domain.
E.g. think of free hosters or dynamic DNS services.
1 Like
Hi,
this is not correct. Even if your USE the domain my-private.dyn-dns-server.com the control
is still on the owner of dyn-dns-server. He own the domain and if he which he could also
change the ip for short time to get hold of an my-private.dyn-dns-server.com zertificate.
So i think it is legitimately to build and trust tree with CA / SubCA same as the DNS Tree.
And yes it is possible to limit an certificate to subdomains via restrictions as far as i know.
He owns the domain, but he does not own the server and he should certainly not own my private key.
Basically he should not be able to intercept traffic just because that's a subdomain of him.
Well... if I notice that the DynDNS provider redirects the traffic I would switch it.
He could do this, but this does not mean it should generally be allowed to get certs for all subdomains.
Additionally why do you want to go such a strange and complex approach?
You could just use wildcard certs - .currently not with LE - but other CAs support this and that’s the reason why such wildcard certs exist.
1 Like
Implemented a SMIME-milter into postfix and tried to sign/encrypt emails using the Let's Encrypt certificate.
It successfully sign the email, but other providers/email-clients don't trust.
Thunderbird 38.5.0:
The certificate used to sign the message was issued by a certificate authority that you do not trust for issuing this kind of certificate.
Outlook 2015:
German
Das Zertifikat, das zum Erstellen dieser Signatur verwendet wurde, hat nicht die richtigen Eigenschaften, um fĂĽr das digitale Signieren von Nachrichten verwendet zu werden.English
The certificate that was used to create this signature does not have the right properties to be used for digitally signing messages.
Damn, it would be a great step forward to use these certificates for signing emails as well. 
2 Likes
Hm this is an interesting new point. LE does not like to sign Certificate for an mail account.
But if an server is trusted why not allow him to sign the email with his certificate for sending
automatic generated mails ?
-> Because the mail client verify against the from mail address and not against the sending server.
So even if the cert would allow mail signing it would not created an trusted mail.
This behavior is deliberate; the extended key usage (EKU) is not set to allow use with S/MIME, because Let’s Encrypt has not validated control over individual e-mail accounts.
If you’d like to use Let’s Encrypt certificates to encrypt e-mail transfer, you can use one with SMTPS, STARTTLS, or IMAPS. That will provided a kind of e-mail encryption in transit that corresponds to what the CA has tried to verify control over. Yes, this is different from S/MIME and e-mail software will represent it differently. On the bright side, it should help with getting the padlock in the new Gmail e-mail transit security indication!
3 Likes
S/MIME is about confidentiality of the MESSAGE.
SSL/TLS is about confidentiality of the TRANSMISSION. Where a mail hub has total view of a message. Quite something different.
When a domain name is validated, it’s mail addresses can be validated as well by sending a link. (possibly using a signed message) with a link that needs to be validated.
S/MIME is about knowing E-mail addresses. If you need to know persons a merrit type system like PGP, or https://CACert.org is required which requires proof of identity.
I really hope that Let’s encrypt will start issuing S/MIME certificates soon with StartCom being put on the blacklist by Mozilla any day now! There are not many free options left. None that I like, anyway.
S/MIME certificates would require a lifetime of 1 or 2 years however, you don’t want to deal with them even more frequently. It’s already a pain to do it once a year. And you have to keep around the old certificates to be able to decrypt old messages and check their signatures.
1 Like
Comodo is also issuing free S/MIME certificates (for non commercial activities).
I too hope to see LE issue S/MIME certificates, but using S/MIME certificates with 3 months validity will be a pain…
Yep, Comodo is one of those CAs I’d rather not use with their bad security record.
https://www.cacert.org might be of more value here.
Those are certificates that identify persons, not machines. Hence they were never included in the browsers besides triggering Mozilla to rethink the certificate business.
Most probably the non-inclusion also created LE.
I fail to see how LE can issue certificates that make a statement about personal identify without setting up a shop to verify people.
CACert has this.
If you put the root certificate of CA-Cert in your trusted store, you can also verify machines if you like.
Why do you need to validate Control of individual email accounts?
You could easily do that you can create S/MIME certificates for *@domain.tld (eg you can specify any email you want) provided you can do DNS-01 validation for domain.tld
Because if you have such access to a zone file so you can validate DNS-01 for domain.tld, then you also have such access you can Point the MX anywhere you want, and thus you have implicit Control over ANY email acccount tied to domain.tld
Same with subdomain, if you can DNS-01 validate mydomain.somedyndnsprovider.org then you have implicit Control over *@mydomain.somedyndnsprovider.org
I guess many e-mail encryption users don’t want to have to trust their providers (they intend the encryption to protect confidentiality against the mail server operator too). Correspondingly, if they do all trust their providers, they can already use STARTTLS over SMTP between providers to protect the data in transit.
But the thing is, that most other S/MIME providers which provide email-only authentication, sends a email with a one-time code or a link to get the certificate.
This means that the server operator can issue S/MIME certificates for any email account on the server. Theres nothing that prevents the server operator from doing the whole validation process at for example comodo or Actalis and then intercepting the validation email and using it.