Thunderbird broken with new cert

Help
1

I have 2 mailservers. One is an SMTP (outbound) server the other is an IMAP/POP3 inbound server.

I've been having problems with a brand new iphone accessing it. In doing some testing I found more problems with older Thunderbird accessing it. Newer Thunderbird is able to send authenticated SMTP no problem via TLS but not able to read incoming mail via POP3 over SSL. Non-authenticated connections work. The problem started after the DST Root CA X3 certificate expired.

I tried deleting and recreating the certs from scratch and that did not help

Running the following test:

openssl s_client -showcerts -connect clientmail.pdxclouds.net:995

I get the exact same certs handed out in the same order (the server cert and the intermediate cert and the root cert) as handed out by the authenticated SMTP server.

I manually added the ISRG root certs in the older Thunderbird and deleted the expired DST root CA cert but that does not help with either sending or receiving mail. When looking at the older Thunderbird complaint it seems to by trying to favor the old expired DST root. I'm willing to assume the problem is just bugs in an old Thunderbird version for now.

The new version of Thunderbird I'm testing with has the ISRG Root X1 and R3 certs in it. It unfortunately has garbage generic errors on the POP3 but it has zero errors at all on sending, and it sends fine over SSL.

I went to the following test website:

https://www.immuniweb.com/ssl/

and tried testing the POP3 server and the only error message I got was a complaint that
"Server sends useless certificates" I got the same "error" when using this site to test the SMTP server.

I tried testing the SMTP server with //email/testTo: sending to postmaster@smtp.portlandia-servers.com and it comes back all green (same as Thunderbird I guess)

Certs were generated with certbot 1.0.0

I have zero problems with using a self-signed certificate on this and zero problems with using a commercial certificate from Namecheap on this. I decided to switch from Namecheap to LetsEncrypt 6 months ago and everything was perfectly fine and worked well. Until this DST cert expired.

The only thing I can assume is going on is it APPEARS that the ISRG root CA cert is cross-signed with that expired DST cert - or perhaps the intermediate R3 is still cross-signed with that expired DST cert - and that's screwing everything up. But I am not a certificate expert.

Followup:

Never mind!

The problem with the old version of Thunderbird was fixed by going into the Certificate Editor and clicking on the tickboxes for the R3 intermediate certificate Edit Options and allowing it to be used for email encryption.

I don't know exactly if doing that "fixed" it or instead caused Thunderbird to rebuild it's certificate chain or whatever, but that took care of it. I SUSPECT that Thunderbird cached the DST certificate and even me deleting it didn't delete it from it's cache, but messing with the R3 cert caused the Thunderbird certificate cache to be flushed. Or something. I'm not a Thunderbird expert and frankly I am sick of it's "here I'll misconfigure that for you" ways but a lot of people use it.

As far as the NEW version of Thunderbird, I realized that was never actually broken I just had a typo in the config.

2

Hi @Ted, welcome to the LE community forum :slight_smile:

I'm glad to see that you've got it all going now, but:

That could use an update.

You are serving a trust root path that might not be needed (unless you have old Android systems connecting):

 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
3

That's the problem, I don't know what users will be using to connect to the mailserver. That's why I test with old software.

4

hmm...
How would email clients that can't connect alert you of their problem? (their email system is down)
If you're having trouble with your telephone system, please call us at: (ROT)FL-MAO!
[I suppose you have a contact form on your web site]

If you really have to support both old and new...
Then I can only think of two choices:

  • use two FQDNs for email:
    for older clients: FQDN1.EXAMPLE.com (old chain)
    for newer clients: FQDN2.EXAMPLE.com (new chain)
    [thus serving the two different chains]
  • use an alternate FREE CA (instead of LE - until this problem is behind us)
5

"How would email clients that can't connect alert you of their problem?"

The phone number for the service is on their invoices, the website, their setup emails, etc. It hasn't changed since 1998.

"use two FQDNs for email"

Actually there's more than 2 FQDNs for the mailservers. pdxclouds.net and portlandia-servers.com are special use domain names. The pdxclouds.net domain name is specific to SSL connections to the mailserver. The primary names used for the server aren't in the certificates since originally most users used unencrypted connections and when I decided to offer SSL I decided to use different domain names for SSL. There's still a lot of unencrypted connections from people using desktops since that isn't a security risk for those.

I'm not sure what you mean by the "old chain" and the "new chain" The old chain terminates in a CA cert that's expired. There's no point in handing that out. The new chain is the only chain.

The primary issue is mobile devices, phones specifically. I get the occasional call from win7 and old MacOS but anyone calling in with that I can tell them either upgrade their OS or use the unencrypted ports. The Thunderbird developers are di cks because they don't use the Windows certificate infrastructure but at least their upgrades are free so you can tell customers "upgrade" and their current versions have the ISRG root in it.

The phones are a different issue. Besides the fact that by definition a phone is sometimes used on wifi networks where you never know who's sniffing in, and it wouldn't be safe to have them use the unencrypted ports, the newer phone mail clients throw hissy fits if you try to set them up to use unencrypted ports. You can't just tell someone to upgrade the OS on their phone.

I haven't tested yet on an older Android or Iphone that lacks the ISRG root CA. But, with older Android and Iphones, their email clients EASILY allow the users to "accept an unknown certificate" I USED to use that trick a LOT when I first deployed SSL because I used self-signed certs - older iphones and Android phones had NO PROBLEM accepting self-signed certs.

Unfortunately, probably due to political pressure from the major CAs who saw self-signed certs cutting into their profits, both Google and Apple started making their more current phones become extremely pis sy in accepting self-signed certificates. Fortunately, the newer phones USUALLY do things properly as long as the server is setup "by the book"

As for using an alternate Free CA - forget it. LE is sort of like the international root DNS servers. They got there first and they provide a free service. For a LOT of reasons it is BETTER to have a SINGLE authority in that position. I don't use "alternate roots" because if there's a problem you will never know if it's something screwed up in the alternate root or not. You can be pretty sure the major roots are NEVER screwed up or if they are then they take everyone else offline so you don't have people blaming you for incompetence because you used some oddball root nobody use uses. The same exists for SSL certs. The reality is the "free SSL Cert" infrastructure is still pretty new and new isn't always accepted that readily. If I use LE then if LE screws up there's so many other people using them that it's likely many other people are doing the same thing I'm doing so there's going to be screaming about it and thigs get fixed. If I use some other free CA then if they screw up then I might be the only site affected by their screwup and who knows if it will ever get fixed.

So no, I'll stick with LE for now. If they screw up badly and stumble and fall and some other free CA replaces them - then I'll switch to that. Otherwise I'll be using the 600 pound gorilla in the room. You can experiment with the 20 pound monkey in the corner if you want.

6

Well actually there were three chains; Today only two are left.
One (the default) does terminate with an expired cert. ("old chain")
But that is being used explicitly to serve really old Android clients that don't look at the expiry of root certs.
Any newer clients should pass trust validation when they reach "ISRG Root X1".

Since you are using multiple FQDNs, you might consider using the "old chain" on some and the "new chain" on others.

And I do love your... loyalty.
I only mentioned the other FREE CA possibility because it does exist - I never said I promote doing that.

7

I do like the comparison between LE and other (semi-)free ACME CA's :rofl:

8

The really old android clients allow you to ignore the validity of the SSL cert when setting up the email client, during the setup it asks if it's OK to do it. So for an email client on an old phone, it's a non-issue you don't even need that expired cert. And I will point out that the browser is so bad in an old Android client that it won't render 99.99% of the websites out there of any complexity at all so it's unusable anyway.

I think you guys think you are helping the old droid clients by keeping that cross-sign in there but the fact is you are doing absolutely nothing other than cluttering up the chain with junk. That's why the immuniweb.com test is saying "server sends useless certificates" Perhaps before you decide what's best for old android users you might try actually turning on an old android client yourself, next time, and testing to see if the cross sign is actually needed, instead of just guessing??? (assuming you didn't drop your last old Android phone in the toilet by accident, ha ha) I have one of these in my test set and have written android apps for old droids, one of which is in the playstore.