Windows 10 will reach EOS (end of support) on October 14, 2025. For more information, see this article.

Prohledat stránky podpory

Vyhněte se podvodům. Za účelem poskytnutí podpory vás nikdy nežádáme, abyste zavolali nebo poslali SMS na nějaké telefonní číslo nebo abyste sdělili své osobní údaje. Jakékoliv podezřelé chování nám prosím nahlaste pomocí odkazu „Nahlásit zneužití“.

Zjistit více

Comparison of signingTime to the RFC 5322 Date? (was: header openssl signed messages show verification error 1041)

  • 1 odpověď
  • 0 má tento problém
  • 18 zobrazení
  • Poslední odpověď od christ1

more options

Hallo,

(new information at the end)

in an effort to understand why one s/mime signed message I received could not be verified by Thunderbird (140.3.0esr (64-bit) on Ubuntu 24.04.3 LTS) (error 1041, "unknown problems with this digital signature"), but by all other clients I and others could check (including cli tools openssl, cmsutil), I did a few tests using my own certificate (using rsaEncryption, SHA256).

Inital observation: Messages signed with "openssl smime -sign -in msg.txt -to <email> -from <my-email> -subject test -signer mycert.pem -inkey mykey.pem -out signed.eml" and opened in Thunderbird showed error 1041. Any modifiers like -crlfeol, -text, -binary, ... did not make a difference.

Omitting signed attributes (-noattr) however helped. The signature was verified.

Further investigations now showed that the reason for that is a mismatch of the signing time in the signed attributes block with the RFC 5322 date in the header (or a missing date, which is the reason, the openssl smime output is rejected). If there is no match, Thunderbird shows a 1041 error (unknown problems with the signature).

However, I'm wondering whether such a test a reasonable. The standards don’t instruct MUAs to compare signingTime to the RFC 5322 Date. Flagging a mismatch is not required by spec and in my opinion adds little to no security value. The RFC date header can be easily modified and the signing time is openly readable.

Does anyone knows why it has been decided to test that?

Hallo, (new information at the end) in an effort to understand why one s/mime signed message I received could not be verified by Thunderbird (140.3.0esr (64-bit) on Ubuntu 24.04.3 LTS) (error 1041, "unknown problems with this digital signature"), but by all other clients I and others could check (including cli tools openssl, cmsutil), I did a few tests using my own certificate (using rsaEncryption, SHA256). Inital observation: Messages signed with "openssl smime -sign -in msg.txt -to <email> -from <my-email> -subject test -signer mycert.pem -inkey mykey.pem -out signed.eml" and opened in Thunderbird showed error 1041. Any modifiers like -crlfeol, -text, -binary, ... did not make a difference. Omitting signed attributes (-noattr) however helped. The signature was verified. Further investigations now showed that the reason for that is a mismatch of the signing time in the signed attributes block with the RFC 5322 date in the header (or a missing date, which is the reason, the openssl smime output is rejected). If there is no match, Thunderbird shows a 1041 error (unknown problems with the signature). However, I'm wondering whether such a test a reasonable. The standards don’t instruct MUAs to compare signingTime to the RFC 5322 Date. Flagging a mismatch is not required by spec and in my opinion adds little to no security value. The RFC date header can be easily modified and the signing time is openly readable. Does anyone knows why it has been decided to test that?

Upravil uživatel EinPhysiker dne

Všechny odpovědi (1)

more options

I'd suggest you ask at the Thunderbird e2ee mailing list on Topicbox. https://thunderbird.topicbox.com/groups/e2ee

Pomohla vám tato odpověď?

Položit dotaz

Pro přidání odpovědi se musíte přihlásit ke svému účtu. Pokud dosud nemáte účet, položte nový dotaz.