Unable to encrypt messages / rcpt cert seems not to be validated properly
Categories
(MailNews Core :: Security: S/MIME, defect)
Tracking
(Not tracked)
People
(Reporter: github, Unassigned)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
Steps to reproduce:
Setup S/MIME signer certificate for current account
Compose a message to a recipient having a valid certificate listed in "Peoples"
Choose to sign and encrypt (compose window suggests "S/MIME e2e encryption is possible" in window status bar
I have validated that the rcpt certificate has a full chain and the signer CA has the "identify email users" checkbox set
Actual results:
When trying to send the message, a popup message occurs:
Unable to encrypt message. Please check that you have a valid email certificate for each recipient. Please check that the certificates specified in Mail & Newsgroups Account Settings for this mail account are valid and trusted for mail.
Unexpected: Clicking on "View certificates of rcpt" shows the email adress and "valid" but the validity fields are empty (see attached image).
I can reproduce this with several rcpt addresses from different CAs using different algorithms.
Expected results:
Send SMIME encrypted message
I guess I found the root cause of the main problem: The certificate of the account I used for the tests was recently renewed and is now an ECC certificate which is obviously not usable for encryption. As I have set up TB to store a copy of all outgoing messages in the Sent folder, it tries to encrypt the self-owned copy with the ECC certificate which is not possible.
So this bug report reduces to several UI/usability issues:
a) The empty validity columns in the "Recipients Certificates" popup as shown in the attached screenshot
b) A certificate that is not usable for encryption either by algorithm or by the internal trust setting is shown as valid certificate in the "Recipients Certificates" popup
c) Encryption is "suggested" by the banner in lower status bar even if the rcpt certificate does not qualify for encryption
d) There is no mention at all that the sender certificate must also allow encryption so it might be useful to also show this in the popup (its obvious somehow but really hard to spot)
Description
•