Please see bug 193367, bug 209166 and bug 209168 for context. In the past, it was possible to - receive a signed S/Mime message from someone using an S/Mime certificate that was not trusted by self - open cert manager, and explicitly trust the certificate of the other person (only recommended after having verified the correctness the certificate, e.g. by comparing the certificate's fingerprint with the sender in person) - send an encrypted email reply Since bug 193367 was fixed, which happened some time after Mozilla 1.3, the above is no longer doable. Because of that, this bug is partially a regression, and partially a RFE because of the request to provide the feature in a different way. This bug asks for the following enhancement to restore the functionality: When reading an S/Mime message having an invalid signature, where the reason for the signature's invalidity is missing trust (as opposed to an expired or revoked cert), when looking at the "message security info" dialog that displays the signer's certificate, Mozilla should allow the user to manually import and trust the email certificate in a single step (after having recommended the user that verification must be done in person before doing so). When the user adds trust to the certificate, Mozilla should import the certificate database and add explicit trust to it. This behaviour is obvious for certificates, that can be used for both signing and encryption. The situation is more difficult when using dual-key certificates. If we were importing only the encryption certificate, sending/replying with encrypted messages to the correspondent would work correctly. However: There is no place to store trust for the signature certificate. Therefore, incoming signed messages from the correspondent would continue to be shown as invalid, because the signing certificate is still untrusted! Therefore, for dual key certificates, I believe that both signing and encryption certificates must get imported and trust added to them, in order to fix this bug and restore the old behaviour.

This bug captures the requirements correctly. Thanks, bob

Because we agree to store signature certificates in some situations, carrying explicit trust, this means the user needs a way to see and manage those certificates. As of today, signature certificates are not displayed in cert manager. This could be done by bug 164707, which has a patch, but has not yet landed. But I tend to prefer that other people's signature certificates should not be shown in the "extra" category suggested by bug 164707, but should be shown in the other people's tab, too.

When I receive an email with an invalid signature (typically because the cert chain terminates with an unknown root CA), I can click on the pencil (signature) icon and see a cert chain. I should be able to mark any cert in that chain trusted. Doing so should cause that cert to be imported into the perm cert DB (if it hasn't already), and then marked trusted. The only thing I'm not certain about in this scenario is whether the chain displayed is the chain for the encryption cert or the signature cert. Those could conceivably be separate cert chains, and I might need to mark certs trusted in both chains.

If this is done, it would make it much easier to implement the RFC in bug 200862, which is quite similar (trust a cert where the address doesn't match against trust if the CA is unknown). At least, the GUI would be there already. I will add this as bloquing 200862.

When dealing with end-users stuck with certs from a CA that is not built in, this makes S/MIME in Thunderbird almost unusable. End users almost never know what a CA cert is let alone how to find one. This is a regular problem for me.

In addition to importing a cert received by mail, I believe you should also be able to import the certificate from a PEM file. That way, you could also add trust to a certificate downloaded from some web page, obviously after verifying the fingerprint.

(In reply to Scott Kitterman from comment #5) > When dealing with end-users stuck with certs from a CA that is not built in, > this makes S/MIME in Thunderbird almost unusable. End users almost never > know what a CA cert is let alone how to find one. This is a regular problem > for me. I just encountered this problem myself. Impossible to import an untrusted certificate and then edit trust levels. I would think this should be a relatively easy bug to squash, and it would be very helpful, for example, to individuals using self-signed certificates.

How has this missing piece of critical functionality been allowed to go unaddressed for... *checking bug history* a decade? Being able to trust self-signed email certificates is kind of important to an open, decentralized internet.

I'm guessing that large parts of the people who care about security with emails use PGP instead of s/mime. However, it is a shame that s/mime support in thunderbird is broken like this, given that it's built-in and *should be* relatively easy to use.

Please Please Please fix this ASAP! How can this really not be implemented correctly? The current situation is a pain in the **** to be honest :( I can not use self-signed S/MIME end-user certificates from a non-trusted CA. If I trust the CA (import the CA's root certficate and all needed intermediate certificates and trust them) I *STILL* CAN NOT trust/use/import the end-user S/MIME certificate issued by that _now trusted_ CA!!! Thus rendering self-signed / issued S/MIME COMPLETLY USELESS!!!!! What a disgrace to Thunderbird and it's developers..... this bug is open for noe over 10 ( *TEN* !!!!!) years!

Unfortunately this quite useful feature is not completely available. While self-signed certificates can be imported under the tab "Certificate Authority" in TB, a certificate signed from a CA can not be imported without the corresponding CA being imported already. I tried a work around in using the certutil tool. It is able to add certificates like certutil -E -n "Nickname for this S/Mime Certificate" -d . -t ,C, -i /tmp/FilenameOfCertificate.pem The certificate is visible in Thunderbird but without the matching CA thunderbird (V 45.4.0) still refuses to actually use it to encrypt mails. What a pitty it wouldn't let me use a certificate I'm sure is right. TB is just too strict.