Connecting to mail server from Kindle Fire HD 8 (10th gen)

Help
1

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: mail.cooperjr.name

  • 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 7.3.2.7.

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[31079]: 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. :confused:

My web server is (include version):

  • postfix-3.7.2-4.amzn2023.0.4
  • dovecot-2.3.20-1.amzn2023.0.1

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.)

So summary:

  • 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 -starttls).

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.

3 Likes
2

What's the current date on the tablet?

4 Likes
3

Thank you; I did check that, and it does have the correct date, time, and time zone.

2 Likes
4

some thoughs

  1. could you give apk of whatever mail app kindle uses?
  2. try making a webserver in mailserver's cert and try connect it with its internal silk browser so it may give better error?
4 Likes
5

I know this is the most generic IT question, but: Have you tried restarting the Kindle* and clearing any kind of caches/temp data (where offered to do so)? There's lots of caching involved in these stacks and something may just be stuck on the device.

*A full restart. These devices like going to sleep without actually rebooting their kernels.

4 Likes
6

The two things i noticed:

  • one has CT for google, the other cloudflare
  • the newer one is showing as revoked

Did you just revoke it?

Does the fire os not respect cloudflare?

4 Likes
7

I'm not sure how I'd do that. It's built into the system; I don't even know how I'd find a version number for it separate from the OS as a whole.

I may give this a go later in the weekend. Since it seems to work when doing imaps over 993 (that is, when doing a TLS connection straight from the start), and not when doing STARTTLS (for imap or smtp), it makes me think that it would work. But it does seem like something to try.

Now that is a brilliant plan, and no, I somehow hadn't tried it. That's exactly the kind of simple advice I was hoping I would get. But now I have tried it, and it didn't help. Was definitely worth trying, though. It could definitely be something weird about this particular device, where the old cert is just cached as working somehow somewhere and anything new isn't for some reason.

I don't see anything obvious along those lines, but I'll dig around and see what else I can find. I suppose if I get really desperate I might try a factory reset, but I'm not quite that desperate yet.

Yeah, I did notice that they used different CT logs, but I tend to really doubt that the mail app would check that. I thought it was just a Chrome/Safari web browser thing.

I tried saying it before, but yes: The June 11 cert I revoked (because that way via the magic of checking ARI my client would automatically replace it :wink:); but I see the same behavior with the June 29 cert, as what I had seen with the June 11 cert before revoking it.

4 Likes
8

Okay; I found the mail app info; it's version 1.0.202184.0-fireos_2062696010, and clicking the "clear cache" button in it didn't seem to affect anything. I may try the "clear storage" a little later.

Thanks everyone for giving this a go; I know it's kind of obscure for this forum but I figured it couldn't hurt to ask.

6 Likes
9

Have you tried connecting via the common name?
Have you tried only serving one cert?

4 Likes
10

Yes, behavior is the same whether I use the CN or any of the SAN.

You mean, only the leaf and not sending the intermediates?

3 Likes
11

You mentioned having two certs.
I mean...
Using only one cert within the entire system.
[as a test]

4 Likes
12

So this is the weird bit. I loaded the page and the revoked Cert showed as not revoked, so I assumed I was looking at the wrong cert. I walked the dogs, came back and clicked again for a second lock, and it was now revoked on one line. That was odd, so I hit reload, and it was now revoked on two lines. I never clicked on the other link (checked with browser history - just the same one 3x) so I assumed you had just revoked it in real time. Super weird, right?

4 Likes
13

Well, dovecot only knows about the one. But, as a test inspired by your suggestion, I tried changing dovecot to serve the current RSA cert instead of the ECDSA one, and I get the same behavior on the tablet of it not being able to connect to it.

And then, aha, I tried the April 11 RSA cert. And it also doesn't work. So it does seem likely to be something along the lines of "tablet not having seen the cert before" rather than anything actually related to the certificates themselves.

Really, crt.sh is broken more often than it's been working lately. Perhaps I should have just attached the pem files directly rather than linking there. :slight_smile:

4 Likes
14

Did you perhaps in the past accepted an override for your April certificate in the affected mail client? And forgot that one gave you trouble 2 months ago? :stuck_out_tongue:

Not sure why such a thing would be necessary though, as Fire OS 7 seems to be based on Android 9, which should include the X1 root your cert is chained to..

3 Likes
15

I'm pretty sure that it all Just Worked the way it was supposed to until a couple weeks ago. (And even when I hit the "OK" to accept anyway, it just pops up the same message again, which is a bit weird even if it were just a matter of not trusting the root.)

And yes, in Settings / Security & Privacy / Credential Storage / Trusted Credentials, I do see ISRG Root X1 in there like I would expect. (And ISRG Root X2 isn't in there, but with the cross-sign being served I think that should be alright, and at any rate shouldn't have changed.)

I also clicked the "Clear Credential Storage" thinking that it might clear out some kind of cache, but doing that didn't seem to change anything either.

Interestingly, in the built-in "Silk" browser, I can visit both https://valid-isrgrootx1.letsencrypt.org/ and https://valid-isrgrootx2.letsencrypt.org/ without error, even though the isrgrootx2 site wouldn't be serving the cross-sign.

3 Likes
16

I don't have any issue opening that site on my Chrome either, Chrome builds a chain to X1 all by itself (probably cached X2-signed-by-X1 somewhere).

Further: no additional clues to your issue, sorry..

3 Likes
17

Just to close this out: Seems all I needed to do was delete the account from the mail app, and then add it again. Not sure why it broke or why that would fix it, though it seems like something I would have thought to try earlier.

Thanks everyone for giving it a look.

7 Likes
18

Well, that's just weird...

2 Likes
19
5 Likes
20

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.