Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Since 31.8 or 38.0 it seems impossible to use self-signed certificates!

  • 11 replies
  • 5 have this problem
  • 99 views
  • Last reply by fjl_london

more options

What's going on? In 31.7 and earlier, using a self-signed (and even expired) certificate worked as long as you understood the scary warning and added an exception. Nothing I've been able to do with 38.0 (and now 31.8) can make it add an exception for a certificate. And when a machine is "upgraded" to 38, the exception previously in force is lost.

And to add insult to injury, the error message the user sees implies that it can't contact the server (i.e. doesn't even mention its not happy about the certificate - I figured this all out from log files).

I'm *assuming* it's self-signed that t doesn't like. I note that 512-bit certs were dropped but mine have always been 1K.

If anyone wishes to look at an example of the certificate on quiestion connect to smtp.fjl.org.uk:465. It works with every release up to 31.7.

Thanks, Frank.

What's going on? In 31.7 and earlier, using a self-signed (and even expired) certificate worked as long as you understood the scary warning and added an exception. Nothing I've been able to do with 38.0 (and now 31.8) can make it add an exception for a certificate. And when a machine is "upgraded" to 38, the exception previously in force is lost. And to add insult to injury, the error message the user sees implies that it can't contact the server (i.e. doesn't even mention its not happy about the certificate - I figured this all out from log files). I'm *assuming* it's self-signed that t doesn't like. I note that 512-bit certs were dropped but mine have always been 1K. If anyone wishes to look at an example of the certificate on quiestion connect to smtp.fjl.org.uk:465. It works with every release up to 31.7. Thanks, Frank.

All Replies (11)

more options

Then your certificates are to small, the "dropping" raised the bar to 2048.

more options

Matt said

Then your certificates are to small, the "dropping" raised the bar to 2048.

Thanks Matt - this has been driving me and others nuts. It's not like I haven't checked the release notes; if its there I must have missed it. Would you say that not producing a diagnostic message as to why it won't connect counts as a bug? At a guess the SSL code is imported from elsewhere and getting the diagnostics back to the application may be difficult, but the generic "server unavailable" message confuses the hell out of everyone.

I've yet to test this works; will report back.

more options

I originally blogged on the subject in July http://thunderbirdtweaks.blogspot.com.au/2015/07/logjam-and-thunderbird.html

Wrote a support article. last month https://support.mozilla.org/en-US/kb/thunderbird-and-logjam

The security researchers made the vulnerability public in May. https://weakdh.org/

Is essence, while Thunderbird not exactly doing a sterling job telling you, the issue is really a server administrator has not patched their server in a timely manner. In May the researchers estimated 8.4% of IMAP servers were affected. By October, I really wonder if that had changed much at all. It should have. But did it. That is something I will never know

more options

Thanks Matt. Whilst I'm actually not bothered that a nation state can break a 1024-bit cypher, I took your advice and upgraded from 1024 to 2048 bit keys in spite of the hassle to all involved update them at the client side.

Unfortunately, still no dice.

The first time I try to send anything (SMTP) it returns *instantly* with an alert that says "Sending of the message filed <- The message could not be sent because the connection to Outgoing server (SMTP) xxxxxx timed out. Try again". Eh? A 10ms timeout?

So I try again and get the same, except the diagnostic is ".... for an unknown reason. <- Please verify that your Outgoing server (SMTP) settings are correct and try again". Basically, exactly the same as with the old 1024-bit certificate. 31.7.0 works fine with the new ones, incidentally.

As you can see, the quality of diagnostic information is a bit rubbish really. At the server end there's nothing to tell - attempted connection, connection dropped (by remote end).

Anything else I could look at?

more options

I would be looking at firewalls and anti virus programs and anything else that purported to be security. As you point out a 10ms timeout is silly and obviously a red herring in my look at things.

Anti virus products particularly often make themselves proxies so they can operate a man in the middle hack on SSL secured mail. If the proxy is not working right then Thunderbird will timeout in that sort of time frame, because it thinks the anti virus is the mail server.

You could log the connection, but that will not tell you much if it is a local proxy. https://wiki.mozilla.org/MailNews:Logging

more options

Hi Matt,

Thanks a lot for your help with this. It's much appreciated, and the problem is driving me nuts.

The "timeout" message is bizarre, but in retry it returns the "unknown" error on subsequent attempts (and quickly). I understand why you might think it's a firewall, it *might* be the Microsoft one on Windows 7 on my test machine. I've found it less weirdness prone than third-party products. But as its a transient problem I never checked or turned it off. It's not the *cause* of the problem as it affects every machine that connects to the server. There's no perimeter firewall messing with it, because there's no perimeter. The server is a straight FreeBSD box, and the problem occurs even when on the same Ethernet segment. The old Thunderbird has connected with no problem for years; the new one doesn't but when you reinstall the old one it's fine. So...

You are almost certainly correct about it being the TLS certificate. BUT I've generated new 2048-bit certs and slotted them in place of the old ones and it's not having it. The new certs work just fine with everything else too. Unfortunately this isn't available for you to look at on the Internet, but I could try and make it. I could also send you the certificates (no security problem - I can make new ones).

I'm probably doing something very simple that's stopping this form working. As it's Thunderbird-only, it looks like Thunderbird is being very picky about it. If there was a nation state snooping on my LAN I think I'd probably have noticed, so it's not like I need this level of encryption, and I note there's an add-on to disable it, but it's be really good to get to the bottom of it.

Incidentally, it barfs on IMAP and SMTP (Dovecot and Sendmail) - both using the same .pem files.

Thanks, Frank.

more options

Just thought - if you had the runes for getting OpenSSH to generate certs that Thunderbird DOES like it might be the simplest solution. I've read the guides for reconfiguring stuff (available from your useful links) but I'm not convinced that the substitute certificates I'm using are good.

more options

Changes for Dovecote here.

To quote the link Dovecot

These changes should be made in /etc/dovecot.conf

Cipher Suites

ssl_cipher_list=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA ssl_prefer_server_ciphers = yes (Dovecot 2.2.6 or greater)

DH parameters

  1. regenerates every week

ssl_dh_parameters_length = 2048


Reload configuration

sudo doveadm reload

more options

Thanks, but I'd seen that already (and tried it). It worked no better than the sendmail, which is why I suspect it's the certificates I'm generating themselves (using openssl). If I had the runes for generating a certificate that would definitely work it'd rule out a lot of other possibilities.

Thanks, Frank.

Incidentally, if anyone's reading this using a BSD system, the file is

/usr/local/etc/dovecot/dovecot.conf

and you get it to take effect with

/usr/local/etc/rc.d/dovecot restart

(Or possibly "service dovecot restart" will also work on some versions.

more options

lets just see if "I am leading you up the garden path.

try installing this add-on. https://addons.mozilla.org/en-US/firefox/addon/disable-dhe/

Yes it is a firefox add-on, but if you download it and install from the file it will install in Thunderbird

more options

Thanks Matt, I saw that add-on mentioned in your blog, I think. Not an ideal solution. I haven't checked that it works yet, but I think it very likely will.

My plan is to spend a bit more time on this tomorrow and set up a server, probably on the public Internet, and test this properly. You can then see for yourself. Right now I've put the 1024-bit certs back on the production server and all the Thunderbirds hereabouts are 31.7 ('cos I needed to get some work done).