1

I'm running my own DNS-over-TLS server under my domain (dns.example.com). On my Motorola G100, which is running Stock Android 11, I can set the private DNS to this domain and it works. This works on my Linux machines, two other Androids (some Motorola on Android 10 and a Samsung with Android 10), and also on two different routers (AVM FritzBox can use DoT as upstream).

The server is not at fault, the certificate is valid and all devices work the way they should, that is, until the server is rebooted or otherwise blocked. Then, of course, I receive the notification that it "can't access the private DNS server".

The Linux machines recover and just retry to connect, as well as the routers. But the Android phones don't want to retry even when I know for sure that the connection is working.

Upon disabling private DNS and reenabling with my domain, the following log is shown (IPs removed)

09-30 19:32:46.091  1144 20197 W resolv  : Validating DnsTlsServer <MY_IPV4> with mark 0xf006b
09-30 19:32:46.091  1144 20198 W resolv  : Validating DnsTlsServer <MY_IPV6> with mark 0xf006b
09-30 19:32:46.138  1144 20197 W resolv  : SSL_connect ssl error =1, mark 0xf006b: No such file or directory
09-30 19:32:46.138  1144 20198 W resolv  : SSL_connect ssl error =1, mark 0xf006b: No such file or directory
09-30 19:32:46.138  1144 20197 W resolv  : TLS Handshake failed
09-30 19:32:46.138  1144 20198 W resolv  : TLS Handshake failed
09-30 19:32:46.138  1144 20197 W resolv  : query failed
09-30 19:32:46.138  1144 20197 W resolv  : validateDnsTlsServer returned 0 for <MY_IPV4>
09-30 19:32:46.138  1144 20198 W resolv  : query failed
09-30 19:32:46.138  1144 20198 W resolv  : validateDnsTlsServer returned 0 for <MY_IPV6>
09-30 19:32:46.138  1144 20197 W resolv  : Validation failed
09-30 19:32:46.138  1144 20198 W resolv  : Validation failed

I don't know why it tells my that the handshake fails, all other devices (or kdig +tls) can connect just fine. From the server's reboot to now, no config, certificate or software version was changed.

My guess is that Android caches the connection and "remembers" that it failed at some point in the past and doesn't even try to connect again. I tried rebooting, shutdown, airplane mode, another DoT (dns.google works), disabling DoT but nothing fixes this behavior.

2
  • Hard to guess the root cause of failure at this point without doing some network troubleshooting on device. Could be due to negative DNS caching of your server's domain. Sep 30, 2021 at 19:17
  • No, it's really the badly implemented certificate verification on Android.
    – burny
    Oct 1, 2021 at 10:12

1 Answer 1

1

Apparently, Android (even the newest versions) can't deal with the type of certificate that Let's Encrypt generates by default.

The solution is a combination from the Let's Encrypt forum and the setting --preferred-chain="ISRG Root X1" for certbot.

If you use caddy as your server, you can set it in the Caddyfile global options:

{
...
  preferred_chains {
    root_common_name "ISRG Root X1"
  }
...
}

You have to force the renewal of the affected certificates/subdomains by deleting the corresponding files in caddy's data directory. (Beware of rate limiting if you generate many certificates at once.)

3
  • Perhaps this is related to the expiration of the root certificate that Let's Encrypt previously used (DST Root CA X3) that affects many sites, including Stack Exchange.
    – Andrew T.
    Oct 2, 2021 at 6:20
  • Yes, but the certifcate I'm using is still valid. All browsers or clients can support the dual (?) chain but the library for the DoT-validation doesn't support this kind of certificate. It has nothing (well only tangentially) to do with the invalidation of a certificate.
    – burny
    Oct 3, 2021 at 9:35
  • This Android bug might have been fixed: issuetracker.google.com/issues/201661947
    – emersion
    Apr 29 at 10:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .