Different SSLException Handling on Android 12 and Greater?

I’m reluctant to post this here b/c I’m relatively certain this is an Android generated question and not a problem with K-9 which I’ve been using for around a decade.

For a lot of that decade I’ve been running my own email for my vanity domain with the mailboxes hosted on my home gateway device running some flavor of debian with dovecot. After the most recent upgrade of that gateway device, I discovered an issue with the self-signed certificate.

Background - the phone I’m currently using came out of the box with Android 11 and subsequently updated to 12. When I put this device into service I had no issue storing the self-signed certificate exception on Android 11. Now I simply get an error:

Setup could not finish
Cannot connect to server.
(Unable to execute POP3 command).

With the options of ‘continue’ and ‘edit details’.

Same version of K-9 on last phone I was using (no Android 12 support) gives the usual warning and prompt to end the session or store the exception.

I know this isn’t a K-9 issue, just curious if anyone else has experienced this. I wonder if something changed with SSLException handling depending on whether the phone has some kind of physical security (unlock code, etc.).

I know that I can ‘fix’ the problem by setting up certbot on the dovecot box, but I’m a bit paranoid that Letsencrypt might be a trap that I’d rather not get caught in. I suppose my other option is to create a CA and install it on the phone manually, but just looking for the path of least resistance.

I (mostly) fully understand the security risks presented by using self-signed certificates. I always initiate the certificate acceptance session over a private network which I control, so there’s little exposure to a mitm vector. I’m not securing state secrets either. I just want things to work like they used to for another 10 years. After that I won’t need email on my phone.


There is no good reason not to be running an LE certificate on your dovecot.

While you are trading in the old and busted for the new hotness, you may want to lose the

in favor of IMAP. The only risk you run is being upset with yourself for not having switched sooner.

1 Like

I have my reasons. I won’t bother justifying them to you because they’re my reasons.

I also see no point in running ssl on websites that don’t actually need it.

I’ve been down the imap rabbit hole and didn’t find it very flexible. I’ll be using pop3s for the rest of my days.

Why post an off topic screed here when you

and you already know all the answers and have immutable secret opinions?

Dovecot, as you well know, is not a website and all email definitely needs TLS.

I don’t understand how you can see a painfully limited protocol like POP3 as more flexible than IMAP, and, honestly, I don’t particularly want to. POP3 is uniquely unsuitable for use with mailboxes used on more than one device. (I mention that not for your benefit, but rather that of the unsuspecting reader who has not yet discovered this firsthand.)

Kudos to you for the S at least.

Now you just need to work out whether or not to roll your own CA. I’ll risk another dismissed suggestion and offer my endorsement of XCA to use if you decide to go that route.

Whatever you settle on, I hope it works out for you, even though it’s definitely not the way I would do any of it.


Because I was looking for confirmation that handling SSLExceptions changed with an Android update.

It was meant to further demonstrate my unwillingness to do what everybody else is doing just because Google tells them they need to.

That’s your opinion, and I respect it. But I don’t necessarily agree with a blanket statement like that. There’s still an awful lot of email traversing the interwebs over port 25 unencrypted. It’s a lot like ipv4, it just won’t ever go away completely.

It’s not the protocol I find unflexible, it’s mainly the client side of the equation. I use email the way I use it, and keeping all my eggs on the server is not my preference. Much in the same way I prefer to drive cars that have thee pedals in the driver’s footwell - it’s not for everyone and I’m not suggesting it should be.

That’s neat, but I already have all the necessary tools available to me in /usr/bin/openssl. Why overcomplicate things with a GUI?

That’s all the reason I need.

If you really insist on using POP3, I recommend looking for another email client, not K-9. You can’t export or move the emails from K-9, so if they are gone from the server and you want to switch phones, they’re gone.

I’m fully aware of that and it’s of zero importance to me. I store my email elsewhere. Having a client to read and on occasion reply with a baby computer (phone) is a convenience. When I want to do real things I use a grown up computer, with a keyboard that has real buttons.

[trying to move this forward - because i don’t see any imap/pop cause for this and there are many very valid reasons to use self-signed certs … ]

what shows in dovecot logging?

i’m using rhel/centos for my OS, so some things may be different, but in my:


configuration file there’s an option setting of:

#Show protocol level SSL errors.
#verbose_ssl = no

the default, in my environment, is “no”. you might want to turn that to “yes” to see what it shows.

also, what release of K9 are you using - and did that change when you updated the device? i believe that there was a change in self-signed certificate handling in K9 a bit ago, don’t remember exactly when.

as a note, i have two android 14 devices, both on K9 6.711. one has been using my self-signed cert for some time. the other won’t accept it even when i tell it to at the prompt.

1 Like

Finally someone who doesn’t drink the LE kool-aid!

The version currently on the play store - 6.603. I tried older versions going back to 5.x with the same results. This is why I suspect it’s an issue that was introduced by an API change.

This is what I get without verbose_ssl:

dovecot: pop3-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=, lip=x.x.x.x, TLS handshaking: SSL_accept() failed: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown: SSL alert number 46, session=<XXC6vm8KOrnAqBho>

I did try with verbose_ssl and it lead me to no better conclusion except the client is ending the TLS negotiation with reason 46.

I haven’t tried older versions of K-9 on the Android 11 device, but the same 6.603 gives the warning and stores the self-signed exception.

I’m accepting the fact that I just need to create a CA or use the one I’ve already created for openvpn and go on with life. I have no need for a phone that costs more than $100 so I don’t see Android > 12 coming my way any time soon.

[my dovecot server is internal-only. so, as long as clients let me accept self-signed certs, it’s not worth the hoops to get LE certs to it.]

that’s the error that i’m getting on my device that won’t accept the cert. haven’t tried to address it yet. my cert has expired, which likely doesn’t help.

see bottom note by Aki (one of the dovecot developers) at:

SSL errors after certificate renewal

you can use the links at the bottom of that page to go back on the message chain. the one immediately previous is useful.

i suspect that the android update included changes to SSL handling - making it pickier on what it will accept. not certain why you’re not getting the cert accept/reject prompt.

I’m pretty sure I came across that mailing list discussion yesterday, but didn’t see the previous message. That’s a pretty elegant explanation of chaining to the uninitiated. This is a complex subject and I seem to only delve into it often enough to maintain a remedial understanding of it. Oh well, what doesn’t kill us only makes us stronger, right?

Whatever the case, this isn’t a chained cert, it happens with the simple snakeoil cert that’s auto-generated during debian os install. Though I typically re-generate it with a 4k keylength.

Nonetheless, thanks for the intelligent discussion.

i realize that it’s local, not chained, but the discussion may help some.

is your cert current? that might also trigger something like that. [i’m going to update mine in the next couple of days to see if that resolves my issue.]

If your cert has expired or the date/time is set wrong on one end that can be a problem.

But mine aren’t expired. I signed one yesterday that’s good until 11/17/2033.