1 votes

La connexion au serveur DoT n'est pas relancée

J'exécute mon propre serveur DNS-over-TLS sous mon domaine (dns.example.com). Sur mon Motorola G100, qui fonctionne sous Stock Android 11, je peux définir le DNS privé sur ce domaine et cela fonctionne. Cela fonctionne sur mes machines Linux, deux autres Androïdes (un Motorola sous Android 10 et un Samsung avec Android 10), et aussi sur deux routeurs différents (AVM FritzBox peut utiliser DoT en amont).

Le serveur n'est pas en faute, le certificat est valide et tous les appareils fonctionnent comme ils le devraient, c'est-à-dire jusqu'à ce que le serveur soit redémarré ou bloqué d'une autre manière. Ensuite, bien sûr, je reçois une notification indiquant qu'il "ne peut pas accéder au serveur DNS privé".

Les machines Linux se rétablissent et tentent à nouveau de se connecter, ainsi que les routeurs. Mais les téléphones Android ne veulent pas réessayer, même si je suis sûr que la connexion fonctionne.

Après avoir désactivé le DNS privé et l'avoir réactivé avec mon domaine, le journal suivant est affiché (IPs enlevés)

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

Je ne sais pas pourquoi il me dit que la poignée de main échoue, que tous les autres dispositifs (ou kdig +tls ) peuvent se connecter sans problème. Entre le redémarrage du serveur et aujourd'hui, aucune configuration, aucun certificat ni aucune version du logiciel n'ont été modifiés.

Je pense qu'Android met en cache la connexion et "se souvient" qu'elle a échoué à un moment donné dans le passé et n'essaie même pas de se connecter à nouveau. J'ai essayé le redémarrage, l'arrêt, le mode avion, un autre DoT (dns.google fonctionne), la désactivation du DoT mais rien ne corrige ce comportement.

0 votes

Il est difficile de deviner la cause profonde de la défaillance à ce point sans faire un peu de dépannage réseau sur l'appareil. Cela peut être dû à mise en cache négative du DNS du domaine de votre serveur.

0 votes

Non, c'est vraiment la vérification des certificats mal implémentée sur Android.

1voto

burny Points 121

Apparemment, Android (même les versions les plus récentes) ne peut pas gérer le type de certificat que Let's Encrypt génère par défaut.

La solution est une combinaison de la Forum Let's Encrypt et le réglage --preferred-chain="ISRG Root X1" pour certbot.

Si vous utilisez caddy comme serveur, vous pouvez le définir dans les options globales de Caddyfile :

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

Vous devez forcer le renouvellement des certificats/sous-domaines concernés en supprimant les fichiers correspondants dans le répertoire de données de caddy. (Attention à la limitation de débit si vous générez beaucoup de certificats en même temps).

0 votes

Peut-être est-ce lié à l'expiration du certificat racine que Let's Encrypt utilisait auparavant (DST Root CA X3) et qui affecte de nombreux sites, y compris Stack Exchange .

0 votes

Oui, mais le certificat que j'utilise est toujours valide. Tous les navigateurs ou clients peuvent supporter la double ( ?) chaîne mais la bibliothèque pour la validation DoT ne supporte pas ce type de certificat. Cela n'a rien à voir (enfin seulement tangentiellement) avec l'invalidation d'un certificat.

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X