1880585 - Thunderbird S/MIME encryption key not detected

Status: RESOLVED INVALID

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

Description

[agowa]

Attachment: Screenshot_20240216_022105.png

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

Steps to reproduce:

1. Import S/MIME certificate for [e-mail] from https://cdn.posteo.de/public-keys/[e-mail]
2. Try to write an encrypted message to [e-mail]

Actual results:

Thunderbird claiming [e-mail] does not have a certificate.

Expected results:

Thunderbird should have seen that a certificate for [e-mail] is in it's own internal trust store.

Comment 1

[agowa]

Attachment: [e-mail]

s/mime certificate I imported.

Comment 2

[agowa]

Attachment: S/MIME certificate in certificate manager

Comment 3

[agowa]

I now got a signed reply from [e-mail] and only now Thunderbird is able to use the certificate. When viewing the certificate from that reply mail and comparing it with the imported one a parsing difference is visible. I don't see any differences within the Certificate Manager though.

For the imported one Thunderbird resolves the entire chain and shows three tabs.
For the one from the signature it doesn't it only shows the certificate itself WITHOUT trying to resolve the chain. It's however the same certificate.

Also within the Issuer Name section for the imported one the Common Name is clickable where for the signature one it isn't.

Comment 4

[agowa]

Attachment: Certificate after import (left), certificate from signature (right)

Comment 5

[Kai Engert [:KaiE:]]

Thunderbird supports S/MIME certificates that can be verified as having been issued by a Certificate Authority that is configured in Thunderbird as being trusted for email usage.

In order to perform this verification, it is necessary that Thunderbird can find a "chain of trust" from a certificate to the corresponding "root" CA certificate.

It does so by looking at the "issuer" field of a certificate, and then it tries to find a certificate that has that name in its "subject" field.

It is a common practice that CAs don't use their root certificate to directly sign the certificates they issue. Rather, they typically use "intermediate CA certificates".

Such intermediate CA certificates are not included with Thunderbird. It is necessary to obtain them.

In your particular scenario, I have downloaded the latest copy from the link you had provided.

That download includes only the end entity certificate. It does NOT contain the required intermediate CA certificate.
I can confirm that importing this certificate isn't sufficient for using it, and can confirm what you saw.

I see that the "subject" of the intermediate CA certificate is "Certum SMIME RSA CA".

I went to the web page https://crt.sh which is a site that attempts to collect issues certificates.
By searching for that string, I found: https://crt.sh/?id=10256433837

On that page, in the lower left, there is "Download Certificate: PEM".

I clicked the "PEM" link, saved the file.
Then I opened Thunderbird certificate manager, click the "authorities" tab, and imported that file.
When prompted, I did "NOT" check any of the checkboxes. It's unnecessary.

After I've done so, the posteo certificate is usable.

Comment 6

[Kai Engert [:KaiE:]]

The reason why it worked after you have received the certificate by email:
It's common that email programs include all the necessary intermediate CA certifiates, together with the end-entity certificate.

When Thunderbird received that email, it automatically imported both the end entity and the intermediate CA certificates.
From that point on, the intermediate CA was cached, and Thunderbird was able to verify and use the end entity certificate.

Comment 7

[Kai Engert [:KaiE:]]

This is NOT a bug in Thunderbird.

The web page that told you to download the certificate should have explained that you also must download and import the intermediate CA certificate.

Comment 8

[Kai Engert [:KaiE:]]

It would be great if my explanations could be turned into a support article!

Comment 9

[Roland Tanglao :rolandtb :adobo :sinigang :mapotofu previous tour of duty profile: https://bugzilla.mozilla.org/user_profile?login=rtanglao%40mozilla.com]

:KaiE: isn't this already covered by the following from the SUMO KB Article Instructions for obtaining a personal S/MIME certificate by creating a CSR::Import the certificate into Certificate Manager and back it up :

If your CA offered you additional intermediate (or subordinate) certificates to download, click the Authorities tab, click the Import button, and import them one after the other. Note that when importing a CA in this place, Thunderbird will offer you to mark a CA as trusted, and also warn you about the associated risks. Please leave the checkboxes unchecked, do NOT check them. Confirm by clicking OK which will import the intermediate CA certificate without explicitly trusting it. (Explanation: It isn't necessary to assign explicit trust to an intermediate certificate, as it is used only to discover a pathway from a person's certificate to a trusted root CA certificate.)

Comment 10

[Kai Engert [:KaiE:]]

No.

What you cited is for a user who obtained their own personal certificate from a CA, and makes sure they import the intermediate CA certificates for their own cert.

In the cited scenario, your own CA should have given you clear instructions what to do.

In the scenario from this bug, the difference is: You are downloading the certificate of another person, and you don't have complete instructions. Comment 5 explains how someone can help themselves, by looking up which intermediates they need, and from where they could be obtained.

Comment 11

[agowa]

Why does Thunderbird have to enforce a chain of trust for OUTGOING mails? At most that should be a warning. The intermediate isn't needed for encrypting the mail.

Also do you really want to import and trust my own root CA just so that you can send me an encrypted mail?

I think there needs to be some discussion about this design decision. In this case the S/MIME certificate is publicly trusted, but I know (from dealing with my customers at work) that there are a lot more that use internal CAs that you don't want to trust for all domains unconditionally.

I would suggest to just use whatever Certificate thunderbird has for OUTGOING mail even if the chain of trust is incomplete.
AND to allow some kind of partitioning of the trust store to allow certain CAs to be used for validating certain domains or email addresses ONLY and be considered "non existent" for all others.

Example, if "BMW internal enterprise CA" (or whatever) issued the certificate "[e-mail]" then I want to trust it. But if it issued "[e-mail]" I don't...

Comment 12

[Kai Engert [:KaiE:]]

We should not encrypt to unauthenticated keys.

You don't want to risk that you are encrypting to a fake MITM key. When you want to use encryption, the assumption is that you want end-to-end confidentiality between yourself and the recipient.

Without authenticating the recipient key, you don't know whether you are encrypting to the intended recipient, or to an attacker.

That's why Thunderbird requires that the recipient's S/MIME encryption certificate can be verified as having been issued by one of the pre-trusted CAs.

Comment 13

[agowa]

Still better than not encrypting at all.

Comment 14

[Magnus Melin [:mkmelin]]

Not if the desire is secure communication. Yes there's the off-chance that you only care about hiding the content. but we can't know that. And we can't really expect users to understand the nuances.

Comment 15

[agowa]

Yea, no. If the goal was secure communication one wouldn't have to trust random root CAs of recipients without any ability to scope them to individual domains or users. That is literally the opposite of secure communication then...