server certificate exception not "taking" since 52.6 (also 52.7) but only one account of two on same server (Linux mint 16.04.1)
I'm getting new and unexpected certificate rejects starting with 52.6. My server has had the same cert for quite a few years, no major changes server side - and there's a second domain/account on the same server that is checking just fine. I can't find any meaningful differences between the configurations of the two accounts and haven't made any changes. The only thing I saw that seemed coincident was upgrading to 52.6, but that might be spurious.
On mail check with the afflicted account I get the "Add Security Exception" dialog (note that this certificate, unchanged, has been stored for many years and hasn't caused any issues previously - and it is the same server/certificate/fingerprint for similar account that is working).
"Unknown Identity" The certificate is not trusted because it hasn't been verified as issued by a trusted authority using a secure signature.
(True, it is self-signed, valid until 2034)
If I click "confirm security exception" (with "permanently store this exception" checked), mail is NOT checked, it seems to silently refuse to connect. If I change mailboxes, i get the same "Add Security Exception" dialogs again. However, if I check the the confirm security exception, the certificates do get added to the server certificate list (but weirdly, to seemingly random headings - as in my server certs are now listed under GeoTrust, Inc. There's nothing about GeoTrust in the hierarchy).
If I click "get certificate," the only user-output is all the dialogs gray out and "cancel" remains.
If I click "View," I see the usual (and correct) information.
I tried deleting all the certificates and restarting - no change.
I tried changing the "trust" model for the root certificate and... now Thunderbird won't start at all (:/).
I updated from 52.6 to 52.7, no change in behavior. I'm updating non-software-manager packages with sudo-apt-update, but the only remotely relevant update is firefox-locale-en, the rest are just mesa driver things. (It'll take a while, slow connection).
Unless there's something obvious I'm not checking (perhaps there was an offscreen dialog from "get certificate" I missed?), my next steps will be to restart (and hopefully be able to launch thunderbird successfully) or remove and reinstall TB.
Was something really borked in the certificate handling recently? i noticed a few security updates for 52.6/7, but nothing obvious.
-David
Alle Antworten (18)
As an update - another install on a different machine of 52.6 is working fine - same server/account, settings (copied settings)... strange.
well, kinda got it fixed. Got Claws mail installed and working so at least I can get my mail on this machine. I'm still not sure what the problem is with Tbird. I deleted and recreated the profile but used the same local folders (50GB of mail would take about a week to download here) to no avail. Weirdly, still, other installations work fine. Something is borked. Next step is to delete the entire profile and start over. Doesn't seem to be a plugin or even a server conflict because other identically configured installs work fine. :/
I would suggest checking the server against https://www.htbridge.com/ssl/
I think it will continue it's tests on self signed certificates.
I am guessing either a corrupt certificate store or use of an obsolete TLS cypher. Hence the test suggestion. (not all distro versions of Thunderbird are the same as the release version)
Useful suggestion - TLSv1.0 is deprecated now.
Is Thunderbird now rejecting connections with servers that allow deprecated ciphers - something that is commonly allowed for compatibility reasons. It would seem a bit snooty to do so, especially without a descriptive error message and the config certainly supports strong connections (e.g. TLSv.12 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA and P-384 (secp384r1), etc.
I can see disabling TLSv1.0 or regenerating the key with a longer DH key as reasonable (but not critical) suggestions, but why is TB rejecting the connection?
from main.cf: (changes in bold) smtpd_tls_ciphers = high smtpd_tls_exclude_ciphers = aNULL, DES, 3DES, MD5, DES+MD5, RC4 smtpd_tls_mandatory_ciphers = high smtpd_tls_protocols = TLSv1.2, TLSv1.1, !TLSv1, !SSLv3, !SSLv2 smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, TLSv1.1, TLSv1.2 smtpd_tls_security_level=may
no change in behavior. Note the last day I connected with TB was 3/26 (a few days of travel means that date isn't perfect).
Also, a bit more detail - I have a linux install 52.7.0 64 bit that stopped working on 3/26. I have ANOTHER Linux install, also 52.7.0 x64 that has an identical set of add-ons that is still working. Another user has a working linux install (52.6) but is getting the same errors on a Windows install (not sure the version, but probably 52.6 given proactive upgrades) since 3/30. My suspicion that there was something uniquely corrupt with my install seems unfounded.
however, it also seems weird to be a programmatic thing. Even weirder, my broken install checks another account on the same server, same exact certificate even (and not SNI, so non-matching domain), and that account works fine.
Seems very odd to me... I was expecting an answer like "cert store is probably corrupted, just delete ~/thunderbird/.ssl/stored-certs" [totally made up location, no such thing exists, AFAIK]
Geändert am
The logged errors on the server are:
imap-login: Info: Disconnected (no auth attempts in 1 secs): user=<>, rip=185.34.17.7, lip=10.3.69.135, TLS: SSL_read() failed: error:1404C418:SSL routines:ST_OK:tlsv1 alert unknown ca: SSL alert number 48
Some searching suggested dovecot errors, but the following /usr/local/etc/dovecot/conf.d/10-ssl.conf config still doesn't work: ssl_protocols = !SSLv3 !TLSv1 TLSv1.1 TLSv1.2 ssl_cipher_list = ALL:!ADH:!LOW:!EXP:!aNULL:+HIGH:+MEDIUM
And sure, that's a fair error, it is self-signed, but why is it refusing to store the exception?
Geändert am
what is Thunderbird actually reporting in the console. It has moved on the menu recently but Ctrl+Shift+J should open it.
Clear the console first. It really is full of junk then try your action of saving the certificate. What appears in the error console.
Rename the files cert9.db/key4.db and cert8.db/key3.db in the Thunderbird Profile Folder to reset all root certificates.
Help > Troubleshooting Information > Profile Directory: Open Containing Folder
Based on information here. https://bugzilla.mozilla.org/show_bug.cgi?id=1434749#c15
Given the Thunderbird SSL libraries are just built from the Firefox source. If it works in Firefox it should work in Thunderbird.
Matt, Thanks so much for your help, very much appreciated.
Nothing in the console at all (I deleted localstore.rdf just in case, still nothing).
I only had cert8.db/key3.db, both deleted. Had to re-enter passwords, but once that was done, no change in certificate acceptance. :/
Dovecot 2.3.1 just came through ports with some new changes in SSL specifications and expectations, so I've installed that, but no improvement in the certificate issue, alas....
If I click "View," I see the usual (and correct) information.
What actually is the usual (and correct) information?
Nothing in the console at all
I kinda doubt that. Please check again, and make sure you look at the right place. If in doubt, check all tabs.
Geändert am
By "usual" and "correct" I mean it hasn't changed since 2014 and it is the same. By correct, i mean that it is what I expect it to be (e.g. correct serial number, fingerprint, and expiry) and is the same certificate that seems to be working for another account hosted on the same server that presents the same certificate that the same instance of thunderbird checks correctly.
And it is the same certificate (i.e. the same SHA-256, SHA1 fingerprints) as shown from edit->preferences->Advanced->Certificates->Manage Certificates->(select)->View... ) as another instance of TB running on another machine (with a copied profile, including all plugins/prefs) also on Linux Mint, but slightly different kernel (working 4.13.0-37, not 4.8.0-58 - but note both /were/ working, the one that isn't for 2+ years without any changes).
As for console, that does seem wrong. Perhaps it is a plugin conflict, my other instance of TB (the one showing the same cert but checking mail as expected) also shows no console output. I did select "All."
I still suspect corruption/bit rot at the profile level in a way that has broken something. I can delete the certificates from the certificate manager, check mail - I get exactly the same error whether the certificates are stored and visible in the manager or not. If I click "save exception" the certificate is stored in the manager, as one would expect, but mail isn't checked. Dovecot-info.log on the server shows (as noted before) with the borked instance: imap-login: Info: Disconnected (no auth attempts in 3 secs): user=<>, rip=185.34.17.7, lip=10.3.69.135, TLS: SSL_read failed: error:1404C418:SSL routines:ST_OK:tlsv1 alert unknown ca: SSL alert number 48, session=
The very close to indentical working install logs: imap-login: Info: Login: user=<[email protected]>, method=PLAIN, rip=185.34.17.7, lip=10.3.69.135, mpid=21858, TLS, session=<+FePdwtpEMG5IhEH>
Oh weird, I spoke too soon, the working instance JUST started to reject SMTP certificates in the same way - it is still accepting the incoming. Hmmm... either something expired or something got installed.
Just to be clear - this is a quirk of TB, apparently since the 57.5 update. K9, Claws, and Roundcube all connect just fine with no issues. It seems there are no easy answers and is likely a bug. We're going to try older versions of TB and see if the problem is correlated to version and, if so, file a bug report.
Interest - installed beta 58 on Linux - no different. Installed beta 60 on windows, very different! (tried various earlier versions on windows and got the same error - which makes sense since i guess it is actually firefox that is handling certificates in some way).
Beta 60 silently fails to connect. The console shows a bunch of things like reflow timing, but no errors. Running wireshark, I can see some odd errors with beta 60:
Check: 60599 664.720187 CCTV-HP5.pmcam shiofuki.blackrosetech.com TCP 54 21943 → imaps(993) [FIN, ACK] Seq=1 Ack=1 Win=66240 Len=0 60601 664.952405 shiofuki.blackrosetech.com CCTV-HP5.pmcam TCP 60 imaps(993) → 21943 [ACK] Seq=1 Ack=2 Win=66240 Len=0 60602 664.952409 shiofuki.blackrosetech.com CCTV-HP5.pmcam TCP 60 imaps(993) → 21943 [FIN, ACK] Seq=1 Ack=2 Win=66240 Len=0 60603 664.952480 CCTV-HP5.pmcam shiofuki.blackrosetech.com TCP 54 21943 → imaps(993) [ACK] Seq=2 Ack=2 Win=66240 Len=0
Send: 53060 575.790859 CCTV-HP5.pmcam shiofuki.blackrosetech.com TCP 66 21958 → submission(587) [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1 53066 576.020950 shiofuki.blackrosetech.com CCTV-HP5.pmcam TCP 66 submission(587) → 21958 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1380 WS=64 SACK_PERM=1 53067 576.021038 CCTV-HP5.pmcam shiofuki.blackrosetech.com TCP 54 21958 → submission(587) [ACK] Seq=1 Ack=1 Win=66240 Len=0 53068 576.027159 CCTV-HP5.pmcam shiofuki.blackrosetech.com SMTP 571 C: \026\003\001\002\000\001\000\001\374\003\003\212\222\016e/\347Uj\001\213\2158%\340CG%\220\232K\374\234\035K\333\025\2634\004|\242\253 \344v\204\351\030\377T\276\277J\327\0174\024W\236\303S\35584\320\3558\023(\333\017\023\2171\334\000\034\023\001\023\003\023\002\300+\300/\314\251\314\250\300,\3000\300\023\300\024\000/\0005\000 | \001\000\001\227\000\000\000\037\000\035\000\000\032shiofuki.blackrosetech.com\000\027\000\000\377\001\000\001\000\000 | \000\016\000\f\000\035\000\027\000\030\000\031\001\000\001\001\000\v\000\002\001\000\000#\000\000\000\005\000\005\001\000\000\000\000\0003\000k\000i\000\035\000 \267\364\300\367\241N\025\255G\244~\001\000\224\260\023\210>\343\331\342\344\2359\217\300\362\002e|\036]\000\027\000A\004\211-'^y\004\242\t\204h\352\a2R'\036\000\374\022\220C\351s\253\346Qy3\234\223b\203\327\302\003\032.\221=\325\037\020\357s\277\246]\026\351#\204\245 | \333U&\206.z\001 | \001\227B\000+\000\t\b\177\027\003\003\003\002\003\001\000 | \000\030\000\026\004\003\005\003\006\003\b\004\b\005\b\006\004\001\005\001\006\001\002\003\002\001\000-\000\002\001\001\000\025\000\244\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000 53076 576.282693 shiofuki.blackrosetech.com CCTV-HP5.pmcam SMTP 100 S: 220 shiofuki.blackrosetech.com ESMTP Postfix 53086 576.489969 CCTV-HP5.pmcam shiofuki.blackrosetech.com TCP 54 21958 → submission(587) [ACK] Seq=518 Ack=47 Win=66192 Len=0 53090 576.720125 shiofuki.blackrosetech.com CCTV-HP5.pmcam SMTP 124 S: 500 5.5.2 Error: bad UTF-8 syntax | 500 5.5.2 Error: bad UTF-8 syntax 53105 576.926694 CCTV-HP5.pmcam shiofuki.blackrosetech.com TCP 54 21958 → submission(587) [ACK] Seq=518 Ack=117 Win=66124 Len=0
Seems certificate is being accepted (despite not being in the certificate list) for outgoing mail, but that there's a UTF-8 issue (I have to check whether I have UTF-8 enabled on the server when i get a chance - I think I do and perhaps v60 beta is doing something wonky/new with UTF-8 that isn't quite supported on the server yet).
I suggest you take it to Bugzilla now, bug or not Firefox should not be involved in the management of keys, just the source code for Firefox is included in Thunderbird, but that does not preclude it happening. I have noticed theat post V60 the daily update of Firefox sees Thunderbird go unresponsive for the duration. But I have not really had a chance to examine why. I have been putting it down to my anti virus going nuts on the new Firefox version.
But please post a link here so I can follow along.
I also suggest you try the logging in Thunderbird. Just to see if it sheds light that wire shark has not. https://wiki.mozilla.org/MailNews:Logging
As you are using postfix, it might be worth checking the openSSL library in use.
5.5.2 Error: bad UTF-8 syntax A quick Google search appears to link the error to the use of DSPAM.but the references all are years old.
Matt,
Thanks so much, your advice is, as always, very reasonable and helpful.
I found the same references to the UTF-8 error (following OReilly's book, "googling the error message") but I'm not using DSPAM (I use a pretty standard freebsd postfix amavisd-new spamassassin clamav dovecot postgreSQL stack).
UTF-8 is annoying, it causes all sorts of issues up and down the chain. Eventually everything will be sorted out. I set smtputf8_enable = yes in main.cf and it has been working with my UTF8 domains, but was, last I checked, still having issues with UTF8 mailboxes.
I've also noticed that when I end up with a crap load of tabs open in firefox (like hundreds, it happens sometimes... I feel like I have a hording issue admitting it) that thunderbird slows down. I suspect there are shared libraries that might get overloaded or threadlocked.
I'm using LibreSSL - I changed over when I installed LetsEncrypt on my web servers. It is definitely something to note in the bug report, good insight. It has been in place for months now and only very recently has TB started throwing the weird cert error, so it isn't the only issue, but might be a less tested/validated config.
I'll follow up with the bugzilla link and enable logging now.
Thanks again!
-David
bugzilla link: https://bugzilla.mozilla.org/show_bug.cgi?id=1452154