Android devices with DoT configured; interaction with new default chain

Not yet in dehydrated... (but option is in the --help of the latest git version)

1 Like

I'm really suprised the DoT stack of even recent Androids have this issue.. :confused:

I'd guess that there is a quite old (ancient?) OpenSSL-version in use.

I'm not surprised. The certificate validation of DoT on Android is somehow different from other validations as it also ignores user installed CAs. Sign in - Google Accounts

1 Like

The github version of dehydrated has a working --preferred-chain option

1 Like

Just edit crontab:

certbot renew; sed -i --follow-symlinks '61,$ d' /etc/letsencrypt/live/XXXX.XXX/fullchain.pem

Unfortunately, this solution is very fragile, since it depends on the cross-signed certificate starting at a very specific line offset in the file. That won't always be the case.

1 Like

And the cut might actually come after certbot is all done which it might have already restarted the web server which would use the longer file.
[and then the file would get cut]

Is this really needed now when the old DST root has expired?

There are still two possible trust paths to choose from. [there were three]
If both work for you, then it won't matter,
But if only one does work, then you may still need to specify that one path until such time that is the default path or the only path left.

1 Like

@Forza The chain which chains up to DST Root CA X3 is still the default for older Android compatibility, so unless LE decides to drop support for that by changing to the current alternative chain: yes, you need to use --preferred-chain if you don't want a chain chaining up to DST Root CA X3.


Yup [ALL DEVICES] Private DNS broken with Let's Encrypt even on new devices | XDA Forums


I don't use DoT on my Android device but use Cloudflare Warp+ For Teams VPN and that seems to work fine as far as I can tell.

I don't believe cloudflare uses letsencrypt for this. So, They didn't run into this problem to begin with.

1 Like

Hi, This problem has came back today. I had regenerated the certificate with ISRG Root X1 as the preferred chain. It worked just fine for 2-3 days and now android reports, "Couldn't connect" errors and in wireshark captures, I see, Unknown CA errors.

openssl s_client -connect

Certificate chain
 0 s:CN =
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
Server certificate
subject=CN =

issuer=C = US, O = Let's Encrypt, CN = R3

No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
SSL handshake has read 3221 bytes and written 378 bytes
Verification: OK
New, TLSv1.3, Cipher is TLS_CHACHA20_POLY1305_SHA256
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
Post-Handshake New Session Ticket arrived:
    Protocol  : TLSv1.3
    Cipher    : TLS_CHACHA20_POLY1305_SHA256
    Session-ID: C65E4A4EBC55D32A3128250AB920F2BAD515AFE3287EB3EB0EB2D542C0188595
    Resumption PSK: 386E120A8BBC5B45F038DD9ADE5BA9640A142CFC43190C547E0272CF0B8D8010
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 604800 (seconds)
    TLS session ticket:
    0000 - 63 fc 63 41 51 8c 5e 40-8e 45 5b 01 50 c9 11 47   c.cAQ.^@.E[.P..G
    0010 - 68 06 65 12 17 d7 8b a3-6e fb 70 d2 da e3 6a 0a   h.e.....n.p...j.
    0020 - aa 00 06 64 27 86 c4 fe-ee 60 08 85 64 53 a5 6c   ...d'....`..dS.l
    0030 - 53 0f a8 1a 66 e6 a4 e3-d7 f8 65 2b a6 17 a9 6e   S...f.....e+...n
    0040 - 9f 0d b2 ac df 54 2a 95-5a 96 f8 e4 db c6 af 11   .....T*.Z.......
    0050 - 8d 6d ca b4 e7 75 9b 28-b8 c3 df ab f8 5f 32 81   .m...u.(....._2.
    0060 - 17 72 dd 5f 52 27 88 af-a2 65 15 93 cc e5 e4 0d   .r._R'...e......
    0070 - d3                                                .

    Start Time: 1633315752
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
read R BLOCK

Those are two different FQDNs that resolve to very different IPs.

It seems ironic that compatibility "hack" for older Androids breaks (DoT) on all Androids. (And BTW, also some GnuTLS versions won't let it pass.)

So.. to summarize this...
Is this a bug in Android?

(I've tried to post it today on /r/android as well, was deleted in 2-3 Minuten on grounds of being a "help request" - which it wasn't.)

1 Like

Hi, that certificate is valid for multiple domains. image

And it did work perfectly fine for a day or two and now it's not working anymore.

1 Like

I rebooted the machine on Linode, Rebooted the Raspberry pi(This certificate is used by adguard home instances on linode and Rpi) and rebooted my phone and now it works again.

1 Like