User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release) Build ID: 20140506004000 Steps to reproduce: Thunderbird/Earlybird 31.0a2 (2014-05-06) Sending email signed with valid (signed by trusted CA) S/MIME certificate. Actual results: Thunderbird reports signature as invalid. Expected results: Signature valid, no error message.

This might be related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741147#10 (abstract: correctly signed messages created using mutt would be marked as invalid because the checksum was based on SHA256 instead of SHA1 by default)

peter: can you attach a sample (save as .eml)? without that, there's not much to go on here

I've attached a zip containing two sample messages created using mutt (with and without the aforementioned workaround). Both signatures are considered valid, e.g., in mutt itself. Kind regards, Markus

I have the same problem with a message generated by mutt. As in the message in the attached file the header says: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="some boundary". This means that mutt generates a message in which a header contradicts the hash algorithm used for generating the signature!

Does your issue reproduce with 38 https://www.mozilla.org/en-US/thunderbird/all-beta.html ?

I was unable to use the prebuilt Linux binary on my Ubuntu 14.04.2 LTS system, so I rebuilt it from source yesterday following the "Simple Thunderbird build" instructions. The issue /is/ still reproducible using "Open saved message" with the attached invalid example message (screenshot attached).

(In reply to Markus Ueberall from comment #7) > Created attachment 8612099 [details] > screenshot showing the problem using the 2015-05-28 daily build I can confirm the Problem with thunderbird 38.3.0 (on fedora 23). I can also confirm the workaround for mutt signatures to add -md SHA1 to the smime_sign openssl command. At the error message is wrong. It indicates that the message content does not match the signature. But the signature is valid (as manual openssl commands prove, and also mutt verifies the signature ok). Thanks for the workaround, Markus!