S/MIME certificate problems: TB does not recognize recipient certificate & does not send encrypted message (ignores manually imported user certificates?)
Categories
(MailNews Core :: Security: S/MIME, defect)
Tracking
(Not tracked)
People
(Reporter: volleyball, Unassigned)
Details
Steps to reproduce:
I am trying to send an S/MIME-encrypted mail to a recipient of which I have imported their new public S/MIME certificate (and deleted the old one).
I never received an e-mail from that address but had used their (previously imported) prior certificate successfully to send encrypted mails to that address.
Actual results:
Having installed their new certificate now, TB shows a yellow message bar at the bottom of the compose window when trying to prepare a new e-mail to that address. The error message is (translated from German): End-to-end encryption requires solving certificate problems for <mailaddress>. The only button next to this messge is "do not encrypt" but no hint is given otherwise what went wrong with these certificates.
Expected results:
TB matches the recipient address with the imported S/mime certificate of the recipient and allows sending an encrypted e-mail.
Addition: Sending encrypted mails to users who had sent their own certificate in previous e-mails works flawlessly.
Addition 2: What does not work either is saving a message as a draft in the case above (message "Your message cannot be saved as a draft. You opted to encrypt this message but the application did not find an encryption certificate for <mailaddress>").
So my assumption is that the current TB version does only look up certificates that have been received in prior e-mails but ignores manually imported user certificates.
|
||
Updated•2 years ago
|
Is there anything else I can help with and/or debug this situation?
|
||
Comment 3•1 year ago
|
||
Sorry for the delay.
Are you sure you have imported the necessary intermediate CA certificates, that are necessary for the certificate verification code verify that it is legitimate cert issued by a pre-trusted CA?
If you want, you could send the certificate that you are trying to use. Either by attaching it here, or by sending it to me by email (mention the bug number please).
(In reply to Kai Engert [:KaiE:] from comment #3)
Sorry for the delay.
Are you sure you have imported the necessary intermediate CA certificates, that are necessary for the certificate verification code verify that it is legitimate cert issued by a pre-trusted CA?
If you want, you could send the certificate that you are trying to use. Either by attaching it here, or by sending it to me by email (mention the bug number please).
Hi Kai,
I sent a short mail that links to the corresponding certficate.
B
|
|
||
Comment 5•1 year ago
|
||
It's exactly as I guessed.
The certificate file you downloaded contains only the end-entity cert, not the intermediate CA certificates required for chain building.
The publisher should create a combined certificate file that includes the required intermediates.
I cannot find the intermediate on the https://crt.sh/ web site.
|
|
||
Updated•1 year ago
|
Ok, looks like I have overlooked this problem. When handpicking the intermediate certificate, the error is gone. I get the idea why TB does not want to trust this particular certificate out of the box because of a missing chain, but...
- If I manually import a certificate (i.e. because I exchanged the certificate / public key with the corresponding person through a secure channel), there should be an option to enable encryption (i.e., a flag "trust this user/certificate) no matter if it is signed by a (chain of) trusted root certificate(s) or not.
- Other clients seem less picky about this and let me encrypt messages to the user/owner of that certificate (probably not a good idea from a security perspective but pragmatic)
- There should be an understandable error message explaining WHY by default I cannot use the stored certificate to send an encrypted message. Just stating E2E encryption requires solving certificate problems is not a usable error message and violates common interface design rules (see for example https://www.cs.umd.edu/users/ben/goldenrules.html rule 5 or 3). Proposal: "E-Mails to this address cannot be encrypted because the certificate for this recipient is not trusted. Common reasons for this are that a) the certificate is not signed by a trusted CA or b) the certificate was signed by an intermediate CA but this intermediate certificate is missing." Or create a help article and link to it from within TB.
- For more experienced users, there should be some form of easy debugging where issues like this can be traced down without requiring external support.
... in addition, as I stumbled across your comments on https://thunderbird.topicbox.com/groups/enterprise/Tb2ee628538c9f37d-M57d985bd07e9deeb215d5edb/strange-s-mime-problem, I digged a bit deeper into the issue of intermediate certificates.
Within 5 minutes, I did not find any RFC explaining the actual process of retrieving intermediate certificates, but issuers like Swissign claim (https://www.swisssign.com/en/support/ca-prod/new-roots-2021) that client could automatically download required intermediate certificates. As it seems right now, TB is not doing this, correct? Was this ever discussed before?
|
|
||
Comment 8•1 year ago
|
||
Yes as of today Thunderbird doesn't automatically fetch the missing CA certificates, even if a certificate contains a link to the intermediate in an AIA certificate extension.
Description
•