840595 - Can't import self-signed certificates nor encrypt using them

Status: RESOLVED DUPLICATE of bug 650355

(Thunderbird :: Security, defect)

Description

[dcmay]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20130107124423

Steps to reproduce:

SUMMARY

Handling self-signed certificates appears to be mostly broken in Tbird 17 through 19. Self-signed CA & e-mail certs that were sucessfully imported and used under Tbird 10 ESR can no longer be used to encrypt messages after upgrading to Tbird 17 ESR, but can be used to decrypt (view) existing and newly received encrypted messages from those same users. The CA cert can be imported in Tbird 17, but user certs that import successfully under Tbird 10 fail to import into a fresh profile uner Tbird 17.

BACKGROUND

Create a self-signed CA certificate. (I used PHPki, wraps openssl 0.9.8k, on Ubuntu Lucid.) Create user certificates using the self-signed CA certificate: both private and public keys. Certificates are proven to work (demonstrated to support S/MIME encrypted and signed mail, for both receiving and sending) using Thunderbird 10ESR, MS Outlook 2007 & 2010, and Firefox 18 (CA cert for websites).

Set a master password and enable FIPS. (Tbird *should* prompt for a password if this step isn't performed).

SCENARIO 1

Install Thunderbird 17.0.2ESR or 18.0.

Successfully import CA certificate under "Authorities", and edit trust settings to identify websites, mail users and software makers.

Successfully import my private key under "Your Certificates".

Attempt to import a different users self-signed CA issued certificate.

SCENARIO 2

Install Thunderbird 10.0.12ESR. 

Successfully import CA certificate under "Authorities", and edit trust settings to identify websites, mail users and software makers.

Successfully import my private key under "Your Certificates".

Successfully import a different user's self-signed CA issued certificate.

Receive an encrypted e-mail from that same different user, and successfully decrypt it and view its contents.

Select Message / Reply.  Select Options / Encrypt This Message. 
  a) Select File / Save As / Draft.
  b) Select File / Send Now.


Actual results:

SCENARIO 1

Message box is displayed containing: "This certificate can't be verified and will not be imported. The certificate issuer might be unknown or untrusted, the certificate might have expired or been revoked, or the certificate might not have been approved."

SCENARIO 2

a) Message box is displayed containing: "Unable to save your message as draft. You specified encryption for this message, but the application failed to find an encryption certificate for [e-mail]".

b) Message box is displayed containing: "Sending of message failed. You specified encryption for this message, but the application failed to find an encryption certificate for [e-mail]".


Expected results:

Same behavior as Tbird 10:

SCENARIO 1

The certificate should be successfully imported, and be usable for sending e-mails

SCENARIO 2

a) The message should be saved as a draft in the user's specified drafts folder.

b) Tbird should connect to the outgoing SMTP server and attempt to send the message.

The only workaround I know for this problem is to revert to Tbird 10 ESR. Certificates can then be installed. After re-installing Tbird 17, new incoming and existing e-mail can be decrypted (but new e-mail cannot be encrypted).

Comment 1

[Kaspar]

(In reply to dcmay from comment #0)
> Create a self-signed CA certificate. (I used PHPki, wraps openssl 0.9.8k, on
> Ubuntu Lucid.)

http://www.mozilla.org/en-US/thunderbird/16.0/releasenotes/

http://sourceforge.net/tracker/?func=detail&aid=3464359&group_id=75973&atid=545639

Comment 2

[dcmay]

Kaspar,

Thanks for pointing out bug 650355: I'd have never found that.

I've confirmed that changing security.enable_md5_signatures=true fixes the error message, and that new encrypted e-mails can now be exchanged; however, Thunderbird 17 appears to be performing differently than the behavior described for bug 650355.

Root certificates reportedly would not be affected by this switch, only intermediates.

In enabling this switch, it appears to force acceptance of ALL questionable intermediate certificates in order to use a self-signed certificate that has been explicitly trusted.

That seems wrong and bad.

Dietmar

---

Comment 4 Kathleen Wilson 2011-04-25 10:07:24 PDT

As per https://wiki.mozilla.org/CA:MD5and1024
"The MD5 root certificates don’t necessarily need to be removed from NSS, because the signatures of root certificates are not validated (roots are self-signed)."

---

Comment 5 Brian Smith (:bsmith) 2011-04-25 17:43:35 PDT

(In reply to comment #3)
> Are there still any such MD based roots in NSS? I believe most have been
> removed already, no?

Regardless, we would still allow MD5-based roots and self-signed certs (?) that are in the user's certificate database to work.

---

Comment 24 Daniel Veditz [:dveditz] 2012-03-26 11:40:06 PDT

> (In reply to Varga Viktor from comment #19)
> > I am at the Netlock, and I will be sure, that the old MD5 roots will be not
> > disabled after when this feature will be included into the Firefox.

Roots are trusted because they are in the trusted list, their signature hash algorithm is irrelevant. Intermediates with MD5 will get blocked, though, same as EE certs.

Comment 3

[dcmay]

The self signed CA has an SHA1 fingerprint as well as an MD5 fingerprint. I'm not familiar with many of the details of TB certificate handling. Bug 650355 doesn't explicitly state the behavior in this case; but a couple of comments leads me to question whether a certificate with both MD5 and SHA1 fingerprints should be accepted by TB.

Finally, just a reminder that Firefox 17esr accepts the root certificate as identifying servers; and FF17esr quietly accepts (without warning or error) the server certificate when browsing an https server using a certificate issued by this self-signed CA. I've confirmed that security.enable_md5_signatures=false in FF17esr. Shouldn't TB17esr behavior be similar?

---

Comment 23 Varga Viktor 2012-03-26 10:39:29 PDT

I checked the mentioned settings up here, and I went to check one thing quickly. 
1. MD5 root - SHA1 EE certificate - working as expected.
Another case I should check if the chain has somewhere an MD5, not on the top, but others are SHA1. (Tomorrow I will check it.)

---

Comment 54 Brian Smith (:bsmith) 2012-10-09 11:47:41 PDT

(In reply to Coyote from comment #53)
> In FF 16, the about:config says: security.ssl3.rsa_rc4_128_md5;true
> Is this correct?

The SSL cipher suites that use MD5 actually use HMAC-MD5 and/or MD5 in conjunction with SHA-1. Consequently, they are considered safe, unlike the plain MD5 hashes used in signatures.

Comment 4

[Kaspar]

Bug 650355 (which is a spin-off of bug 590364, to be precise) is about disabling MD5 "as a hash algorithm for intermediate and end-entity certificates" (bug 590364 comment 0).

What you have reported in the description of this bug is exactly what the expected behavior for Thunderbird 16 is: it refuses to import/validate end-entity certificate with MD5-based signatures.

Fingerprints are completely unrelated to the signature algorithm used in the certificate. The signature algorithm is shown in the Certficate Viewer's "Details" tab, by looking at the "Certificate Signature Algorithm" field. With Thunderbird 16 and later, all intermediate and end-entity certs with "PKCS #1 MD5 With RSA Encryption" are rejected by default. The proper solution is not to switch security.enable_md5_signatures to true, but to get rid of MD5-based certificates.

Firefox has traditionally allowed to skip SSL server certificate validation errors (versions up to 2.0) or to add exceptions (releases 3.0 and later), and continues to allow this for certificates with MD5-based signatures. S/MIME-based message signing and encryption in Thunderbird has nothing to do with SSL server certificates, however, and allowing similar exceptions for S/MIME certificates would be a pretty bad idea (MD5 has been deprecated years ago, and http://www.win.tue.nl/hashclash/rogue-ca/ was meant to really, really make it go away - that was about 4 years ago).

Do *not* change the status of this bug (reopen or such) unless you can provide full details of a test case (including certificates, mail message files etc.) where Thunderbird is not behaving as expected.

Comment 5

[dcmay]

Thanks for the detail: it's helped me to understand the issue.

As a note, "end-entity" appears nowhere (that Firefox can find) in bug 650335: only the cryptic "EE" (with obvious meaning to those at Mozilla and certificate issuers), and one reference to "end certificate".

My understanding of the problem (for those who, like me, aren't so deeply immersed in cryptography and certification chains) is that the *user* certificate (ie. the one with *my* e-mail address, used to sign and/or encrypt the e-mail message) is MD5 signed. The fact that the root CA certificate is MD5 signed is irrelevant here, because Thunderbird will accept an MD5 root CA certificate (whether self-signed or issued), but NOT an MD5 *intermediate* CA certificate. The solution is to re-issue the user certificates for each person's e-mail address (presumably revoking the older ones once the new are installed?) with ones having SHA1 signatures. It *would* be a good idea to re-issue the self-signed root CA, but not required. Any MD5 server certificates issues by the (original) MD5 self-signed root CA are still being accepted by Firefox.