Specific Android Apps Not Recognising Let's Encrypt

I’ve been using Let’s Encrypt successfully with my phone for well over a year, but there are two android apps that won’t recognise the certificate.

First, K-9 Mail throws an error, but allows me to accept, save, and continue. So it wasn’t a huge problem, just a minor inconvenience every two months.

But now Nextcloud Notes refuses to connect at all. Instead it throws an error saying the connection to the server is “broken”. I can’t find any way around it. CAdroid wont import the certificate since the chain is already trusted.

Is there a reason only specific apps would have trouble? I’m using Cyanogenmod 11 (android 4.4) and the domain is cloud.darksteve.tk.

Maybe those applications are using a custom trust store? You could check with the application developers.

I see that you allow only TLS 1.2 connections to your server. Have you tried turning on TLS 1.0 and 1.1 temporarily? It seems that TLS capabilites of apps on Android may be affected by API level chosen at their build time and socket options used by the developer (https://developer.android.com/reference/javax/net/ssl/SSLSocket.html).

Most likely the cert.pem file in use doesn’t contain the chain.

Other than that:
Some parts of the system seem unreasonably slow (SSL Decoder was unable to complete a scan on port 993)
https://cloud.darksteve.tk/ forwards (302) to https://cloud.darksteve.tk/index.php/login
(which gets stuck in a forwarding loop to itself)

As suspected (a quick check on) port 993 shows (details):

I thought that, but it seemed unlikely so I kinda dismissed the idea. I posted a similar question to the Nextcloud app forum about Notes so I’ll see if I get a response there.

I must admit, I didn’t try. Since K-9 said it was an unrecognised certificate but allowed me to save and continue, I didn’t think protocol was the issue,

Perhaps you’re right, and the issue with K-9 is completely different to what is impacting Notes. I’ll give that a try. Thanks!

I opened port 993, but I’m no longer using it. I switched to using STARTLS on 587 and 143. I forgot about 993! I guess I should close it all together.

Not sure about that. I’m guessing that’s a built-in redirect that Nextcloud makes on the web?

Via the web interface, Android app, Contacts and Calendar, and desktop client, there are no problems and everything works fine. It’s just that one Notes app that has issues and instantly fails.

I’m using Apache 2.4, which needs to use fullchain.pem instead of cert.pem, but I just realised I have the following in my Apache conf:

SSLCertificateFile "/usr/local/etc/letsencrypt/live/darksteve.tk/fullchain.pem"
SSLCertificateChainFile "/usr/local/etc/letsencrypt/live/darksteve.tk/chain.pem"

D’oh! I commented out the ChainFile line, hopefully that will clear up my chain fail error. I tried rescanning, but got a damn Cloudflare bad gateway error! I’ll try again later (it’s currently 4:26am here!)

But thanks @rg305, you’ve got me re-examining settings I thought I had working. I’ll go over them again when I get up.

And thanks for the suggestion @mkwm, I enabled TLS 1.0 and 1.1 and surprisingly, Notes now works!! Thanks @mkwm, I was conflating errors with settings and was thinking I had a single cause. That’s a pain, I really don’t want to downgrade my site security if I can help it. There’s no easy way around that.

Thanks everyone, your help is greatly appreciated :slight_smile: I’ll go over everything again with a clear head after a good sleep!


Why would you want to use 143 instead of 993?
Port 143 = IMAP (no TLS/SSL)
Port 993 = IMAPS (IMAP over TLS/SSL)

Apache 2.4.27 should work fine with just:
SSLCertificateFile “/usr/local/etc/letsencrypt/live/darksteve.tk/fullchain.pem”

Unfortunately the site runs on multiple independent software (Apache2, Dovecot, etc.)

You can use encryption on port 143 if you use STARTTLS. For whatever reason, the powers that be decided that once STARTTLS encryption was negotiated on port 25, the encrypted data would be sent on port 587. But once STARTTLS encryption was negotiated over port 143, the encrypted data would continue to be sent on port 143.

STARTTLS was supposed to negate the need for separate encrypted/unencrypted ports, but they chose to have a separate 587 port dedicated to STARTLS anyway!

I do have fully encrypted mail, but STARTTLS has made port 993 unnecessary.

[Edited severly]
587 secures 25 (both are for inbound emails)
143 is both secure and insecure - STARTTLS is required
993 is only secure - requiring STARTTLS
Just to be crystal clear:
port 143 can be misconfigured and allow plain/text unencrypted traffic which should never be allowed; especially over the Internet.

I don’t know what to tell you, it’s working fine in Thunderbird, Fossamail, Seamonkey, and Roundcube:

I have three domains in that one certificate, maybe that’s what you’re detecting? Only mail.darksteve has MX and the like configured. Now I really need to sleep, it’s 4:54am!

No, that is the reason for STARTTLS :wink:

You are using the telnet session incorrectly, you need to put a session identifier in every command, a letter, a number, a word, etc.:

$ telnet darksteve.tk 143
Connected to darksteve.tk.
Escape character is '^]'.
1 OK Begin TLS negotiation now.

You can also try openssl:

$ openssl s_client -starttls imap -connect darksteve.tk:143 -servername mail.darksteve.tk
    depth=0 CN = mail.darksteve.tk
    verify error:num=20:unable to get local issuer certificate
    verify return:1
    depth=0 CN = mail.darksteve.tk
    verify error:num=27:certificate not trusted
    verify return:1
    depth=0 CN = mail.darksteve.tk
    verify error:num=21:unable to verify the first certificate
    verify return:1
    Certificate chain
     0 s:/CN=mail.darksteve.tk
       i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
    Server certificate
    -----END CERTIFICATE-----
    issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
    No client certificate CA names sent
    SSL handshake has read 2909 bytes and written 564 bytes
    New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
    Server public key is 4096 bit
    Secure Renegotiation IS supported
    Compression: NONE
    Expansion: NONE
        Protocol  : TLSv1.2
        Cipher    : ECDHE-RSA-AES256-GCM-SHA384
        Session-ID: 068E3122A58B02B16133F4D460C91EF0057EBDCDD691388DD1FD88292C807F67
        Master-Key: 34113B60BC8794CA7CDBD038F15B3FB893E9164289C7024561F58E7270724547F65BBD62F1CCD56B84C87A5E8BD2D1F6
        Key-Arg   : None
        PSK identity: None
        PSK identity hint: None
        SRP username: None
        TLS session ticket lifetime hint: 300 (seconds)
        TLS session ticket:
        0000 - 13 07 82 ed 5e d4 15 f0-a1 a4 2b 7e 07 97 65 de   ....^.....+~..e.
        0010 - 2f ab ec eb b4 3b 69 77-94 f1 af 76 53 86 f8 e3   /....;iw...vS...
        0020 - 73 59 c6 27 c7 fe 91 13-cd b5 be 58 d5 e0 ed e5   sY.'.......X....
        0030 - 64 f6 7a 25 c3 74 e3 43-28 93 0d 26 95 34 66 9b   d.z%.t.C(..&.4f.
        0040 - 9c 0e 5d ec 2d 35 cd 73-3a 04 0e 6d 08 47 7d 55   ..].-5.s:..m.G}U
        0050 - 38 d9 0f 50 1d b3 26 77-7b 67 9c 54 ed 83 a1 ca   8..P..&w{g.T....
        0060 - cb bf ff 9b 31 44 65 71-dc 70 62 69 9f 09 35 da   ....1Deq.pbi..5.
        0070 - 2a 45 46 d9 be e7 43 b8-73 8b 13 24 ab 05 7a fe   *EF...C.s..$..z.
        0080 - a9 39 c2 8b 45 b2 0c 0b-22 98 7f 39 cf ae 5d 1d   .9..E..."..9..].
        0090 - 2a 25 46 93 f5 8b 0e ab-b5 eb 19 96 4d ed 58 a0   *%F.........M.X.
        00a0 - d8 5f 17 74 a2 0f 1c 3d-3b ec dd 12 b1 3e b7 91   ._.t...=;....>..

        Start Time: 1503946790
        Timeout   : 300 (sec)
        Verify return code: 21 (unable to verify the first certificate)
    . OK Pre-login capabilities listed, post-login capabilities have more.

@DarkSteve, keep in mind that you are not serving the fullchain in imap, you are only serving the cert.


1 Like

Good Lord!
I think I’m the one needing sleep!

1 Like

You might want to use “-starttls imap” not “smtp”. It looks like some older OpenSSL versions won’t work because TLS 1.0 and 1.1 are disabled. (OS X default OpenSSL fails, but a Homebrew install of 1.1.0f connects.)

gnutls-cli works fine to connect, but the server isn’t serving the chain certificate, causing a verification issue:

$ gnutls-cli --starttls-proto=imap cloud.darksteve.tk:imap
Processed 168 CA certificate(s).
Resolving 'cloud.darksteve.tk:imap'...
Connecting to ''...
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
 - subject `CN=mail.darksteve.tk', issuer `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', serial 0x042724b8c812a17da6b1b711bedf8cae8532, RSA key 4096 bits, signed using RSA-SHA256, activated `2017-08-21 15:14:00 UTC', expires `2017-11-19 15:14:00 UTC', pin-sha256="cRZWATy6Fw3K0nDTow256mMNFZVJKfMcdxL6iCeZLNQ="
 (Details removed for length reasons)
- Status: The certificate is NOT trusted. The certificate issuer is unknown. The certificate chain uses insecure algorithm.
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
*** handshake has failed: Error in the certificate.

It looks like Dovecot is being used. The ssl_cert directive should use fullchain.pem to fix this. Make sure Dovecot is restarted after making this change.

Ignore the whole different port part. 25 will work fine with STARTTLS. Opening 587 is also a good idea, as it’s useful for clients whose ISPs have blocked outgoing 25 for spam prevention reasons. (587 should require auth to send anything, though. It should not act like plain 25.)

yes, I do need sleep.

But to go over the ports, just so we are all clear:
(correct me if I’m wrong)

- - - - - - - - - - - - - -
25 inbound emails from unknown sources - can encrypt but doesn’t require encryption
587 inbound emails from authenticated sources (also used to relay) - requires encryption

- - - - - - - - - - - - - - - - - -
143 for authenticated users - can encrypt but doesn’t require encryption
993 for authenticated users - requires encryption

More or less.

SMTP can work over 25 and 587. Both ports can either do an unencrypted session or use STARTTLS which starts an encrypted session on the same port. Current best practices are to not allow authentication without an encrypted session. (Specifically, 25 is reserved for SMTP, 587 for “Submission”.) 587 should only be used for authenticated clients. I haven’t seen any servers connecting to 587 on remotes to deliver mail. There is also 465 for SMTPS, which is implicit encryption. That’s not in common use today as most clients can use STARTTLS, but often enabled for legacy configurations.

For IMAP, there’s 143 which can be unencrypted or encrypted (using STARTTLS mechanisms for IMAP). Port 993 is IMAPS, which is implicitly encrypted. Port 993 is also out of common use, but often still configured for legacy clients.

POP3 has its own ports (110 and 995 for POP3S), and it’s the same thing.


Thanks @sahsanu, I was second guessing myself about STARTTLS! But you’re also right about me incorrectly serving my cert.

At first I wasn’t sure what you meant when you said I was only serving the cert, not the chain. I checked my Postfix config, and it has:

smtpd_tls_cert_file = /usr/local/etc/letsencrypt/live/darksteve.tk/fullchain.pem

Of course I’m serving the whole chain! What are you talking about?!?! But I’m an idiot, and my Dovecot config had:

ssl_cert = </usr/local/etc/letsencrypt/live/darksteve.tk/cert.pem

D’oh! I’ve now fixed that.

Reminds me of the other day when I my car displayed the warning light saying my coolant was low… so I topped up the oil. It took me hours to figure out why the coolant light didn’t go off.

1 Like

Ok, to wrap this thread up, I’ve solved the problems. I had two apps not working (K-9 Mail and Notes for Nextcloud) but it was because of two completely independent issues.

K-9 Mail complained because I’d configured Dovecot to serve cert.pem instead of fullchain.pem. (Thanks again @sahsanu I’ve now fixed that.) I also had Apache 2.4 misconfigured with the chainfile, a hang-over from when I was running Apache 2.2. (Thanks @rg305 for getting me to notice that.)

Notes doesn’t work with TLS 1.2 and so couldn’t connect. (Thanks @mkwm for getting me to check that!) That wasn’t something I did wrong, but now I know it’s not my fault. I’ve submitted the issue to the Notes Github page.

Lastly, thanks to @motoko for clearly explaining ports, STARTTLS, how things are implemented and what’s deprecated. You explained way better than I could have!

Weirdly, Hotmail/Outlook is still configured for port 993! As far as I know, it’s the only major player still using port 993.


You’re welcome and you can add Gmail to this list:

1 Like

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