Przeszukaj pomoc

Unikaj oszustw związanych z pomocą.Nigdy nie będziemy prosić Cię o dzwonienie na numer telefonu, wysyłanie SMS-ów ani o udostępnianie danych osobowych. Zgłoś podejrzaną aktywność, korzystając z opcji „Zgłoś nadużycie”.

Więcej informacji

S/MIME Digital Signature Is Not Valid, but can decrypt and sometimes encrypt...

  • 3 odpowiedzi
  • 1 osoba ma ten problem
  • 1 wyświetlenie
  • Ostatnia odpowiedź od Matt

more options

In addendum to the below: I am now up to TB v 121.0.1 and still have this issue of untrusted S/MIME signatures from DoD sources. As I also have a DoD email, I can send myself test messages. If I send an unencrypted message from my DoD email in reply to to an S/MIME signed message from TB, I get the behavior described below in the original post, where my DoD S/MIME signature is not valid. If I reply to the same signed TB email with an encrypted message from my DoD email, TB decrypts the message but still says my signature is not valid. However, the "invalid" message is slightly different with an additional clue - the message states that "This message includes a digital signature, but the signature is invalid. The message was signed using an encryption strength that this version of your software does not support." See snips 4 (error)+ 5 (successful decryption) below. Is it possible that the newer signature certificates from DoD use an encryption strength that cannot be decrypted by TB, yet the message encryption works? Another clue is that it appears I can send encrypted emails to some DoD recipients (but not all) even if their signature is invalid.

Original Post: I have received a signed email from a DoD sender in TB v115.5.1. The S/MIME icon states the Digital Signature is Not Valid (png below), consequently, the cert was not imported into the TB Certificate Manager. I have updated the DoD Root Certificates, and ensured that the most commonly used DoD Root certs and Email certs have trust settings that identify web sites and mail users (add'l png examples). I cannot examine the cert I received in TB, although I seem to recall I could by clicking on the icon in earlier versions of TB.

How can I: 1) Identify the certificate authorities for the invalid cert to ensure they are trusted? 2) Examine and import the certificate from the user? This is not unique to a single user, it happens with DoD emails whose certs were not already in my Certificate Manager, and the organization I commonly communicate with is changing everyone's email, so everyone is getting new certs. This prevents me from sending encrypted emails to the recipients.

In addendum to the below: I am now up to TB v 121.0.1 and still have this issue of untrusted S/MIME signatures from DoD sources. As I also have a DoD email, I can send myself test messages. If I send an unencrypted message from my DoD email in reply to to an S/MIME signed message from TB, I get the behavior described below in the original post, where my DoD S/MIME signature is not valid. If I reply to the same signed TB email with an encrypted message from my DoD email, TB decrypts the message but still says my signature is not valid. However, the "invalid" message is slightly different with an additional clue - the message states that "This message includes a digital signature, but the signature is invalid. The message was signed using an encryption strength that this version of your software does not support." See snips 4 (error)+ 5 (successful decryption) below. Is it possible that the newer signature certificates from DoD use an encryption strength that cannot be decrypted by TB, yet the message encryption works? Another clue is that it appears I can send encrypted emails to some DoD recipients (but not all) even if their signature is invalid. Original Post: I have received a signed email from a DoD sender in TB v115.5.1. The S/MIME icon states the Digital Signature is Not Valid (png below), consequently, the cert was not imported into the TB Certificate Manager. I have updated the DoD Root Certificates, and ensured that the most commonly used DoD Root certs and Email certs have trust settings that identify web sites and mail users (add'l png examples). I cannot examine the cert I received in TB, although I seem to recall I could by clicking on the icon in earlier versions of TB. How can I: 1) Identify the certificate authorities for the invalid cert to ensure they are trusted? 2) Examine and import the certificate from the user? This is not unique to a single user, it happens with DoD emails whose certs were not already in my Certificate Manager, and the organization I commonly communicate with is changing everyone's email, so everyone is getting new certs. This prevents me from sending encrypted emails to the recipients.
Załączone zrzuty ekranu

Zmodyfikowany przez BarnRat1 w dniu

Wybrane rozwiązanie

After continued searching thru support articles, I found this: https://blog.thunderbird.net/2023/10/thunderbird-115-and-signatures-using..., which states: "As part of our continuing efforts to strengthen the security of Thunderbird, a change was made in version 115.0 that rejects the use of the SHA-1 algorithm in digital signatures of S/MIME emails." US Government ECA and CAC cards use SHA-1. The blog entry describes a workaround to re-enable SHA-1, which seems to have solved the problem.

Przeczytaj tę odpowiedź w całym kontekście 👍 0

Wszystkie odpowiedzi (3)

more options

Looks like this continues from https://support.mozilla.org/en-US/questions/1392971 although it appears you have all sorts of issues with s/mime https://support.mozilla.org/en-US/questions/1392971

Use the config editor to change the preference mailnews.display.show_all_body_parts_menu to true. Use the View entry on the menu bar to set message body as to "all body parts".

All the normally hidden email parts will now show up as attachments and you can open things like s/mime keys as attachments, without the benefit of a user interface.

1. The message is the signature is invalid, not untrusted. It is probably using some broken level of encryption that is decades old, or simply corrupted in transmission. It does happen. This image would indicate that old and/or broken encryption is the issue.

2. See the instructions to show the certificate as an attachment. How you go about reading the file, I have nothing to offer. If it is invalid as far as Thunderbird is concerned, it is not going to display it.

I really think you should be using the E2ee list you were pointed to here https://support.mozilla.org/en-US/questions/1392971#answer-1541253 that is where the encryption experts hang out.

more options

Wybrane rozwiązanie

After continued searching thru support articles, I found this: https://blog.thunderbird.net/2023/10/thunderbird-115-and-signatures-using..., which states: "As part of our continuing efforts to strengthen the security of Thunderbird, a change was made in version 115.0 that rejects the use of the SHA-1 algorithm in digital signatures of S/MIME emails." US Government ECA and CAC cards use SHA-1. The blog entry describes a workaround to re-enable SHA-1, which seems to have solved the problem.

more options

Who would have thought the US military had not kept with the times and would be using broken encryption for the nations secrets that has been around for more almost 30 years.

Wikpedia say on the topic "Since 2005, SHA-1 has not been considered secure against well-funded opponents; as of 2010 many organizations have recommended its replacement. NIST formally deprecated use of SHA-1 in 2011 and disallowed its use for digital signatures in 2013, and declared that it should be phased out by 2030". https://en.wikipedia.org/wiki/SHA-1

It would have never occurred to me that the US military would be so cavalier with national security. I guess that is why I am a farm hand and they are security professionals. Fancy using 1995 encryption. So old, most of your new recruits were not born when it came out. Especially when that same standard was updated to SHA-2 in 2004 and SHA-3 in 2015

Over a year ago the NIST said further use of SHA-1 was inadvisable. https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm