1719054 - S/MIME certificate chain doesn't work correctly in Thunderbird, since: ever.

Status: NEW

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

Description

[marportugues]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

Created a certificate chain in XCA free and open software, with CRL option, and it works great in Microsoft Windows, LibreOffice, XolidoSign and Adobe Acrobat Reader, but not in Thunderbird.

• I made the root certificate with "Certificate Sign, CRL Sign";

• The Intermediate certificate with: "Digital Signature, Certificate Sign, CRL Sign, E-mail Protection" and with the CRL and CRT information of the root;

• The user e-mail certificate with: Digital Signature, Key Encipherment, Data Encipherment, E-mail Protection, and the CRL and CRT of the Intermediate certificate.

• User e-mail digital certificate exported as "PKCS #12 (*.pfx)" "The certificate and the private key as encrypted PKCS #12 file", and then imported to the Thunderbird.

Actual results:

The certificates are put in "My certificates" just referring to the name on the certificate it self, and not the intermediate certificate (not in the authority list) or the Root digital certificate (that has been added manually to the "Authority" listing).

Even adding the intermediate certificate manually to the "Authority" listing won't make the digital certificate be list in in the "My certificates" below the intermediate certificate... doesn't matter if I had before or after is the same... is like it doesn't exists.

Expected results:

Since the user e-mail digital certificate refers to the intermediate certificate, and that one is properly sign by the Root certificate in the "Authority" listing already properly authorized, the Thunderbird should download it from the server (since the information is on the user certificate) and after making sure the intermediate is properly signed by the root it refers to, should add it and recognize the certificate chain, and list the user e-mail digital certificate, on "My certificates" under the immediately above intermediate digital certificate.
When opening the user e-mail digital certificate it should show all the tabs of the intermediates until the root certificate.

If several intermediates are found your may want to limit up to 6 intermediates or something like before not allowing that to be added properly to prevent "infinite" like intermediates and to be possible to list all of them on the Window tab.

In Microsoft Windows and Adobe Acrobat Reader, I only add the Root Digital Certificate to the Authority list, and then both Windows and Adobe can get the intermediate certificate and display the complete chain without any problem or error.

Comment 1

[Wayne Mery (:wsmwk)]

Does problem reproduce when using newer version (91 for example) with Help > Troubleshoot mode?

Comment 2

[marportugues]

Yes, the problem is still exactly the same at 91.3.0 (64-bit), no change in behaviour, even when in Troubleshoot mode.

Comment 3

[leszek.zablocki]

Attachment: windows_chain.png

Comment 4

[leszek.zablocki]

Attachment: CA_hiearchy_test.tar.gz

Comment 5

[leszek.zablocki]

I confirm this bug. The behavior of 128.0.1esr version is slightly different, but still Th. does not show the certificate chain. root and intermediate certificates places in the Authorities tab.

I created 3 levels of certificates based on this specification:

https://github.com/cabforum/smime/blob/main/SBR.md#7121-root-ca-certificates

Steps to reproduce:

• import .p12 file: private/user/credential_private_encrypted.p12
• change trust bits in root and intermediate certificates
• check EE certificate in "Your Certificates" tab

$ openssl verify -show_chain -CAfile "public_user/root.cer" -untrusted "public_user/intermediate.cer" "public_user/user.cer"

public_user/user.cer: OK
Chain:
depth=0:  (untrusted)
depth=1: CN=📍 TEST CMS/SMIME intermediate CA (untrusted)
depth=2: CN=📌 TEST CMS/SMIME root CA

similar:

bug#385601, bug#1741110, bug#146868, bug#540498, bug#543980, bug#545501, bug#1716998, bug#1753886, bug#956480, bug#1070094, bug#1535546, bug#1574325

psm:

bug#970196, bug#337785, bug#399643

Comment 6

[leszek.zablocki]

Attachment: th_cert_auth.png

Comment 7

[leszek.zablocki]

Attachment: th_cert_tab.png

Comment 8

[Kai Engert (:KaiE:)]

(In reply to leszek.zablocki from comment #5)

Your certificate "TEST CMS/SMIME intermediate CA" isn't a valid CA certificate.

It contains a "basic constraint extension" that says "this is NOT a CA".

Comment 9

[Kai Engert (:KaiE:)]

Expected results:
Since the user e-mail digital certificate refers to the intermediate certificate, and that one is properly sign by the Root certificate in the "Authority" listing already properly authorized, the Thunderbird should download it from the server (since the information is on the user certificate) and after making sure the intermediate is properly signed by the root it refers to, should add it and recognize the certificate chain, and list the user e-mail digital certificate, on "My certificates" under the immediately above intermediate digital certificate.

It's difficult to identify which problem you are reporting.

Is your complaint "Thunderbird does not automatically download intermediate CA certificates that are locally missing" ?

If I misunderstood, could you please try a shorter summary of the problem?

Comment 10

[leszek.zablocki]

Your certificate "TEST CMS/SMIME intermediate CA" isn't a valid CA certificate.

see: private/intermediate/cert_intermediate.crt.txt

        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign

I also checked cert_intermediate.crt through the certificate preview in Wnidows. And through certutil.exe. It's fine.

That's why I take dumps to see if something has gone wrong.

You can repeat the steps from the script, it will come out similar (with other keys, serial numbers).

Is your complaint "Thunderbird does not automatically download intermediate CA certificates that are locally missing" ?

It's all about certificate add-ons: subjectInfoAccess & authorityInfoAccess. In them you provide http links to the missing certificates. When you get a .p12 file (or signed email), for example, with a user and root cert (or only user cert), and the intermediate is missing, you can download it through the authorityInfoAccess / caIssuers extension in the user certificate. You can build a whole chain up. In the package I created, there are no such things, only the basics. see also

similar:

bug#1858275

Comment 11

[marportugues]

Attachment: smime certificate chain not_displayed when accessed through the message

In the current 128.0.1esr I can reproduce:
I enter in the signed message with S/MIME, and only the personal certificate will be displayed, without the tabs for the intermediate and the root certificates.
But when I go to the options > privacy & security > manage certificates, I can click the personal certificate and there it will display the personal certificate, and also the intermediate and the root certificates in the tabs.

Comment 12

[Kai Engert (:KaiE:)]

I have probably found the bug.

When certificate manager wants to build a chain, it only considers issuer CAs that are valid for TLS server authentication, and have the respective extended key usages.

In other words, if a CA certificate defines itself as being usable only for the S/MIME usages, then certificate manager might not consider that CA for the chain.

I think that instead, it should allow any extended key usage, and just rely on the certificate to look like a proper CA certificate.

I'm working on improvements for certificate viewer, as part of bug 1735832, and will suggest to fix this detail, too.

Comment 13

[leszek.zablocki]

I have prepared a test package and I think you can test the most important things that come from this ticket. The package includes 6 certificates: root, 4 x inter, leaf.

In the script, you can freely modify EKUs for intermediate certificates. Most interesting is the AIA extension starting from the EE certificate up to intermediate no1. To test this extension, set up a localhost server and put the files from the public_user folder (.cer files).

The scenario goes like this: you receive a signed email containing 1 leaf user certificate (signedData/signed_opaque_1_cert.eml), you do not have his certificate or intermediates. Th. in the background builds a path through this extension and in the message preview allows you to add missing certificates.

Scenario 2: you receive an email containing all the sender's certificates (signedData/signed_opaque_6_certs.eml), Th. in the preview of the signed message allows you to review them one by one, possibly adding a chain to the database.

To compare the behavior, open the above emails in Outlook and see what the program can do. (Yes, Outlook2021 can build chain via AIA)

I think that instead, it should allow any extended key usage, and just rely on the certificate to look like a proper CA certificate.

There are specific standards for S/MIME. Check which EKUs you need/can put in (intermediate) certificates designed for email encryption. I wrote about SMIME BRs above. Check this: rfc8550, or this.

I also went through the tickets and picked out a few bugs that are related to this one.

similar:

bug#399324, bug#245609, bug#542674, bug#1129540, bug#1911331

other NSS:

bug#1280076, bug#171969, bug#44838, bug#154246, bug#195842, bug#201143, bug#208286, bug#216832, bug#217270, bug#238146, bug#279845, bug#308859, bug#651585, bug#1603183, bug#396606, bug#476979, bug#958786, bug#422963, bug#1339322, bug#1738592, bug#465774, bug#1317657

other PSM:

bug#1591567, bug#488485, bug#188338, bug#236461, bug#357595, bug#360594, bug#953323, bug#968453, bug#994981, bug#1009102, bug#1123805, bug#1322751, bug#1427717, bug#1443554, bug#1449668, bug#1510003, bug#1512476, bug#1540639, bug#585352, bug#867478, bug#1847378, bug#733716

Comment 14

[leszek.zablocki]

Attachment: CA_hiearchy_test_6_level.tar.gz

Comment 15

[leszek.zablocki]

Attachment: thunderbird128_6_certs.png

Comment 16

[leszek.zablocki]

Attachment: outlook2021_6_certs.png

Comment 17

[leszek.zablocki]

Attachment: outlook2021_1_cert.png