Regression, TB v137 no longer attaches S/MIME cert from ECA
Categories
(NSS :: Libraries, defect)
Tracking
(Not tracked)
People
(Reporter: jgrant, Unassigned, NeedInfo)
Details
(Keywords: regression, regressionwindow-wanted)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:137.0) Gecko/20100101 Firefox/137.0
Steps to reproduce:
After receiving the v137.0.2esr update, TB no longer will send emails signed or encrypted with ECA S/MIME certificates. (Unsigned messages work fine.) I get "Send Message Error: Sending of the message failed. Unable to sign message. Please check that the certificates specified in Mail & Newsgroups Account Settings for this email account are valid and trusted for mail". I verified functionality of ECA certs at IdenTrust and settings in TB. Per suggestion in e2e forum, I reverted to TB 128.7.0esr, and later v128.9.2esr after an auto-update, in v128 signatures are attached and encryption works in both those versions.
Actual results:
TB v137 requests and accepts the ECA PIN via ActivCLient mddleware, but no matter how many attempts to send the message, I receive the above Send Message Error.
Expected results:
On TB v128, after opening a create message window for the first time, TB immediately requests the PIN for the certs on the ECA card via the ActivClient middleware. After creating a message, the first one or two attempts at sending will result in the Send Message Error, but following that, the message will send normally with signature attached and encrypted if desired. If the PIN has timed out (10 minutes), I need to revalidate the PIN, and the message sends within one or two tries.
Updated•19 days ago
|
Comment 1•19 days ago
|
||
Jon, Would you be able to help us narrow in on when this was regressed using https://mozilla.github.io/mozregression/ or by testing with various versions leading up to 137.0.2? For the latter, you can find 136.0, 136.0.1, 137.0, 137.0.1, etc at https://ftp.mozilla.org/pub/thunderbird/releases/
Comment 2•18 days ago
|
||
Just a few additional thoughts.
The report says that the interaction with that smartcard middleware was already unreliable with 128.
I think this is most likely a problem in the pkcs#11 layer. I assume you have a third party pkcs#11 module installed and registed in Thunderbird.
I think a better point of contact would be the vendor that provides your hardware and your software. They should test whether the configuration you're using is supposed to work, or what they have to say about limitations etc.
I think that vendor should help you run a debug log of the interaction from Thunderbird with your security modules, and maybe that could allow someone to understand what's going wrong.
If 128 worked and recent versions don't, I think it's unlikely that a change in Thunderbird is responsible.
A change in the NSS library might be more likely.
As Corey said, the exact version when this regresed would still be helpful. It would also allow us to identify which version of NSS still worked better, and which one no longer works for you at all.
Comment 3•18 days ago
|
||
@Kai, can you add severity and priority, please.
Updated•18 days ago
|
I do not believe my issues are related to the IdenTrust ECA and ActivClient middleware, which have been in use together since 2017. Only the certificates have been updated since then, in 2020 and 2023, and laptop in 2021. On March 13 I had contacted IdenTrust support re: the access time hang of 20-30 sec each time Thunderbird encountered an encrypted message, and TB seemed to be accessing the middleware as the icon flickered between red and blue during the delay time. Support indicated that the middleware just makes the token available on the computer and has nothing to do with the message access. They suggested and I confirmed normal functionality using their test page on 13 March 2025. Here are specifics for the middleware:
ActivClient -- WINDOWS VERSION --
Platform Info = Microsoft® Windows 10 (TM) or later
Major Version = 10 or later
Minor Version = 0 or later
Service Pack = 0
-- LIBRARY VERSION --
Mini Driver Library:
Name: ac.scapi.scmd.dll
Version: 7-1-0-128
P11 Library:
Name: acpkcs211.dll
Version: 7-1-0-128
BSI Library:
Name: acbsi21.dll
Version: 7-1-0-128
PIV Library:
Name: acpivapi.dll
Version: 7-1-0-128.
Re: observations with other versions of TB, I examined several, and observed that v130.0b3 was the last successful version to send a signed email, v131.0 was the first version that failed. My observations from those two cases are below.
V130.0b.1: Opened new email, entered recipient address, acknowledged alert to authenticate to token (but did not receive ActivClient window, probably still authenticated from previous use), first attempt to send resulted in Send Message Error, second attempt successfully sent and received with valid signature.
V130.0b3: Opened new email, entered recipient address, received Send Message Error (prior to sending). Second attempt to send message successful, message received with valid signature. Closed and restarted TB, edited previously sent message as new, acknowledged alert to authenticate, noted that previous message body did not include text signature from previous message, typed in new message. First attempt to send generated Send Message Error, second attempt successful and received with valid signature.
V131.0: Opened new email, entered recipient address, acknowledged alert to authenticate to token (but did not receive ActivClient window, probably still authenticated from previous use), all attempts to send resulted in Send Message Error. Did note that during delay between send and error message the ActivClient indicator flashed red and blue several times. Closed TB, manually authenticated to ActivClient, restarted TB , opened new email, no alerts until I tried to send message, each time received Send Message Error.
Comment 5•18 days ago
|
||
Jon, please get a regression range using https://mozilla.github.io/mozregression/quickstart.html
Sorry, I have not had available bandwidth to do the regression, and will be on travel all next week. I will update when I can.
Description
•