Open Bug 1481969 Opened 6 years ago Updated 2 months ago

Thunderbird 60 unable to find certificate for signing or encrypting (SMIME) email

Categories

(Thunderbird :: Security, defect)

Product:
Thunderbird
Component:
Security
Type:
defect

Tracking

(Not tracked)

Status:
UNCONFIRMED

People

(Reporter: mozilla-bugs, Unassigned)

References

Details

Attachments

(8 files, 1 obsolete file)

THis mesdsage appear in drafts when you compose the message.
6.44 KB, image/png
Details
account settings as they appear when selecting account settings from the tool menu
10.23 KB, image/png
Details
After clicking the button Thunderbird offers this certificate. The same one it had
28.10 KB, image/png
Details
Account settings after clicking to accept the default offered
14.50 KB, image/png
Details
contents of the error log from around the time of the problem.
25.56 KB, text/plain
Details
Console_log.txt
6.71 KB, text/plain
Details
Console_log
6.71 KB, text/plain
Details
SMIME Issue Overview
322.81 KB, image/jpeg
Details
Attached image TB sign failure.JPG (obsolete) — 
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180807170231

Steps to reproduce:

    Name: Thunderbird
    Version: 60.0
    Build ID: 20180731173940

    Update Channel: release
    User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0
    OS: Windows_NT 10.0       (v 1803 with all updates applied at 08/08/2018)

When writing email select either (or both) encrypt or digitally sign the message from Options menu.

All seems fine at this stage, relevant icons appear on message.

Press "send" button - get error message as detailed

Revert to Thunderbird 52.9.1, repeat above steps & message sends fine

Upgrade back to Thunderbird 60 & error returns. It is consistent and happens without fail.

I have tried restarting Thunderbird, restarting machine, removing certificates & re-installing, but error persists. Has been tried with Outlook.com & gmail.com email addresses, with identical results.


Actual results:

After trying to send email, get error message
"Sending of the message failed.
You specified that this message should be digitally signed, but the application either failed to find the signing certificate specified in your Mail & Newsgroup Account Settings, or the certificate has expired."
or
"Sending of the message failed.
You specified encryption for this message, but the application either failed to find the encryption certificate specified in your Mail & Newsgroup Account Settings, or the certificate has expired."

Have confirmed certificate is visible in Thunderbird certificate store, expiry date in March 2019, and machine date/time is correct. And it continues to work fine in Thunderbird 52.9.1.


Expected results:

Send SMIME encrypted or signed (as appropriate for selection) email without error.
See bug 1470077 comment #8. The user there removed cert8.db (and possibly re-imported his personal certificates).
A solution for our institution was as follows:

*Go to Account Settings - "Security"

*Digital Signing - "Select"

*Simply reselect your certificate

Afterwards you are able to send SMIME encrypted or signed Emails again.
Hi all,

I tried the workaround to remove the cert8.db file but I had no luck. Even the tip in #2 doesn't work for me.

Before Thunderbird 60.0 for Mac everything works like a charm, but now...

Please tell me if you need any information to be able to replicate this behaviour.

Cheers
Flo
Reselecting certificate worked for me - thanks Franz
Hello,
I just wanted to confirm the bug. Same system as the original poster. Deleting the certificate and re-installing it did NOT solve the issue.
POSSIBLE SOLUTION:

Do check the account settings under S/MIME safety:
if the encryption certificate is missing try to choose one even if you do not want to encrypt.

That did the trick on my side. Signing emails was possible from that point on.

Cheers
See Also: → 1462915
Component: Untriaged → Security

A possible explanation/solution:
I was having the same issue in Thunderbird 68, on both Windows and Linux. I tried all of the above recommended solutions, to no avail. Then I came across bug 1574325, and had an "aha" moment.
The problem, in my case, was that the issuer of my certificate had the wrong trust settings in Thunderbird's certificate manager. So I had to get into Preferences -> Advanced -> Manage Certificates -> Authorities, and find my certificate issuer. The issuer was there all right, and listed as a proper authority - but for some reason there was no tick in the "This certificate can identify mail users" box. So I ticked it, and immediately the signing procedure was working.
Don't do this unless you really trust the certificate issuer! ... but then, if you don't, you probably wouldn't be having your certificate issued by them.
There may be lots of other ways this could go wrong, of course - the above is just one more thing to try.
I am all in favour of the idea, as expressed in bug 1574325, that the error message produced by Thunderbird in such a situation is too imprecise to be of much use.

Blocks: 74157
Attachment #8998677 - Attachment is obsolete: true

I have filled a lot of images here, but this is really an unacceptable situation, the program can obviously locate the certificate in the certificate store and read it, but for reasons I do not understand, it looses the plot.

See Also: → 531073
No longer blocks: 74157

Despite a changed IU and some other minor bits, is this the same bug as reported in Bug 531073. Both appear to revolve around available and valid certificates being reported as unable to be located.

Blocks: 74157
Flags: needinfo?(kaie)

If Thunderbird has a certificate configured, and the certificate is available, but Thunderbird thinks the certificate is invalid (cannot be verified as being valid), then it will not use the certificate and show the generic message from your screenshot in comment 8.

Note the text says "either not found or expired" - it tells you that Thunderbird isn't sure what's wrong. There is currently no code in place to give a more precise message.

The code that communicates the failure needs to be enhanced. It should distinguish between "cannot find certificate" and "certificate found but it's not usable/invalid", and display the appropriate message.

There could be other reasons why a certificate isn't valid, beyond being expired. In comment 7 Jesper explained what was wrong in their setup.

Matt, I cannot say easily what was wrong on your side. Based on your screenshots, the certificate wasn't expired on the day you reported the issue (meanwhile, it has expired...). Maybe it was the same problem as reported in comment 7.

Besides having imprecise error messages, we also don't have good diagnosis tools currently. If you have a current certificate, and the problem still occurs, feel free to send an email with a copy of your public certificate to kaie@kuix.de mentioning this bug number, and I could try to check.

Flags: needinfo?(kaie)

That does not explain the dynamic change from usable to not usable without any outside interference. The certificate had been installed and usable for almost a year when suddenly Thunderbird has a barf about it. I changed exactly nothing, just clicked the button and clicked ok and it reset to Ok. Fundamentally I have no idea what the issue is, but the problem is in Thunderbird / NSS code as this is not a web site issuing a certificate, it is me clicking on write and the auto save failing because the certificate is suddenly bad.

My feeling is this has something to do with the OCSP checking and because my internet has some issues sometime on and off again several times in a matter of a minute, the failure to validate the certificate prompts the error. I have since turned off the setting. I Will have to see if it stops this random and infrequent error. (Usually only 3 or 4 times a year.)

(In reply to Jesper Goll from comment #7)

The problem, in my case, was that the issuer of my certificate had the wrong trust settings in Thunderbird's certificate manager. So I had to get into Preferences -> Advanced -> Manage Certificates -> Authorities, and find my certificate issuer. The issuer was there all right, and listed as a proper authority - but for some reason there was no tick in the "This certificate can identify mail users" box. So I ticked it, and immediately the signing procedure was working.

Jesper, just wanted to way a big thanks. This did the trick in our case, nothing else helped. Normally, we use PGP, but this was the first time where we absolutely couldn't avoid S/MIME, so we generated our personal certificate and imported it into TB with no issue. The next hours were for searching our mistake, until we saw your post ...

And for the record, we could neither encrypt messages nor sign them before ticking that check box. Ticked it, and suddenly could encrypt as well as sign with no issue.

Best regards

And while we're at it, may I suggest that certificate authorities which are automatically added when a personal S/MIME certificate is actively imported from the file system are trusted automatically for email user identification? The current behavior is more than worrying, given the nonsense error message. After all, a user who imports a certificate which identifies himself obviously must trust that certificate's issuer to actually use that certificate; there seems to be no way around this in TB. This means that this is what the user wants to do, and there's no sense in letting the user import a personal certificate in a way that it can't be used afterwards.

Plus, the label of that tick box is wrong. It is: "This certificate can identify email users." However, email users are very rarely directly identified by a CA certificate / certificate issuer. Instead, the issuer usually signs other certificates which in turn identify email users (or are also used as intermediate certificates). Therefore, that label should should be reworded. The label of the other tick box in that dialog ("... can identify websites") is wrong in the same way.

(In reply to Binarus from comment #16)

I am glad that you found this little tidbit of information helpful -- like you, I spent a lot of time digging it out -- and I do agree with your comments. Thunderbird's behaviour when importing certificates seems rather illogical: I find it hard to imagine why someone would wish to import a certificate into an e-mail client if not in order to sign or encrypt/decrypt e-mail messages. I suppose there could be some reason for this behaviour that we don't know -- but at the very least, we may safely say that the error messages given when this problem occurs are more confusing than helpful. Let us hope for better things in the future. :)

(In reply to Jesper Goll from comment #17)

(In reply to Binarus from comment #16)

I suppose there could be some reason for this behaviour that we don't know

A final remark regarding this: I believe I have a notion of the reason.

When ticking that check box, we trust the respective CA certificate. Again: By that check box, we do not trust the one certificate we have just imported; we trust the CA certificate which was used to sign the imported certificate, and thus, we implicitly trust all other certificates which have been or will be signed by that CA certificate, too. Therefore it is generally a good idea to set some obstacles (in form of "Are you sure?" questions) before a CA certificate is trusted.

However, in this case, it doesn't make any sense. There is no way around trusting the CA certificate if we want to use the personal certificate we just have imported, so TB should do that by default.

Of course, this is only true when the personal certificate is actively imported from the file system (that is, by an explicit user action). In every other case (that is, when personal certificates are imported by automatic actions behind the scenes without letting the user know and without explicitly asking for permission), the CA certificate must not be trusted automatically, because otherwise everybody could put their own CA certificates in our TB installation and use these CA certificates to attack us.

In every case, the error message needs to be reworked.

Side note:

It would be interesting what happens when we import a personal certificate which has not been signed by a CA. At the moment, I don't have the time to test it, but I suppose that the problem which is discussed here wouldn't arise then (if TB would accept such certificates at all).

Furthermore, that problem shouldn't arise if the personal certificate is signed by one of the official CAs which are built-in in TB. Since we are not willing to pay moon prices for S/MIME certificates, are not willing to take the effort to manage and renew them every year, and are strongly against the whole idea of centralized PKIs with a few root anchors who control everything, we simply have set up our own CA. This surely causes the issue.

I manually upgraded from TB91 to TB102.0.1 (MacOS). While certficates worked flawlessly until the upgrade, I now have the same issues that I cannot send signed e-mails, receiving a message that I should verify my certificates (i.e. that they are valid for mail signing and that they are trustworthy). Quite annoying...

In my case, the problem seems to be related to an intermediate certificate (see bug 1777336 for a working fix).

Severity: normal → S3

I'd like to drop by and say this also affects me.

Situation is as follows: I have two certificates for my two accounts stored on a single smartcard. I am using /usr/lib64/onepin-opensc-pkcs11.so as my pkcs#11 device, and

pkcs11-tool --module /usr/lib64/onepin-opensc-pkcs11.so -l -O

reads my card objects just fine. I am able to find my certificates on the card in Thunderbird. I am also able to decrypt email that has previously been encrypted and sent to me using S/MIME. As a further point of data on this, the recipient of this message has an intermediate certificate that is not present in the trust store, so the signature is marked as invalid. Even when I add this certificate and modify the trust to trust email users, the signature is reported as invalid.

I frequently see issues with being unable to send signed messages. If I try to send myself a signed and encrypted message, when selecting security and then view certificates of recipients, my own certificate is marked as invalid, even though it is valid and expires at the end of 2024.

I have checked intermediate trust on the certificates.

  1. If I remove the intermediate certificate, my certificate is marked as not trusted.
  2. If I add the intermediate certificate and mark it as trusted, my certificate is marked as not valid.
  3. I managed to get the certificate to display as valid by re-importing my previously deleted CA intermediate. But Thunderbird still isn't happy.

Well, I'm not entirely useless, so I decided to run:

 MOZ_LOG="certverifier:5" thunderbird-wayland &> certverifier.log

and I got

[Parent 72781: Main Thread]: D/certverifier NSSCertDBTrustDomain: CheckSignatureDigestAlgorithm
[Parent 72781: Main Thread]: D/certverifier NSSCertDBTrustDomain: IsChainValid
[Parent 72781: Main Thread]: D/certverifier NSSCertDBTrustDomain: Top of CheckRevocation
[Parent 72781: Main Thread]: D/certverifier NSSCertDBTrustDomain: no stapled OCSP response
[Parent 72781: Main Thread]: D/certverifier OCSPCache::Get(7fffd8b12a20,"firstPartyDomain: , partitionKey: ") not in cache
[Parent 72781: Main Thread]: D/certverifier NSSCertDBTrustDomain: no cached OCSP response
[Parent 72781: Main Thread]: D/certverifier Top of VerifyCert
[Parent 72781: Main Thread]: D/certverifier NSSCertDBTrustDomain: CheckSignatureDigestAlgorithm
[Parent 72781: Main Thread]: D/certverifier NSSCertDBTrustDomain: IsChainValid
[Parent 72781: Main Thread]: D/certverifier NSSCertDBTrustDomain: Top of CheckRevocation
[Parent 72781: Main Thread]: D/certverifier NSSCertDBTrustDomain: no stapled OCSP response
[Parent 72781: Main Thread]: D/certverifier OCSPCache::Get(7fffd8b12a20,"firstPartyDomain: , partitionKey: ") not in cache
[Parent 72781: Main Thread]: D/certverifier NSSCertDBTrustDomain: no cached OCSP response
[Parent 72781: StreamTrans #20]: D/certverifier Top of VerifyCert
[Parent 72781: StreamTrans #20]: D/certverifier NSSCertDBTrustDomain: CheckSignatureDigestAlgorithm
[Parent 72781: StreamTrans #20]: D/certverifier NSSCertDBTrustDomain: IsChainValid
[Parent 72781: StreamTrans #20]: D/certverifier NSSCertDBTrustDomain: Top of CheckRevocation
[Parent 72781: StreamTrans #20]: D/certverifier NSSCertDBTrustDomain: no stapled OCSP response
[Parent 72781: StreamTrans #20]: D/certverifier OCSPCache::Get(7ffcd55bd190,"firstPartyDomain: , partitionKey: ") not in cache
[Parent 72781: StreamTrans #20]: D/certverifier NSSCertDBTrustDomain: no cached OCSP response

All looks good, no errors, my dialog is now showing valid (confusingly - I got to here by deleting and re-importing my intermediate CA). When I hit send:

[Parent 72781: Main Thread]: D/certverifier Top of VerifyCert
[Parent 72781: Main Thread]: D/certverifier NSSCertDBTrustDomain: CheckSignatureDigestAlgorithm
[Parent 72781: Main Thread]: D/certverifier NSSCertDBTrustDomain: IsChainValid
[Parent 72781: Main Thread]: D/certverifier NSSCertDBTrustDomain: Top of CheckRevocation
[Parent 72781: Main Thread]: D/certverifier NSSCertDBTrustDomain: no stapled OCSP response
[Parent 72781: Main Thread]: D/certverifier OCSPCache::Get(7fffd8b15e40,"firstPartyDomain: , partitionKey: ") not in cache
[Parent 72781: Main Thread]: D/certverifier NSSCertDBTrustDomain: no cached OCSP response

and of course, there's

mailnews.send: 
Exception { name: "NS_ERROR_FAILURE", message: "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIMsgComposeSecure.beginCryptoEncapsulation]", result: 2147500037, filename: "resource:///modules/MimeMessage.jsm", lineNumber: 468, columnNumber: 0, data: null, stack: "_startCryptoEncapsulation@resource:///modules/MimeMessage.jsm:468:25\n_writePart@resource:///modules/MimeMessage.jsm:513:12\n", location: XPCWrappedNative_NoHelper }
MessageSend.jsm:130:27

In the error console.

I've no idea what's going on, but S/MIME as it stands is utterly and completely broken. I've downgraded to TB 91.7, which at least works somewhat more reliably.

I am happy to help. Better, I know S/MIME, PKCS11, Smartcards etc, how PKIX works, what ASN.1 is, and I'm a capable developer, but I do not know the Mozilla codebase, so I'll need guidance to make some headway. If someone wants to reach out, my email here is of the form firstname.lastname@gmail.com. Take firstname.lastname, and turn it into firstname@lastname.ch, and send an email there. Or look up my smime cert in a certificate transparency log.

Just coming back to confirm that I validated that this bug also exists on Windows, Windows 11 x64 Enterprise, Thunderbird 102.5.1 x64 official release. As on Linux, I'm able to add a PKCS#11 provider and account settings can see the certificate and is happy, but the compose window reports the same error. Nothing to do with Linux packaging or my penchant for powerpc.

I'm going to grab the source of Thunderbird and see if I can identify the bug and fix it if I can.

i encounter the exact same problem for about 2 years now, since i have this S/MIME certificate and change the distri or have to reinstall thunderbird. Its a joke, really. Who needs proper encryption, as long as we have some new shiny UI.
And now i switched from tumbleweed back to fedora, and here we go again. I have to remove the cert a dozen of times and suddenly some magic happens and it works.

i dont know why but this worked now for me, after about 5 times removing the cert, so not sure what nasty bug this is or what magic goes on behind the scenes:

delete the cert from tb via the manager
add it, restart tb
select the signing certificate, restart tb
select the encryption certificate, restart tb
write an email and pray that it works

this is ridiculous

I suppose there could be multiple reasons for seeing errors with S/MIME certificates - including some that I've been lucky enough to avoid. They have worked well for me for a number of years now. Currently I am on TB 102.8.0 and still having no issues with them. I did have some initial trouble though, as described further back in this thread. I've found that:

  • You need to ensure that you have the right authority certificate installed - one that corresponds to your own certificate. This can be a bit tricky to verify, as many of these authorities have multiple "authentication trees" - so you've got to make sure you've got the right one.
  • Then you need to verify that your authority is trusted to verify e-mail users. In my case this box stayed unticked after import of the authority certificate, so I had to set it manually (in the certificate manager's Authorities section).
  • After doing the above, select your certificate in Account settings. Even if it's already been selected, I've found that I needed to re-select it after "trusting" my certificate authority.

Back when I was having these issues, I did find the error messages given somewhat unhelpful. Instead of reporting a problem with certificate trust, the message I got was that my certificate could not be found. This was rather confusing, as I could see it well enough in the certificate manager.

(In reply to oli from comment #24)

i dont know why but this worked now for me, after about 5 times removing the cert, so not sure what nasty bug this is or what magic goes on behind the scenes:

delete the cert from tb via the manager
add it, restart tb
select the signing certificate, restart tb
select the encryption certificate, restart tb
write an email and pray that it works

this is ridiculous

You gotta be careful when suggesting this because TB has direct access to some smart cards via their respective libraries and if you wipe the cert from TB you are actually wiping it from your smart card too.

Attached file Console_log.txt — 
This is still very much an issue with TB 115. I have tried all that has been suggested. Console log attached.
Attached file Console_log — 
This is still very much an issue with TB 115. I have tried all that has been suggested. Console log attached.

(In reply to Nicola Ferralis from comment #28)

This is still very much an issue with TB 115. I have tried all that has been
suggested. Console log attached.

Pointless, I ditched TB and migrated to Evolution. There is some adaptation period, I have to say this, but at least it works fine.

The same to me!
Thunderbird 115.1.0 unable to find certificate for encrypting (SMIME) email.
"End-to-end encryption requires resolving certificate issues for xxx@xxx.com." warning after clicking Encrypt button.
But the certificate is indeed in "Manage S/MIME Certificates -> People"。
The same problem happens in Mac and Windows.
There is no such problem in Thunderbird 102.14.0.
All the certificate is in RSA-1024. Is the Thunderbird 115.1.0 not supporting RSA-1024 yet?

I can confirm that I am able to send SMIME emails with my keys stored on smartcards with Evolution, as per @TheGrave's suggestion. Works fine on all architectures, so definitely Thunderbird related; evolution is happily picking up whatever pkcs11 library I configure in p11-kit.

By contrast, Thunderbird can and does read the certificates, and will actually decrypt messages sent to me using the keys I specify but fails to sign or encrypt when "send" or "send later" are pressed in the compose dialog.

This is almost certainly a regression in either NSS or how TB uses it. I am fairly sure the issue is related to the validation of intermediate certificates in the cert chain when locating the certificate on send, so people's experience will differ depending on how their certificates are issued.

@guozesheng RSA-1024 was supported about 15 years ago. These days, it is deprecated in most TLS software stacks because 1024-bit moduli are uncomfortably close to current factoring records, which at the time of writing stand at 829-bit moduli. There will soon be S/MIME "baseline requirements" from the CA/Browser forum (the industry group that sets the standards CAs need to follow for inclusion by default in browsers) which state "For RSA key pairs the CA SHALL: • Ensure that the modulus size, when encoded, is at least 2048 bits" but this has been the case in TLS for a lot longer.

All this to say you might run into problems using 1024-bit keys or root CAs and you may find software simply rejects your certificates. If you get your certificate from a public CA, you might want to point out the SMIME BR to them. If you are running your own for experimentation purposes, either make everything at least 2048-bit, or use the nist p-256 curve (I'm suggesting this because of all the curve options, it has the widest support).

Same here, but I do have trusted the CA certs and there is no intermediate IMO. But, the crypto device cannot get opened for for signict certs. See https://bugzilla.mozilla.org/show_bug.cgi?id=1851666 .

Attached image SMIME Issue Overview —

Thunderbird 115.2.0 (64-bit), thunderbird-flatpak - 1.0

Certificate for signing is different from certificate for encryption.

a) certificate for SMIME signing is found and working

b) certificate for SMIME encryption is still not found for recipients for unkown reason
1. I deleted the certificate of authority and people once.
2. I added authority certificate again and trusted authority for emails.
3. I added the recipient certificate again.
=> I am still not able to encrypt the email with SMIME for the recipient.
4. I checked the End-To-End Encryption Section in account settings.
5. I found the people/recipient certificate in the SMIME Certificat Manager.
6. I observed that the "View Certificates Of Recipients" dialog is still not able to find the certificate.
7. I didn'ẗ found a way to check if the recipient certificate is trusted, but I am wondering that the status is "not found".

Adding my experience. It turns out that Thunderbird isn't able to resolve the full certificate chain when the certificate in question signed by an intermediate CA. This is the case when validating both S/MIME and server side TLS certificates. Since this bug is about S/MIME I won't talk about server certs too much.

What I had to do to get my S/MIME certificate working:

  • Add both the root AND any intermediate CA's used to sign the certificate.
  • Ensure the checkbox is selected for the type of trust you want for all CA's you just added
  • Make sure sure signed certificate is using the same email address for the Common Name (CN) as the one you are protecting. The CN field must match!
  • Restart Thunderbird
  • Import your S/MIME certificate
  • Selecting it in the email settings

Compose a new message, and test. It should work.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: