I have got a fun one that's been bugging me for days; maybe someone here can help me figure this one out.
My domain is:
- Not running a web server
- Running Dovecot imap on 143 (STARTTLS) & 993 (imaps)
- Running Postfix SMTP submission on 587 (STARTTLS). (Postfix is also running SMTP to receive mail from the Internet on 25, but that's not what I'm having trouble with.)
Also worth noting: I get both an ECDSA P-256 certificate (signed by E1 as my account is on the allowlist), as well as an RSA certificate (for mail compatibility), but it's only port 25 that's configured to serve both. Dovecot, and Postfix over 587, only serve the ECDSA cert.
To be clear, this is my personal mail server, that I'm trying to connect to using my own device.
I ran this command: Ever since my certificate renewal on June 11, attempting to read mail using the built-in mail application on my Kindle Fire HD 8 (10th generation), running Fire OS 188.8.131.52.
It produced this output:
When refreshing mail:
Unable to open server connection (cooperjr.name)
When trying to set the imap server in settings, pointing to 143:
Connection Security Warning: There is a problem with the server's security certificate (it is self-signed, expired, or has a hostname mismatch). Would you like to trust it anyway? Note that even if I click "OK" here to trust it anyway, the dialog just shows up again and again each time and doesn't seem to actually trust it anyway.
When this happens, here's the log from dovecot (though I redacted my home IP):
2023-06-29T23:34:12.788174+00:00 setzer dovecot: imap-login: Disconnected: Connection closed: SSL_accept() failed: error:0A000416:SSL routines::sslv3 alert certificate unknown: SSL alert number 46 (no auth attempts in 0 secs): user=<>, rip=[redacted], lip=172.31.10.117, TLS handshaking: SSL_accept() failed: error:0A000416:SSL routines::sslv3 alert certificate unknown: SSL alert number 46, session=<WStEI03/GoZEuX2T>
Similar problems happen when connecting to SMTP submission via 587.
Interestingly, connecting to imaps over 993 does work.
web server is (include version):
The operating system my
web server runs on is (include version): Amazon Linux 2023 (2023.1.20230629)
My hosting provider, if applicable, is: AWS EC2
I can login to a root shell on my machine (yes or no, or I don't know): Yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No
The version of my client is (e.g. output of
certbot --version or
certbot-auto --version if you're using Certbot): A custom client, using the @root/acme library 3.1.0. I've got information on an older version of what I did written up on my blog, and can give more details about my current code if needed, but I don't think the problem is with the certificate acquision.
So this has been working fine for a long time (got the tablet Christmas 2021 and haven't had any problems with it until now), and I noticed the issue when my June 11 renewal happened. I originally thought it must be a coincidence and the tablet did some sort of update around that time too, but no: If I revert the certificate to the one that was issued on April 11 (which still has a couple weeks left of validity), everything works. Note that June 11 is before the recent policy identifier change, so I don't think it's related to that. Thinking that it might just be some sort of weird fluke with that certificate, I did try to issue a new certificate last night (June 29 UTC), but I have the same symptoms with that. (I also revoked the June 11 certificate as part of the process of getting a new one, which is probably just going to confuse things at this point, but be aware that I had the symptoms before I revoked it.)
- If server uses the certificate issued on April 11, it works when connecting from the tablet
- When server used the certificate issued on June 11, it did not work when connecting from the tablet (and I've since revoked it which I'm sure is just going to confuse things)
- If server uses the certificate issued on June 29, it also does not work from the tablet. (Link there goes to the precert as it doesn't look like crt.sh has caught up with the actual cert yet.)
I can reproduce or fix the problem by switching the server between using the April 11 and June 29 cert, so there's something that must be different between them but I can't tell what. (Other than the June 29 cert no longer has the additional policy info which was removed on June 15 but I don't think is related to anything here.) In both cases I'm serving the same E1-signed-by-Root-X2 and Root-X2-signed-by-Root-X1 chain alongside the cert (at least as far as I can tell by running
openssl s_client with
I'd be happy to make an imap/smtp login for any regulars here if doing so would be helpful in diagnosing, but I'm guessing that wouldn't actually be needed. It's currently serving the June 29 cert, but I can switch back and forth if someone wants to look at that behavior.
In addition to this tablet, I connect to the server using Thunderbird on various flavors of Windows, which continues to work fine regardless of which certificate. (Well, unless I have OCSP checking turned on and using the revoked one. But that would be as expected.) And I've been getting mail from the Internet just fine via port 25 as well as far as I can tell.
I'm pretty stumped on this one and would appreciate whatever guidance people can give on exactly what is going on here, and what the difference might be between the certificates that work and the newer ones that don't, or what weirdness this tablet might be doing.