User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Updated to 91.0.1

Actual results:

Various issues with encryption:

• Apparently expired certificates were removed. This prevents reading old emails encrypted with those certificates.
• After sending an encrypted email, no encrypted emails can be read. TB reports that the messages does not have any certificates.
• When sending a signed or encrypted email, a Windows Security dialog pops up asking to allow the application access to the private key. This may be related to using YK smartcards though the email encryption certificate is not stored there but in TB. See attached image.

Expected results:

Everything should have worked as before.

(In reply to Orion Poplawski from comment #0)

Various issues with encryption:

• Apparently expired certificates were removed. This prevents reading old emails encrypted with those certificates.

There were not changes in this regard.

• After sending an encrypted email, no encrypted emails can be read. TB reports that the messages does not have any certificates.

I'm not sure what you're reporting. To read encrypted mails, you only need your key. Certificates is related to TLS and S/MIME. But messages never have any certificates.

• When sending a signed or encrypted email, a Windows Security dialog pops up asking to allow the application access to the private key. This may be related to using YK smartcards though the email encryption certificate is not stored there but in TB. See attached image.

There is bug 1726301 but unclear what that might be about.

So, after further investigating it appears that issues may be limited to one or two users that have multiple email certificates. Note that we are using S/MIME encryption and not OpenPGP. I'm trying to coordinate time with affected users to further diagnose. Is there any more information we should collect?

Bug 1726301 seems specific to macOS, while these issues are on Windows. Also, only certain people are seeing the pop-up and we don't yet know what is common among them.

That would be good to find out yes.
Possibly could be related to the security.enterprise_roots.enabled pref.

Okay, the difference appears to be whether a user has the certificate loaded into the WIndows Certificate Store or not. If they do, the "Your Certificates" dialog shows "OS Client Cert Token (Modern)" for the "Security Device" and there are problems with encryption. If not, they don't. Things also work if they unload the oscertclient security device. Unfortunately, this returns on restart. Is there a way to disable this permanently (at least for now) ?

I think that's the pref I mentioned: security.enterprise_roots.enabled and maybe security.osclientcerts.autoload.

Thanks, setting security.osclientcerts.autoload to false is working for us for now. What other information can we provide to help get this issue fixed?

Also, removing the user certificates from the TB store I am able to send encrypted emails but not to read them. See attached image. I can read the message on another version of TB.

Hard to say. Maybe the message is using some no longer accepted encryption algorithm or something like this (I don't know what/if any got disabled 78->91, but it's possibly). In the version where it's working, do you see any details about what's used?

91 works perfectly fine when the certs are stored in TB, it only fails when the certs are in the Windows Certificate store. So I don't think algorithms are involved here.

As noted in the duplicate, it looks like S/MIME is not implemented for the os store. https://hg.mozilla.org/mozilla-central/file/6ed51ef7419537ebd0f96d0ae520ae97314d25c8/security/manager/ssl/osclientcerts/src/lib.rs#l730

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/7bba1e987b41
disable security.osclientcerts.autoload for Thunderbird by default since it doesn't work with S/MIME. r=benc

Comment on attachment 9238899 [details]
Bug 1726442 - disable security.osclientcerts.autoload for Thunderbird by default since it doesn't work with S/MIME. r=benc

[Approval Request Comment]
Regression caused by (bug #): bug 1696997
User impact if declined: OSX and Windows users will have problems using S/MIME, as it will try to look at the OS level certificates and not what you have in Thunderbird. But that part is not implemented for S/MIME...
Testing completed (on c-c, etc.): just landed on c-c
Risk to taking this patch (and alternatives if risky): just a pref change to the previous default so very safe.

Just to be clear - while this is probably the best fix (since the current default completely breaks S/MIME), it does have other impacts. For instance, we currently configure an LDAP address book that requires the AD CA certificate to trust. In the past this has been retrieved from the Windows certficate store. With this change it appears that the AD-CA certificate is no longer available and must be directly imported into TB.

Comment on attachment 9238899 [details]
Bug 1726442 - disable security.osclientcerts.autoload for Thunderbird by default since it doesn't work with S/MIME. r=benc

[Triage Comment]
Approved for esr91

Does this need to be relnoted, given comment 16?

I don't think so, it should be no different from 78 where certs from the OS were not used as well. This bug is reverting making them the default (which was a change in m-c).

Thunderbird 91.1.1:
https://hg.mozilla.org/releases/comm-esr91/rev/7d4f4aaf07aa