1791490 - S/MIME Recipient's Cert Marked Invalid when Smartcard is present.

Status: RESOLVED INCOMPLETE

(MailNews Core :: Security: S/MIME, defect)

Description

[Train Dancer]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36

Steps to reproduce:

System: openSUSE Leap 15.4, TB 102.2.2, opensc 0.22.0-150400.1.7.x86_64, with DoD PIV 2 "CAC" card.

With S/MIME selected, enter a known recipient's address. Select "S/MIME/View Certificates of Recipients". Dialog reports recipient's cert as "Valid".

Now insert Smartcard and repeat. Cert is now marked as "Invalid".

Actual results:

Unable to send S/MIME Smartcard encrypted email.

Expected results:

Email encrypted and sent successfully.

Note that Smartcard S/MIME has been working here for many years. This problem appeared when the unsolicited upgrade to 102.2.2 occurred.

Comment 1

[Kai Engert [:KaiE:]]

Lew, I've read in the e2ee mailing list that you have already reverted to 91. Will you still be able to help test this bug? Do you know how to use the Profile Manager? Would you be able to create a second, fresh profile, which you'd only use with Thunderbird 102 for testing, in which you recreate your S/MIME setup? This way you could continue to use 91 with your existing profile, and only use 102 with the new profile for testing purposes.

The problem with smartcard bugs is, that I find them difficult to reproduce. I currently don't have an S/MIME smartcard setup.

I'd ask for a variety of tests. The first thing I'd like to find out if the problem is actually related to your own certificate, because when sending an encrypted email to someone else, Thunderbird wants to encrypt for yourself, in addition.

(1) Try to send a signed-only email (not encrypted) to yourself.

(2) Try to send an encrypted-only email (not signed) to yourself.

(3) Try to send an encrypted-only email to someone else (not signed).

Which of those works?

I wonder if there's a problem with automatically unlocking the smartcard, could you try to unlock it manually?
Settings, private, scroll down, security devices, on the left hand side find your smartcard, then click Log In on the right hand side.

With the smartcard logged in (unlocked), please repeat the tests. Does it make a difference?

Comment 2

[Train Dancer]

Yes, I'll be able to test and reproduce. I've got lots of machines at work! I'll get back with you soon.

Comment 3

[Train Dancer]

I've done the testing, sorry it took so long.

All three of the test cases failed both before and after logging in to the card. The failure modality was the same for all cases, where the recipient's cert is reported as being "Valid" until the smartcard is inserted. Then, checking the recipient's cert again it's reported as being "Invalid" and the mail can't be sent. This happened both sending to myself and to someone else for whom I have their public cert. When the smartcard is removed the recipient's cert is again "Valid". Of course, signed or encrypted mail can't be sent since the card is removed. When viewing the cert while it's reported as Invalid everything looks okay regarding dates and the certificate chain.

Again, reading encrypted traffic works as expected.

Comment 4

[Magnus Melin [:mkmelin]]

NOTE: bug 1519093 comment 19 has instructions for how to simulate a smartcard.

Comment 5

[Kai Engert [:KaiE:]]

Could the smartcard have intermediate CA certificates, which allow an issuer path to a different root certificate, and that other root certificate isn't marked as trusted as an email CA?

And with the smartcard absent, other intermediates are used for building a chain to the root, and that way a trusted root CA is found?

Comment 6

[Kai Engert [:KaiE:]]

We didn't get sufficient information, my question remained unanswered.