User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.103 Safari/537.36 Steps to reproduce: updated my thunderbird beta and dev - since then no SSL/TLS, STARTTLS connection works (rootCA and server certificate is known) dovecot ssl_ca = </etc/ssl/cacert.crt ssl_cert = </etc/ssl/mail.pem ssl_cipher_list = HIGH:MEDIUM ssl_key = </etc/ssl/mail.pem security.tls.version.min = 0/1/2/3 (nothing works) ~: openssl s_client -connect alexdpsg.net:993 CONNECTED(00000003) depth=1 C = DE, ST = Germany, L = Cologne, O = Privat, OU = ALEX_DPSG, CN = alexdpsg.net, emailAddress = info@alexdpsg.net verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/C=DE/ST=Germany/O=Privat/OU=ALEX_DPSG/CN=*.alexdpsg.net/emailAddress=info@alexdpsg.net i:/C=DE/ST=Germany/L=Cologne/O=Privat/OU=ALEX_DPSG/CN=alexdpsg.net/emailAddress=info@alexdpsg.net 1 s:/C=DE/ST=Germany/L=Cologne/O=Privat/OU=ALEX_DPSG/CN=alexdpsg.net/emailAddress=info@alexdpsg.net i:/C=DE/ST=Germany/L=Cologne/O=Privat/OU=ALEX_DPSG/CN=alexdpsg.net/emailAddress=info@alexdpsg.net --- Server certificate -----BEGIN CERTIFICATE----- MIIFBTCCA+2gAwIBAgIBCDANBgkqhkiG9w0BAQ0FADCBjzELMAkGA1UEBhMCREUx EDAOBgNVBAgTB0dlcm1hbnkxEDAOBgNVBAcTB0NvbG9nbmUxDzANBgNVBAoTBlBy aXZhdDESMBAGA1UECxQJQUxFWF9EUFNHMRUwEwYDVQQDEwxhbGV4ZHBzZy5uZXQx IDAeBgkqhkiG9w0BCQEWEWluZm9AYWxleGRwc2cubmV0MB4XDTE0MDIwNTE0NDYw OVoXDTIzMTIxNTE0NDYwOVowfzELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0dlcm1h bnkxDzANBgNVBAoTBlByaXZhdDESMBAGA1UECxQJQUxFWF9EUFNHMRcwFQYDVQQD FA4qLmFsZXhkcHNnLm5ldDEgMB4GCSqGSIb3DQEJARYRaW5mb0BhbGV4ZHBzZy5u ZXQwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDVvYthc7b7UhvQJ9zg XvFDlHqnLx0UDlukQdfDsN0jHjDP7JEZVuKn3k3fnfnxmNIR/BdATAVy+a+BlON/ 17ZosjpIhVDHGxVzntICftNkW61sao38CeR3BQf8opzbvK11cz01XJe7fGiB+ky6 GDYCsV+ALpuJW3Qx7KrgyjqhHrDtRHoE8xsoURcdBE++RqhckwIJCtwLF/Zlj1Zw BlTcsZLNpoxALfGw49GE1TSuGHLReh8MvfKXGig4s69/NsmJVTa/pHzrgbm2JENQ z/n2flcPDVbSM5mnIDpJ3DAfC5+SH1At7vUqoVx5WOGmpqysIR8T9lOBc4ESm40P Z6o6Lj7NSrp8SKJsx5N3nDawPxQZj1n89xp3yQd7cyZ58c0q+zx45mTkp1TBw66e Qzg29VSeq57cqP4sxRkiV6U4e+q+T9gmiFyBe2/ZERzkBKcR9UxTJU6Z1EXClJeK bj9H+bdSCvDUALb1KwZuo4bRl9S8Va9ekprBm6hUGsopKop3zWJEmyBtdOP05HdO ++AWKtqWqFklmF7HqP/sT5GH+xnftnIb5wOuB56WhtkBWnhI7hQbvVi9h5ZT8hJj FCJTBr/eVLIyeZw1gPFD8SsdQIPPHad2YivLnKJ6/Bfn03md6LLmMI+mlwhCviUT KkYyUtZhFHhukkQ9InjH1yBsVQIDAQABo3sweTAJBgNVHRMEAjAAMCwGCWCGSAGG +EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU uGORmIiATfOfs0tIpmQHmDDQjkYwHwYDVR0jBBgwFoAUz+2ObJIJTTpIcvh2vBAQ AOwLpmswDQYJKoZIhvcNAQENBQADggEBAB/LPAFQR0c6e9NWmY4uKdAU49o9g6O1 /wNXLAqQSzbcHUCnOGTGSFSbmymETZ85/noPoHGX7nZV8RalvLmNsxQgE30rx1/z krcweEGeP7c7QCjX53zL/FgUMFF76VAzVCD76cLz4LVxvjyOA7E4XXbPpd30lC5R z3TecBsQu3Gmi8cAEuCXKMHfZ6e86KcnOwbaCCXb7KPkw8NDU9q8v4R8xFL3jk1u mL+Jz6x/4D0zJQLNl28x6DguOIxfLUzw0JXltqLqFuoav+1U9EmzxhkwxKFxbcfM YUy6dX7oPlmDTaUzIYYhC8AlblUUtp0kb+ruWspfpby1RaFADooLYvA= -----END CERTIFICATE----- subject=/C=DE/ST=Germany/O=Privat/OU=ALEX_DPSG/CN=*.alexdpsg.net/emailAddress=info@alexdpsg.net issuer=/C=DE/ST=Germany/L=Cologne/O=Privat/OU=ALEX_DPSG/CN=alexdpsg.net/emailAddress=info@alexdpsg.net --- No client certificate CA names sent --- SSL handshake has read 3576 bytes and written 507 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384 Server public key is 4096 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : DHE-RSA-AES256-GCM-SHA384 Session-ID: C78A16A58D096C270EF45713F645CF1AE90B706409CFBE1E12E8CF1BADD73FE8 Session-ID-ctx: Master-Key: 41725F3C58D24EE8F9D33BE4031E61379ED2C241464F93073A92F4C24C9369A8BEBA25CA29EFF3CDD880E5AE3CDBBA2D Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - dc 01 3d 5b cc fe ab e4-2c 1b 76 0b 8c d7 b4 c1 ..=[....,.v..... 0010 - 94 59 88 26 7f 09 82 14-42 08 d5 d9 95 0c 0d 1d .Y.&....B....... 0020 - 84 79 f5 11 55 3b a5 d4-6c 34 21 a9 31 41 36 a4 .y..U;..l4!.1A6. 0030 - aa c7 89 ce 5f 38 61 48-58 a3 6d 72 ef e0 6b 83 ...._8aHX.mr..k. 0040 - 44 b0 7b b9 da 0c 33 64-d6 83 65 1f 5e 26 29 57 D.{...3d..e.^&)W 0050 - 49 11 6c 26 51 98 bf a8-86 20 e2 9d fb 81 96 2c I.l&Q.... ....., 0060 - 4f 6e c7 39 a2 b3 17 0a-88 46 8e d3 60 91 92 00 On.9.....F..`... 0070 - 60 97 d8 64 6c ce 14 f3-22 49 46 af 21 97 f3 c4 `..dl..."IF.!... 0080 - 1d a2 97 f2 1b a0 ed af-91 39 58 57 37 05 98 dd .........9XW7... 0090 - e6 8a 4f b2 2a 9b c1 df-fc 72 4c a5 29 c2 24 b1 ..O.*....rL.).$. Start Time: 1404899140 Timeout : 300 (sec) Verify return code: 19 (self signed certificate in certificate chain) --- * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN] Dovecot ready. Actual results: on the server side "TLS: SSL_read() failed: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate: SSL alert number 42" actual stable works fine, TB 31, 33 and trunk are broken -

Thanks. If you find more regressive bugs in version 31 beta, please mark them blocking bug 1008543.

What are the server names and ports that should be used? (So we can test.)

you can try STARTTLS or SSL/TLS on mail.alexdpsg.net (:143 or :993). CA Cert (yes, self-signed http://daten.alexdpsg.net/alexdpsg_net.crt, but i trust myself :) )

good: 2014-04-26 broken: 2014-04-28 ... so this should be fallout from bug 915930. I set up an account for that server (put stmp.gmail.com as smtp to get through). Previously you get the add certificate exception when i later try to connect by clicking on inbox, now nothing at all.

Thanks for filing this bug. It appears to be the same issue as bug 1034124. The certificate at http://daten.alexdpsg.net/alexdpsg_net.crt has a basicConstraints extension with the value cA: TRUE. We stopped allowing CA certificates to act as end-entity certificates. That certificate should be regenerated without the basicConstraints extension (for example, `openssl req -new -x509 -nodes -out server.crt -keyout server.key -extensions usr_cert' might work with a default openssl configuration). (The reason the certificate override dialog didn't come up is that this error is not overridable.)

ehm WTF? if you connect to my mailserver you get a proper Cert CHAIN! and of course http://daten.alexdpsg.net/alexdpsg_net.crt contains the value CA:TRUE ( because it is one :) )

I see - I misunderstood your setup. I can reproduce the problem on Daily (33) but not Beta (31). Is this the behavior you're seeing? If so, the problem is that Thunderbird hasn't been updated to deal with the removal of the nsIRecentBadCerts service (bug 940506).

See also bug 1025332 comment 11. In the meantime, what you can do to work around this is use the certificate manager (Preferences -> Advanced -> View Certificates) to import and trust your root certificate (Authorities -> Import).

I had (manually) imported the cert http://daten.alexdpsg.net/alexdpsg_net.crt (to under Servers) to test and that got me the regression range with symptom "no exception dialog for trying to connect." When I deleted the imported cert, I can connect, and get the exception dialog using 31 and adding it works. On 33 I get the dialog but it can't add exception because "Unable to obtain identification status for the given site" (probably bug 940506 adaption needed yes) So maybe there are more than one issue here? I can reproduce it again if I delete the cert. (I note the one added via dialog is with *.alexdpsg.net, the other without *.

(In reply to Magnus Melin from comment #9) > I had (manually) imported the cert > http://daten.alexdpsg.net/alexdpsg_net.crt (to under Servers) to test and > that got me the regression range with symptom "no exception dialog for > trying to connect." Well, if that's the root certificate (not the end-entity certificate), then importing it to the Servers tab won't work. It'll have to be under the Authorities tab. Then, if that root is trusted, the end-entity certificate should validate correctly and the connection will succeed.

Ok, BUT, if one did that wrong earlier it was (evidently) ignored, now silently failing.

yep, this is my root cert (yes, i know not perfect but small environment) - adding it to the Authorities worked in tb 32(windows), tb 31 and 33 not checked.

This one is a blocker in our intranet, since it stopped mail processing to those unhappy who updated their clients today. We use internal root CA to sign other certificates, including the one used by mail server. TB refused to go over SSL altogether. Re-installing certificates didn't help (on both Windows and Ubuntu computers). I would appreciate if TB developers would perform more thorough tests when changing SSL-related areas. Thanks.

Same problem here with TB 31.0. Server is Verio FreeBSD VPS running sendmail with self-signed certs installed by Verio's built-in "vinstall" command. Sending email insecurely still works in 31.0, but SSL/TLS and STARTTLS both fail with TB's "unknown error" message... and it won't even bring up the "allow exemption" dialog or let you add one manually in preferences. Worked fine for years until today after upgrading to TB 31.0. Reverted back to TB 24.7.0 and works fine again with no other external changes. Waiting for a fix.

Oh... and I'm on Mac OSX 10.9.4 so Mac version 31.0 in my case.

Just curious - are there plans to handle this bug in the immediate future? It's still unassigned. Thank you.

We've experienced the same thing as everyone else here. We have self-signed certs and had to revert all our systems back to TB 24.6. Bug is confirmed on Ubuntu and Windows 7 here in our offices and it's pretty substantial to us.

Hi, I am also suffering from this bug. Have self-signed certificates for private use. This is totally sufficient and works perfectly. I am used to this. Everything else is a big hassle. I hope Thunderbird people will rectify this bug. Can you already tell us when the bug will be fixed? Thank you in advance, Thunderbird is a great program!

Setting security.use_mozillapkix_verification to false could work as a workaround I think. keeler: you you need additional info here? it seems a fair number of people hit this

There is no workaround when you're the one running the server and you have no control over your remote clients' Thunderbird installations. Telling them they all need to turn off their email security doesn't seem like a good option. ;-) Please fix this, Mozilla. It is affecting Unix, Mac and Windows users in my experience.

Just FYI, that option doesn't turn of security, it uses the old library mozilla used to use. Yes, it's not a good workaround but only a first aid in some situations. (The pref and option to use the old lib has been removed from later development versions.)

Here's what I recommend: * Remove any existing overrides for the server in question (Preferences -> Advanced -> Certificates -> View Certificates -> Servers) * Import the root certificate for the server (i.e. the certificate that issued the server's certificate) in the Authorities tab of the certificate manager * Edit the trust of that root so it can identify websites (select it and click "Edit trust") * Try connecting to the mail server. If that doesn't work, remove the imported root and try connecting again. The certificate error override dialog should show up. If it doesn't appear or it doesn't work, please attach a copy of the certificates you're using and identify what version of Thunderbird you're using. Note that this will not work in 33 - that is due to a separate, known issue (bug 1046328).

fwiw, the original reporter's root CA certificate does not meet the CA/B Forum Baseline Requirements for a root CA certificate. the original reporter's root CA cert is: -----BEGIN CERTIFICATE----- MIIEmzCCA4OgAwIBAgIJAOTRdqh+3BXWMA0GCSqGSIb3DQEBBQUAMIGPMQswCQYD VQQGEwJERTEQMA4GA1UECBMHR2VybWFueTEQMA4GA1UEBxMHQ29sb2duZTEPMA0G A1UEChMGUHJpdmF0MRIwEAYDVQQLFAlBTEVYX0RQU0cxFTATBgNVBAMTDGFsZXhk cHNnLm5ldDEgMB4GCSqGSIb3DQEJARYRaW5mb0BhbGV4ZHBzZy5uZXQwHhcNMTEw MzAyMTQzNzQyWhcNMjEwMjI3MTQzNzQyWjCBjzELMAkGA1UEBhMCREUxEDAOBgNV BAgTB0dlcm1hbnkxEDAOBgNVBAcTB0NvbG9nbmUxDzANBgNVBAoTBlByaXZhdDES MBAGA1UECxQJQUxFWF9EUFNHMRUwEwYDVQQDEwxhbGV4ZHBzZy5uZXQxIDAeBgkq hkiG9w0BCQEWEWluZm9AYWxleGRwc2cubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA6GgDdZ5udpqUTfJUDA+bSfZW+19Kz297iq2LUgIHOBpIl6h5 9FjSvbcn0j07ZitjX5WrNTTpp7SkGF6mkpchsHyqyFb3UDMRimjSKCmDfuY0/9IH i8EOgHKK820yAFykRgPw+TJadVB7m2v3mRzarDHNCnxZP786uioXwPoZg8ki8Fi/ N53lBK+uBAI8jL3FvrK2PgAtdE1Wo4kmfFmc2Ol4zRf/ZDdsYdS7ajudsRb2o8xr Ih2EMOvkDKBJOzbYVsK3ANMQnj+jHzaep2Eb5V0vhMnBxrRmTjqkdrikgmpnvBSx V5i9WIsyz+jVyFeytc6Yb3MEyCBiSscg3wJsAwIDAQABo4H3MIH0MB0GA1UdDgQW BBTP7Y5skglNOkhy+Ha8EBAA7AumazCBxAYDVR0jBIG8MIG5gBTP7Y5skglNOkhy +Ha8EBAA7Auma6GBlaSBkjCBjzELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0dlcm1h bnkxEDAOBgNVBAcTB0NvbG9nbmUxDzANBgNVBAoTBlByaXZhdDESMBAGA1UECxQJ QUxFWF9EUFNHMRUwEwYDVQQDEwxhbGV4ZHBzZy5uZXQxIDAeBgkqhkiG9w0BCQEW EWluZm9AYWxleGRwc2cubmV0ggkA5NF2qH7cFdYwDAYDVR0TBAUwAwEB/zANBgkq hkiG9w0BAQUFAAOCAQEAOlm8QbaBXwWbOKuRoVeEt+5Bk2zms+ld+fKvhgg2cBEt FacKssNdXjcI1Y/GkXDtYT2uKOOFLifTLaonP2Jo3kpyplDLRAbMWG+z/p6w+3AM KUzVVPlk9agHdGsRtjL5gLXLO5OUZLi6/NO4XqLJ6C+GY5qCiBT5D1HEFEZ3F7O3 Os6CZk98wFdaOjVgaCp9OH3h8YurUyS2gzoQJOc/RhbnHmMUGPHvJEd8LV0cqAa4 2KQ0/OIpy2EqCjayTh77LbfQXsREfcoVyk/N/AxBJgIIO4b16IwaZV7gd3punnNC Sqhm1NXAPZhip4hEjnrzdur4Z56MdamBgNh7qSFzjg== -----END CERTIFICATE----- this certificate does not have a keyUsage extension. CA/B Baseline Requirements v. 1.1.8, appendix B says that for root CA certificates: B. keyUsage This extension MUST be present and MUST be marked critical. Bit positions for keyCertSign and cRLSign MUST be set. If the Root CA Private Key is used for signing OCSP responses, then the digitalSignature bit MUST be set. So i think that thunderbird 31, which validates against these rules, might be refusing to honor this particular CA because of the lack of kU extension.

The bug still exists even if OCSP validation is turned off in the settings.

Comment 24 might be right, but IMHO it is silly to force self signed and even private CA certificates to comply to the baseline requirements. A warning sure, but just a warning. There needs to be a UI to allow the certificates anyway, and give control back to the users.

I agree with Richard van den Berg: in Firefox 31/Thunderbird 31 the SSL processing changes prevent users from adding exceptions for certificates missing certain quality standards. I would say that browsers/mail clients may not dictate me what certificates to use. I should be able to add exceptions to whatever I need. Nag if you wish, place warning icons/whatever, but preventing me from using certificates I trust is absolutely unacceptable.

I want to add to the "absolutely unacceptable" comment by Konstantin Boyandin. I set up my TB profile, accounts etc. more than 5 years ago, including an exception for a self-signed certificate that I use for all my email. I then forgot about all this process and since then I just copy my profile whenever I set up a new operating system and/or re-install TB. So, my email "just worked". Suddenly, an automatic update of Ubuntu leaves me with my email completely broken (TB just cannot connect to server). After being left without email for a few days (possibly blaming the server, the VPN etc.) I eventually googled for the problem and I reverted to TB 24.6 that is still working. Now, having your email just broken after an automatic update without any sign of what might be wrong is absolutely unacceptable.

@Yannis your experience was the same as ours. Over the space of a day or two e-mail just started going down for people company wide. We had issues where customers weren't getting responses for over a day when our normal response time is under an hour. Giving some kind of warning would be nice. Or just sticking with "if it ain't broke, don't fix it". Couldn't agree more with @Konstantin. Warn us, fine. But preventing us from using our own self-signed certs sounds like something Microsoft would do.

To add some more to this, I've seen inconsistent behavior of this exact issue with the variable being the base-OS. My certificates are in-fact signed by a valid CA (cacert). I've had this CA imported and operating successfully throughout my systems for several years now. My OSX 10.7.5 system, running TB happily for several years now, broke in a big way when TB updated to 31.0. No STARTTLS accounts I host could connect. I as well have reverted back down (30.0 works again in my case). Yet another system, running OSX 10.9.4, still -can- connect to the exact same accounts with the exact same settings following when TB updated to 31.0.

I also just upgraded to TB31 and now no SSL connections work to my server (iMail from www.imailds.com). I have the server setup to only allow SSL connections for all authentications, so this is fairly problematic for me. My ca cert is from GoDaddy and is valid until 2016. Have tried most of the workarounds posted here with no success

I am suffering from the same problem afer an automatic upgrade to TB31 on Ubuntu. What a PITA, especially since there is no error message or any indication of an error whatsoever. I just happened to notice new emails had arrived on my phone, but TB is not downloading them.

Over the last 2 weeks this issue has progressively gotten worse. A few minutes ago I opened TB 31.0 and got the first of several popups "Unable to obtain identification status for the given site.". Normally, I either add the exception or get the certificate and it'll stop for that particular session. This time, I clicked the button to add the exception about 50 times in a row. I then got fed up and just held down the ESC button for a minute or two just to see what would happen and yep, it just continued popping up with no end. I went into task manager and stopped the program. I then relaunched TB 31.0 and it seems ok so far with no pop ups. Point being, it's getting worse. I first thought it was a firewall issue, but clearly it's not. I had read an old article which mentioned using a TB addon - http://kb.mozillazine.org/Security_Error:_Domain_Name_Mismatch_or_Server_Certificate_Expired . The addon mentioned is out of date. Any suggestions.

(In reply to Nake Corp from comment #35) > Over the last 2 weeks this issue has progressively gotten worse. A few > minutes ago I opened TB 31.0 and got the first of several popups "Unable to > obtain identification status for the given site.". Normally, I either add > the exception or get the certificate and it'll stop for that particular > session. This time, I clicked the button to add the exception about 50 > times in a row. I then got fed up and just held down the ESC button for a > minute or two just to see what would happen and yep, it just continued > popping up with no end. I went into task manager and stopped the program. > I then relaunched TB 31.0 and it seems ok so far with no pop ups. Point > being, it's getting worse. I first thought it was a firewall issue, but > clearly it's not. I had read an old article which mentioned using a TB addon > - > http://kb.mozillazine.org/Security_Error: > _Domain_Name_Mismatch_or_Server_Certificate_Expired . The addon mentioned is > out of date. Any suggestions. I forgot to mention that the issue occurs on 143, 993 and 995.

People having this problem should try setting security.use_mozillapkix_verification to false

@Magnus Melin, if I am not mistaken, since version 33 mozilla::pkix is the only verification library available. So it's not solution in the long run. The solution is to allow adding exceptions - to fix that broken feature. As far as I see, no developer wishes to fix this, thus forcing a lot of people to stop using Mozilla products in the long run. Good luck on that path.

Yes it's just a workaround that does not work for 33+, but it can help for the immediate problem so people can access their mail.

any progress for tb 33+ ?

I have the same issue and I also have about 20 people working for a company experiencing the same. We had to roll-back to version 26. This is the biggest flaw in T so far in years. It is unacceptable to release a software from beta to full without having this testes enough. We are really out of luck.

I did not mention that I am experiencing the issues on Windows clients. Luckily the Fedora team has not pushed the 31 version in the repository, otherwise I would be probably experiencing the same issue on Linux as well. The code is the same anyway, so this is a wide-system Thunderbird 31 issue.

Still nothing done on this up through TB 31.1.1 release?

(In reply to Bogdan from comment #42) > I did not mention that I am experiencing the issues on Windows clients. > Luckily the Fedora team has not pushed the 31 version in the repository, > otherwise I would be probably experiencing the same issue on Linux as well. > The code is the same anyway, so this is a wide-system Thunderbird 31 issue. Not true anymore. Fedora released the broken version to FC20, at Sep 8, namely thunderbird-31.1.0-1.fc20. Many complaints coming now, just as myself. Please fix it ASAP! Fortunately, workaround at comment #8 worked for me.

Hate to be a "me too" guy, but this one has hit me too. I'm using Ubuntu's 31.1.1 on 14.04. Was working fine until I updated to this version, now I can't connect to my home mail server (using a CACert certificate). I've tried the security.use_mozillapkix_verification false thing, and tried importing my certs root cert into the Authorities section. Neither helped me.

Me too. Ubuntu 12.04LTS or Thunderbird itself recently upgraded to 31.x, and no all communications with self-signed certs broke down. Thanks to the hints on this bug I reverted to 26.0b1, and everything works as it should again. Turned off auto-updates. Really annoying, and I don't have the time and the willingness to work through all the possible reasons why this may have been the "right choice" by the TB developers. Sorry...

Standard8, this is causing a lot of grief. Is there any proposal for dealing with this in Thunderbird 31?

(In reply to Kent James (:rkent) from comment #49) > Is there any proposal for dealing with this in Thunderbird 31? We'll see if we can find someone to fix it.

For tb31 esr, how about setting security.use_mozillapkix_verification to false? (If not, we should list this under known issues, with that as a workaround.)

(In reply to Konstantin Boyandin from comment #53) > You caused major troubles for huge amount of users. And looks like you just > don't care. We do care, however we aren't always able to catch everything. Although this wasn't flagged, unfortunately it was underestimated as an issue for lots of users. We have already dealt with several major regressions in 31 and a security issue, as can be seen from the various dot releases. > I would like to ask you just to allow manual override, as it was before. You > may not govern what type of certificates are used - mail client must be > compatible with any type of self-signed certificates. If it were as simple as you make it sound, I'd have probably written the patch and uploaded it by now. Unfortunately it is not, and hence we need to find someone to fix it and I've already started asking around. Folks, at this stage, I feel I must remind you of the etiquette. Please read it before commenting on this bug: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html The best thing to do is not to comment, unless there's new information to add, or information specific to fixing it. Otherwise, "me too" and other similar comments just serve to waste time further and slow down the developers. We understand this is a significant issue for folks, and we will be trying to fix it.

(In reply to Magnus Melin from comment #54) > For tb31 esr, how about setting security.use_mozillapkix_verification to > false? > (If not, we should list this under known issues, with that as a workaround.) When I set it to false, I am able to send email again. However I am then rendered unable to receive email. So, I turned it back on.

(In reply to Magnus Melin from comment #54) > For tb31 esr, how about setting security.use_mozillapkix_verification to > false? > (If not, we should list this under known issues, with that as a workaround.) Yes, for any gecko-31-based versions, I imagine this will restore the previous behavior.

At this point what would be helpful from those that are seeing this bug is to try the workaround suggested in comment 54, and report here whether that worked or not.

As I mentioned at bug 1065649 https://bugzilla.mozilla.org/show_bug.cgi?id=1065649 (which is essentially the same problem within Seamonkey). Setting the parameter in Comment 54 solves the issue concerning email BUT it has side effects with stored/trusted certs in the browser. My Firewall for example uses a self signed cert with won't work anymore after setting the parameter to false. Re-importing and adding an exception wouldn't work either.

(In reply to Kent James (:rkent) from comment #59) > At this point what would be helpful from those that are seeing this bug is > to try the workaround suggested in comment 54, and report here whether that > worked or not. As David Keeler pointed out: I am able to receive email, but can't send. This is for both Windows and Ubuntu builds of TB. Using 26.* versions is the only solution so far.

David, do you have any idea of why the workaround is not working for the user in comment 61?

(In reply to Kent James (:rkent) from comment #62) > David, do you have any idea of why the workaround is not working for the > user in comment 61? Maybe different certificates for IMAP/POP and SMTP? df.eu uses this constellation. Are both certs imported and fully trsuted?

(In reply to hallobox from comment #63) > (In reply to Kent James (:rkent) from comment #62) > > David, do you have any idea of why the workaround is not working for the > > user in comment 61? > > Maybe different certificates for IMAP/POP and SMTP? df.eu uses this > constellation. Are both certs imported and fully trsuted? Correct, IMAP4/POP3 and SMTP use different certificates. Both are imported and fully trusted.

(In reply to Kent James (:rkent) from comment #62) > David, do you have any idea of why the workaround is not working for the > user in comment 61? That would point to mozilla::pkix not being directly related to what caused this to break. In any case, probably the quickest way we're going to be able to figure out what's going on here is for those who are experiencing this problem to include some more details such as what domain name/port they're trying to connect to or the entire certificate chain the server is sending (with the root certificate, as well).

(In reply to David Keeler (:keeler) [use needinfo?] from comment #65) > That would point to mozilla::pkix not being directly related to what caused > this to break. In any case, probably the quickest way we're going to be able > to figure out what's going on here is for those who are experiencing this > problem to include some more details such as what domain name/port they're > trying to connect to or the entire certificate chain the server is sending > (with the root certificate, as well). Here you are: https://bugzilla.mozilla.org/show_bug.cgi?id=1065649#c2 If you need a mailbox for testing contact me directly.

I am affected by this bug as well, not to be just a "me-too", I want to add an information: my certificates are not self-signed, they are paid-for valid StartSSL certs. I had to revert to 24.8.1 to make it work again after trying 33beta and of course 31.1.12. I am reporting this as well to StartSSL so they be warned and so they might go through this bug and tell me if something might oe needs to be done on the server or client side regarding their certificates.

I think this issue is the same as bug 1042889. I can confirm that the exception dialog is reappeared with the patch in bug 1063315.

(In reply to hallobox from comment #66) > (In reply to David Keeler (:keeler) [use needinfo?] from comment #65) > > That would point to mozilla::pkix not being directly related to what caused > > this to break. In any case, probably the quickest way we're going to be able > > to figure out what's going on here is for those who are experiencing this > > problem to include some more details such as what domain name/port they're > > trying to connect to or the entire certificate chain the server is sending > > (with the root certificate, as well). > Here you are: https://bugzilla.mozilla.org/show_bug.cgi?id=1065649#c2 > If you need a mailbox for testing contact me directly. Thank you for the information. However, I was not able to reproduce the issue using the following settings: Email address: test@sslmailpool.ispgateway.de Password: test Incoming: POP3, sslmailpool.ispgateway.de, port 995, SSL/TLS Outgoing: SMTP, smtprelaypool.ispgateway.de, port 587, STARTTLS I don't have an account, so authentication didn't work, but from capturing packets using wireshark, I observed a successful TLS handshake. This was using Thunderbird 31.1.1 with the default certificate verification settings.

Sorting through the comments, I see one common behavior pattern, reported by Konstantin Boyandin and G J Piper: "When I set it to false (setting security.use_mozillapkix_verification), I am able to send email again. However I am then rendered unable to receive email. So, I turned it back on. ... Using 26.* versions is the only solution so far" hallobox has a similar but not identical experience (on SeaMonkey): "Setting the parameter in Comment 54 solves the issue concerning email BUT it has side effects with stored/trusted certs in the browser. " The only viable fix for TB 31 is using that preference, so we need to understand why it is having unexpected issues. It would be really helpful if someone involved with the core Thunderbird team could reproduce this. Hiro, Standard8, Magnus, Wayne, are any of you able to reproduce failures with security.use_mozillapkix_verification = false on tb31? hallobox, you offered credentials, but "contact me directly" to devnull@hallobox.de sounds like a no-reply address. Would you be able to send test credentials to someone on the Thunderbird core team (that list above, or me kent@caspia.com), ideally with permission to share those credentials with others on the core team for testing purposes? Or can anyone else offer test credentials for an account? G J Piper, you implied that you are the one running the server. Would you be able to come up with a test account that we could use to demonstrate the problems?.

(In reply to Kent James (:rkent) from comment #70) > The only viable fix for TB 31 is using that preference, so we need to > understand why it is having unexpected issues. It would be really helpful if > someone involved with the core Thunderbird team could reproduce this. Hiro, > Standard8, Magnus, Wayne, are any of you able to reproduce failures with > security.use_mozillapkix_verification = false on tb31? No, I can't. So I decided to starting investigation the failure on setting security.use_mozillapkix_verification true. In my case, the cause of the failure is SEC_ERROR_CA_CERT_INVALID. Then bug 1042889 could be found.

RE: G J Piper, you implied that you are the one running the server. Would you be able to come up with a test account that we could use to demonstrate the problems?. Yes. I will set up a new email account and email the login credentials to kent@caspia.com. This will happen in the next 3 hours at the latest. Share only with responsible Mozilla team members.

I found the cause of GA's failure case on setting security.use_mozillapkix_verification false. SEC_ERROR_CA_CERT_INVALID has been removed by bug 991177.

If I correctly understand bug 1042889 comment 55 made today by Firefox VP Jonathan Nightingale, he has set the policy that Firefox security should allow overrides of certificates after sufficient warnings: "Firefox's intent is that an override be possible, and I am satisfied that the warnings we put up are suitably effective at protecting novices from MitM. How quickly can we get to a fix that accomplishes that intent?" The issues in this bug are largely (so we believe) a fallout from changes made in Firefox, so we are hopeful that these changes, which will be uplifted to Firefox ESR 31 and thus to Thunderbird 31, will fix this current bug as well. We now have credentials from a couple of users in the current Thunderbird bug, and Hiro has been taking the lead in testing them with the patches applied from the Firefox bug.

Hiro pointed out to me privately, I can confirm using credentials supplied by G J Piper, that the symptoms in comment 15 can be reproduced in released Thunderbird 31.1.2 (sending fails to mail.piperhost.net using port 587 STARTTLS). Using a build with the current patch on bug 1042889, sending now works. At this point, we believe that this bug is going to end up just being a dup of bug 1042889, so that when the patch lands for that on the Mozilla esr-31 branch, then future Thunderbird 31 releases (that also use Mozilla esr-31) will then work. I am trying to get a try server run up for this, so that others can test for other issues.

The patches for bug 1042889 have now landed on mozilla-esr31. The latest build of Thunderbird 31.2.0, which should release in less than a week, is now available with those fixes at: ftp://ftp.mozilla.org/pub/thunderbird/nightly/2014/10/2014-10-11-03-02-04-comm-esr31/ If anyone who is experiencing this issue could try that build, and report back here whether it fixes their issue or not, that would be appreciated. I tested with one set of credentials that were sent to me, from G J Piper, and it fixed the issue.

Kent, I just tried that esr31 version and it doesn't fix my problem. When sending mail to my Exim mail server that uses a self-signed certificate, the sending times out. Also it seems that Exim (subprocess/thread) hangs on the server-side. I will email you some credentials for testing.

Please disregard my previous comment (#78). I found out my problem was not related to TB at all, but some package I installed on my server that broke PAM, that in turn broke Exim authentication. Sorry for the noise.

I can confirm that the new Thunderbird v31.2.0 release fixes this issue for me. It allows me to confirm indefinitely the security certificate and I am able to send through my SMTP server using either STARTTLS or SSL/TLS again.

I've got Thunderbird version 33 (beta channel) on Windows 8.1 64-bit and cannot get it to let me add a security exception at all. It just says "Unable to obtain identification information for the given site". I tried a copule of workarounds suggested elsewhere (changing the port in the dialog box to 443, which made it detect the certificate and allowed me to import it, as well as manually downloading the certificate and importing it), and neither option worked. I don't send much email so it's not a huge deal, but it's annoying either way.

Mike: There are still ongoing discussions about handling this issue in Gecko 33, so AFAIK there is no fix landed there yet. The confirmed landing is in Gecko 31 which would affect TB 31. Please check those versions, for example the link in comment 77 (or later versions of the Thunderbird 31 branch).

Now I (Reporter of Bug 1036338, marked as a duplicate of this bug) have still one question: Does that mean, that with Thunderbird v31.2.0 we can reset security.use_mozillapkix_verification back to true without running into the cert problem anymore?

That was wrong, I meant Bug 1052102, sorry.

(In reply to t318671 from comment #83) > Now I (Reporter of Bug 1036338, marked as a duplicate of this bug) have > still one question: Does that mean, that with Thunderbird v31.2.0 we can > reset security.use_mozillapkix_verification back to true without running > into the cert problem anymore? As far as I understand the issues, yes you can and should "reset security.use_mozillapkix_verification back to true" with Thunderbird 31.2.0 However, my pleas for testing prior to release in comment 77 only got one valid response (Thanks, G J Piper!) so this understanding is mostly theoretical, and I am not a Security Expert. (Thanks also to Mike and Marcel for attempts to test). I would still appreciate comments from a few people on whether version 31.2.0, which is now released, solves their issues or not. In the parent bug there were many different kinds of failures that could generate the issue, and that fix was motivated by similar concerns in Firefox, not Thunderbird, so it is not certain those issues are the same, but likely.

I can confirm that Thunderbird 31.2.0 resolved this issue for me with security.use_mozillapkix_verification set to true. I was never asked to add an exception for my self signed certificate. It seems TB 31.2.0 is using the same exception list as TB 24 did.

Yes, here is a good "me too". I just installed v31.2.0, reset security.use_mozillapkix_verification back to true, restarted TB one more time, and yes, I can read and send mails. I also wasn't asked to add a new cert exception. Many, many thanks, Kent for your work on this issue!

"Many, many thanks, Kent for your work on this issue!" And yet, strangely, I've mostly done communications. Hiro did most of the Thunderbird technical work, and Kai Engbert played a major role in bug 1042889. Also thanks to those who provided credentials for testing. I'm tempted with the confirmations to mark this bug a duplicate of bug 1042889. Work is still ongoing there to get the fix in for Gecko versions 33 or later. If I get no objections, I'll do that in a few days. I'd also like to nominate (tongue-in-cheek) Firefox VP Johnathan Nightingale as a "friend of the tree" for Thunderbird for his role in deciding that Mozilla will indeed allow overriding of certificates with sufficient warnings.

It seems like the fix landed in version 31.2.0 and it really works now. Thank you all for involvement!

Just testet version 31.2.0 and now it works. Great!!!

nope, won't work " Sending of message failed. The message could not be sent using SMTP server <> for an unknown reason. Please verify that your SMTP server settings are correct and try again, or contact your network administrator. " and check mail stuck with "checking Mail server capabilities" rootCA and server certs known in thunderbird "security.use_mozillapkix_verification = false" is the only option so far (TB 31.1.2 // Ubuntu 14.04.1)

@Update same in TB 34.0a1 (2014-07-23) 34.0~a1~hg20140723r16586.195564-0ubuntu1~umd1

ok, nevermind my last 2 comments the daily ppa builds failed - Tb 1:33.0~b1+build2-0ubuntu0.14.04.1 works fine so far

Receiving email from my IMAP server with a self-signed cert works in TB 31.2.1 with "security.use_mozillapkix_verification" set to true (it didn't before). Lightning 3.3.0 works with my CALDAV server with a self-signed-cert (it didn't before). Unfortunately, the Addressbooks Synchronizer 1.1.2 plugin (https://addons.mozilla.org/en-US/thunderbird/addon/addressbooks-synchronizer/?src=ss) hangs trying to download address books from my HTTP(S) server with a self-signed-cert. It does not display an error message or dialog allowing me to view and/or accept the cert. It also fails with "security.use_mozillapkix_verification" set to false (that worked before I upgraded to 31.2.0).

Typo in comment 94, should be Lightning 3.3.1.

From 1049918 Tested 31.2.0 Works Steps followed Deleted exceptions set security.use_mozillapkix_verification = true Restarted Thunderbird On next send attempt prompted for exception confirmed exception Resend message Succesful.

How about self signed certificates for email (S-MIME) encryption? It still does not seem to work in 31.2.0 when setting security.use_mozillapkix_verification = true. How can I declare the self signed certificates as trusted? It previously worked by loading them as CAs. Now it does not work any more.

I was affected by this as well. My setup is OS X 10.10 and TB 31.2 and a certificate added to the store by adding a security exception. After clearing out all certificates from the server section and confirming the security exception again, the problem was gone.

Hi, Still seeing this issue as of today in TB 31.2. My company's mail provider is register.com. mail.mycompany.com forwards to webmail04.register.com, our actual mail server. The cert is for *.register.com, which of course is invalid for the URL mail.mycompany.com. I was able to get the "Confirm Security Exception" dialog box using the workaround (first?) suggested in comment 54: "security.use_mozillapkix_verification = false" But when I set it back to "True," having confirmed the security exception, TB will not receive new mail from our IMAP server (and provides no error). Trying to send mail yields the message: "Sending of message failed. The message could not be sent using SMTP server mail.mycompany.com for an unknown reason. Please verify that your SMTP server settings are correct and try again, or contact your network administrator." We cannot change the cert with the provider; for now we are using the workaround. Upgraded from TB 24.7, which functioned perfectly. Wiping TB (as well as user profile) and re-installing makes no difference. Installing on new, clean PC makes no difference. We are primarily running Windows 7 64-bit.

At this point, anyone seeing an issue with this needs to file a new bug. The primary issue was fixed, and confirmed in various comments. I'm not saying that new issues don't exist, or are unimportant, but they need to be tracked separately from the main issue in this bug, which was fixed by changes to mozilla-central.

Has a new bug been opened? I can confirm the issue is still there in Thunderbird 31.3.0. Removing my self-signed CA certificate does not help. Even after removing the certificate from the store I get absolutely no dialog about the certificate. Just that it failed for an unknown reason. I can be persuaded to accept that the certificate authority is not quite correct (see below), but no warning dialog box? No option to proceed? My CA Certficate is missing the "Critical" flag on the key usage extensions. I will at some point try to generate a new CA certificate (and resign the certs) to see if that fixes it. In the meantime I downgraded Thunderbird back to the 24.8 and it is working again.

There are a number of recent unconfirmed certificate bugs in Thunderbird (search for "Certificate: in Thunderbird product) but I am not aware of bugs that narrow the issues that still exist into the a specific confirmed description of current conditions.

(In reply to Michael Torrie from comment #101) > Has a new bug been opened? I can confirm the issue is still there in > Thunderbird 31.3.0. Removing my self-signed CA certificate does not help. > Even after removing the certificate from the store I get absolutely no > dialog about the certificate. Just that it failed for an unknown reason. I > can be persuaded to accept that the certificate authority is not quite > correct (see below), but no warning dialog box? No option to proceed? Please paste logs in error console (Ctrl + Shift +J).

I'm sorry but there is absolutely nothing in the error log. I tried 31.2.0, 31.3.0, and 31.4.0. They all act the same. Sending a message pops up a box that says it's connected to my server, but it quickly fails and says it cannot send do to an "unknown error." When I click on my IMAP inbox, it will not pull in new emails and clicking on a message just causes thunderbird to spin saying in the taskbar, "checking mail server capabilities." If I knew exactly what was wrong with my certificates and why, I would be willing to fix them. But at this stage I have no idea. Rolling back to Thunderbird 24.8.1 works great again. I have a web site that uses a certificate signed by the same authority, but I currently don't have Firefox newer than 24 to test it on. I might have to download the latest firefox and see what it says about my certs.

Firefox 35 gives me the dreaded "sec_error_extension_value_invalid" error. The question is why isn't Thunderbird giving me any kind of error reports like firefox does? And how can I get Thunderbird and firefox to just accept my certificates. Why not pop up a box asking me? Going back to Thunderbird 24 PaleMoon browser until this is fixed.

(In reply to Michael Torrie from comment #105) > Firefox 35 gives me the dreaded "sec_error_extension_value_invalid" error. > The question is why isn't Thunderbird giving me any kind of error reports > like firefox does? And how can I get Thunderbird and firefox to just accept > my certificates. Why not pop up a box asking me? Thanks for testing. The result of firefox35 would be very helpful. Please open a new bug. We need to help from security experts.

I would open a new bug, but it looks to me like there are tons of bug reports along a similar vein, most of which are closed, involving fixing the bad certs, or slight modifications to libpkix over the last few releases. My problem is two-fold, one is how come thunderbird won't even show me a certificate error message, and two, just what exactly does libpkix not like about my certificate? I could probably open a bug report on thunderbird not showing a descriptive error message. I'm unsure what to do about the certificate issue itself.

(In reply to Michael Torrie from comment #107) > I would open a new bug, but it looks to me like there are tons of bug > reports along a similar vein, most of which are closed, involving fixing the > bad certs, or slight modifications to libpkix over the last few releases. > My problem is two-fold, one is how come thunderbird won't even show me a > certificate error message, and two, just what exactly does libpkix not like > about my certificate? The latter must be bug 1045973.

Added specific bug about the lack of any real error message here: https://bugzilla.mozilla.org/show_bug.cgi?id=1121302

Even though this bug is closed, I do think it describes the 2 issues best, so that is why I am posting here for reference: Using Seamonkey 2.32 the exact same issues can be observed. - First issue is that though the mail client is prompting for a certificate, it is actually never able to fetch it - second issue is that a manual import of the certificate has limitations: It will only be attached on https (port 443), and not on the imap or smtp port. The solution/workaround I found: Mozilla keeps certificates that can not be verified in cert_override.txt I had a copy containing a working key on a different machine. Simply putting this in your profile folder solves the issue. In case you want to add new/more keys here, you need to edit this file according to the rules as set out here: https://developer.mozilla.org/en-US/docs/Cert_override.txt I have to say that I cheated a bit: I took my imap certificate that was already in here, and updated it with just the fingerprint of my smtp server which is on the exact same machine. This works, but the import mechanism for self signed certificates is definitly not working here.

I have updated to version 38.01 on my Windows 8.1 and cannot check mail using self signed certificate

(In reply to Rafi from comment #111) > I have updated to version 38.01 on my Windows 8.1 and cannot check mail > using self signed certificate Please file a new bug to track this issue. Include as much detail as you can, such as a publicly-accessible domain name if applicable and the full certificate chain that the server sends.