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.. 
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?
@Forza
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.
2 Likes
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 dns.ishan.pw:853
CONNECTED(00000003)
---
Certificate chain
0 s:CN = ishanjain.me
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
-----BEGIN CERTIFICATE-----
MIIFVjCCBD6gAwIBAgISBKwDKsUiH4BsKB1cAoJoHrQOMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTEwMDQwMTQ4MDNaFw0yMjAxMDIwMTQ4MDJaMBcxFTATBgNVBAMT
DGlzaGFuamFpbi5tZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALsy
d2HcWJBcF5NNwXHOqSLumPH8rGwJSmjKWoGdLf/BPSgUOd8NCKutKFXiy+okmvWH
e+//vnqAvvqP3Y2WdKKvF0wgSsy7csdKqtaxch0wGCqjlj9vRNSMNYRy6rxd1qWO
psP05OAx8qK5XuYZVrEGsqJd9XAYh+1gtOvm8iWjLVtNcUAKqZBVBeUb4aiK/3IB
fmWlUV3RFXCSERV6YHEBkG6cpNYvg1YXV1so1aqsWhmTUPvja3kvjApBaMrPjWQ9
DnTUxCvFAJ9HTdFy/JqSfXp3JutUApcdFuAMv66rvnaaCh1q9502uVlRHdAQsYIO
RklLU1lZ2f0V3vIyOlsCAwEAAaOCAn8wggJ7MA4GA1UdDwEB/wQEAwIFoDAdBgNV
HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4E
FgQUTnrwrvTyRXswvgkm1JG5Ll2zcocwHwYDVR0jBBgwFoAUFC6zF7dYVsuuUAlA
5h+vnYsUwsYwVQYIKwYBBQUHAQEESTBHMCEGCCsGAQUFBzABhhVodHRwOi8vcjMu
by5sZW5jci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6Ly9yMy5pLmxlbmNyLm9yZy8w
TQYDVR0RBEYwRIIOKi5kbnMuaXNoYW4ucHeCCiouaXNoYW4ucHeCDiouaXNoYW5q
YWluLm1lgghpc2hhbi5wd4IMaXNoYW5qYWluLm1lMEwGA1UdIARFMEMwCAYGZ4EM
AQIBMDcGCysGAQQBgt8TAQEBMCgwJgYIKwYBBQUHAgEWGmh0dHA6Ly9jcHMubGV0
c2VuY3J5cHQub3JnMIIBBgYKKwYBBAHWeQIEAgSB9wSB9ADyAHcA36Veq2iCTx9s
re64X04+WurNohKkal6OOxLAIERcKnMAAAF8STN7twAABAMASDBGAiEAibkDAO2J
lX6uFyea9Y7TBew1zaRo3E2IbJPJOY6dMCECIQDFGeqSNaP9kDn+PCd/w7rUO/7+
IbBsSAVF8LATrkNgqgB3AEalVet1+pEgMLWiiWn0830RLEF0vv1JuIWr8vxw/m1H
AAABfEkzfBkAAAQDAEgwRgIhAIofCyv/4VNGqfHA8si80cfjT/kAaS+lr5jyv2hA
MX/oAiEA2TyacluvOiqJAZjcKdjBBv9xcawDUXFAqReIZkS7fZ0wDQYJKoZIhvcN
AQELBQADggEBAB/E0KgbmgqtVIgb8+FtL3aKi+vgojjtILuQwCcZ6WqeHu8TMF7w
lD63q6WpIQNl5qWvVRYfvd3GzwiC0KjGbMJAFPS8ZZYgzQii8PiS6Zg2FDMNJkAQ
YqHDq4y8OBMjLtEkcN4lqwC+ni6t3eeyZS6gibj0/4QKb4THPGAM2kZqePLpX6WB
OSohr/QR2EhjpoN42tW7xH5NCj2XlTb/qYSIDKzCahV74HgQec3A08aW6YCEgx9K
GIU3zwPNPYj8+ocgdghTUsevUymLj4GKT6T5DNagrgEtLeuO5dZXeQSaQAETFMDO
WnLR1BZJAndA9bE3cQuxukIr6J0Q9wSdkyk=
-----END CERTIFICATE-----
subject=CN = ishanjain.me
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:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_CHACHA20_POLY1305_SHA256
Session-ID: C65E4A4EBC55D32A3128250AB920F2BAD515AFE3287EB3EB0EB2D542C0188595
Session-ID-ctx:
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
closed
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. 
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