1853475 - S/MIME: End-to-end encryption requires resolving certificate issues for [e-mail]

Status: UNCONFIRMED

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

Description

[gerrit.huebbers]

Steps to reproduce:

I wanted to reply to an S/MIME-signed, but unencrypted e-mail sent from [e-mail] to [e-mail] (I control both e-mail addresses, they are operated by different services). That e-mail address [e-mail] is well-set-up in Outlook, and I never have problems with sending valid signed/encrypted e-mails to other colleagues among our Outlook clients.

Actual results:

When I want to reply to that S/MIME signed e-mail from Thunderbird and select the option to encrypt my response e-mail, Thunderbird shows a yellow warning:

"End-to-end encryption requires resolving certificate issues for [e-mail]"

And this situation only allows to send the e-mail unencrypted.

Weirdly, while that [e-mail] S/MIME certificate is listed correctly in Thunderbird's Certificate Manager under "People", in that particular e-mail context back then clicking on S/MIME certificate information for this particular address when replying showed "Certificates:: Recipient: [e-mail] . Status: Not Found" (via e-mail dialog -> S/MIME > View Certificates of Recipients > pop-up "Message Security".)

After I sent a second e-mail from that Outlook e-mail account to my "Thunderbird" e-mail address [e-mail], but this time both S/MIME-signed and S/MIME-encrypted, the e-mail was sent with "From:" [e-mail] .

Notice the capital/uppercase Oooh in [e-mail] , versus previously lowercase [e-mail] . This may or may not be relevant for the initial failure.

This second time, it was possible to send the e-mail encrypted.

Since then, also e-mails sent from [e-mail] to lowercase [e-mail] get encrypted correctly, and no yellow warning/error message is shown.

While the encryption failure still was present (before receiving the second encrypted-and-signed e-mail), I tried as a work around to send an encrypted e-mail to [e-mail] by first querying the associated LDAP server for that e-mail address, as there its public X.509 certificate is published under the userCertificate;binary attribute.

(DFN LDAP:

Name: Name of the Address Book (e.g. ldap-DFN-PKI.)
Hostname: ldap.pca.dfn.de
Basis-DN: ou=DFN-PKI,o=DFN-Verein,c=de
Port-Nummer: 636
Bind-DN: keep empty
Check "Use secure connection (SSL)"
)

But using an LDAP search query for the e-mail address, selecting the found match for [e-mail] (in LDAP, it's listed lowercase, and lowercase it also is in the certificate itself) also didn't resolve the problem. Also, the Thunderbird LDAP interface doesn't seem to show any details regarding certificate availability for search results/matches.

Expected results:

Thunderbird should (easily) identify S/MIME certificates for encrypting when replying to an e-mail address signed with that particular S/MIME certificate.

LDAP S/MIME certificate lookup and usage should work, and it should be explicitly visible if a certificate is associated or not associated for a person found in LDAP.

Comment 1

[Kai Engert [:KaiE:]]

I cannot explain why the recipient certificate wasn't accepted for sending an encrypted email initially.
A certificate might be shown in cert manager, despite currently not (or no longer) being considered "valid".
I agree that our UI isn't great at showing exact reasons for rejecting certificates.
(I was trying a slight improvement in bug 1735832, but didn't yet have the time to complete it.)

I also cannot say whether the uppercase/lowercase O made any difference, it shouldn't.
And it's not obvious why receiving an encrypted email would enable you to send an encrypted reply, a signed S/MIME email including the certificate is usually expected to be sufficient.

There are so many details that could be wrong, it would require a very detailed analysis of all involved messages and certificates.

Comment 2

[Luca Edler]

Hi everyone,
I'm not sure if I should open a new issue or comment this one but for now I've chosen the latter.

Since when I upgraded two installations of Thunderbird to 115 on two fully different computers (one with Ubuntu 22.04, one with Windows 11) I got the message "End-to-end encryption requires resolving certificate issues for ..." when writing with encryption to a specific person.
The setup is

• TB 115.3.1
• self signed (and since years in production used) CA
• CA is installed under "Authorities" and trust is allowed to identify mail users
• multiple mailadresses with certificates that were signed by this CA

When I look under Certificate Manager -> People into the imported certificates signed by this CA, it's conspicuous, that in all but one mail/client-certificates under "Issuer name" the "Common Name" is marked and underlined and when you click on it, the CA-"tab" in the same window is being opened and shows the CA. In one of the certificates no CA-tab is shown and the Issuer Common Name field isn't marked or underlined and unclickable too. It seems that "because of reasons" Thunderbird doesnt recognize that the Issuer Common Name is related to the specific CA.

On one of the computer this behaviour happens related to only one specific client-mail-certificate/mail recipient. On the other computer two different certificates/recipients are affected.

The same configuration worked fine for months/years on each of the computers. This behaviour occurred after the 115 update.

Comment 3

[Kai Engert [:KaiE:]]

Luca, Thunderbird 115 changed a policy related to S/MIME. Signatures with SHA-1 are no longer accepted. Maybe your certificates involve the use of SHA-1 and are therefore treated by Thunderbird as unusable.

If viewing details of a cert in cert manager doesn't discover the issuer certificate and isn't offering showing the CA(s) in a separate tab, it very likely means that Thunderbird doesn't consider the certificate valid, or doesn't consider the issuer (CA) certificate valid.

If your certificates aren't using SHA-1, maybe you can provide a sample, we could try to look at it.

Comment 4

[Kai Engert [:KaiE:]]

Gerrit, if Thunderbird claims that no usable certificates are available, but you see some certificates, it usually means that Thunderbird considers those certificates as unusable, that it cannot validate them. For example, it could be because of an old algorithm that's no longer supported.

I believe upper-/lowercase differences in email addresses in certificates shouldn't matter, but if you can provide an example, I could test it.

Comment 5

[Luca Edler]

(In reply to Kai Engert (:KaiE:) from comment #3)

Luca, Thunderbird 115 changed a policy related to S/MIME. Signatures with SHA-1 are no longer accepted. Maybe your certificates involve the use of SHA-1 and are therefore treated by Thunderbird as unusable.

If viewing details of a cert in cert manager doesn't discover the issuer certificate and isn't offering showing the CA(s) in a separate tab, it very likely means that Thunderbird doesn't consider the certificate valid, or doesn't consider the issuer (CA) certificate valid.

If your certificates aren't using SHA-1, maybe you can provide a sample, we could try to look at it.

Good point and yes, it solved the problem!

I asked the person to send me a renewed certificate with signature algorithm "SHA-256 with RSA Encryption" instead of "SHA-1 with RSA Encryption" and now everything works again. Thank you for pointing that out!

Comment 6

[Luca Edler]

(In reply to Kai Engert (:KaiE:) from comment #4)

Gerrit, if Thunderbird claims that no usable certificates are available, but you see some certificates, it usually means that Thunderbird considers those certificates as unusable, that it cannot validate them. For example, it could be because of an old algorithm that's no longer supported.

I believe upper-/lowercase differences in email addresses in certificates shouldn't matter, but if you can provide an example, I could test it.

btw I tested the upper-lowercase thing. It doesn't matter. Even if the certificate just contains the lowercase mailadress (common name and altname), if I type the adress with partwise uppercase letters, thunderbird choses the "right" certificate and encrypted mailing works.

Which is interesting. Technically mailadresses are case-sensitive. So technically [e-mail], [e-mail] and [e-mail] are different addresses. When the certificate for "[e-mail]" is accepted when mailing to the adress "[e-mail]", it's technically wrong. This could be abused for e.g. phising.

Comment 7

[Kai Engert [:KaiE:]]

Can this bug be resolved, or is there any problem missing?

Comment 8

[Kai Engert [:KaiE:]]

While you're right that strictly speaking those are separate email addresses, I believe that in practice it's uncommon to use email addresses that only differ in the upper/lowercase of the local part, because it's very confusing.

Thunderbird ignores the difference in many places.