The github version of dehydrated has a working --preferred-chain option
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.
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.
@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.
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.
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.)
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.
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.
Yes, my understanding is that it's a bug (or incompatibility) in Android's DoT stack.
I'm at a loss. Where can someone like me (simple user) post android bug reports?
While fixing this eventually on Android side will be nice, I don't think it can really address the immediate concerns. For that I'm afraid that DoT servers will just have to switch to a different chain (old Androids didn't have built-in DoT anyway).
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.