Une horloge d’appareil fausse peut bloquer le VPN : vérifiez l’heure d’abord

Le VPN cesse de se connecter, le journal mentionne un certificat et le premier réflexe est de remplacer le profil. Une horloge d’appareil décalée de quelques minutes ou heures produit exactement cette erreur, car la validité du certificat est jugée par rapport à l’instant local. L’étiquette de fuseau horaire à l’écran n’est pas le problème ; l’heure sous-jacente l’est. Vérifiez l’horloge avant de toucher au moindre élément du certificat.

L’erreur ressemble à un problème de certificat, pas à un problème d’horloge

La poignée de main TLS échoue lorsque le certificat du pair sort de sa fenêtre de validité par rapport à l’horloge du vérificateur. Ce contrôle s’exécute sur le client, donc une horloge client fausse rejette un certificat parfaitement valable. Le texte de l’erreur nomme le certificat, et c’est pourquoi les gens le remplacent et revoient la même panne. L’horloge est l’hypothèse la moins coûteuse et doit être testée en premier.

Une horloge en avance sur le temps réel rejette un certificat en cours comme expiré ; une horloge en retard rejette un certificat plus récent comme pas encore valide. Les deux messages pointent vers des dates, et tous deux sont produits sans aucun contact avec l’autorité de certification. C’est l’indice : une vraie expiration touche tous les clients, alors qu’un problème d’horloge ne touche que la machine dont l’heure est fausse.

Lisez l’instant, puis le certificat

Affichez l’horloge en UTC et les dates propres du certificat avant de modifier quoi que ce soit. Comparer deux instants absolus retire entièrement la question du fuseau horaire de l’enquête. Si la fenêtre du certificat contient l’instant actuel, le certificat n’est pas votre panne.

date -u
timedatectl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -dates

Si l’horloge locale est fausse, vérifiez si elle est synchronisée et avec quoi. Une machine dont la synchronisation est désactivée, ou dont la source de temps est injoignable, dérive jusqu’à ce que quelque chose échoue. La sortie d’état nomme la source et le dernier ajustement réussi, ce qui est plus utile que le décalage actuel seul. Un décalage important sans source configurée est un problème différent d’un petit décalage face à une source qui fonctionne.

timedatectl timesync-status
chronyc tracking

Arrêtez-vous si le certificat est vraiment expiré pour tous les clients. Alors l’horloge est correcte et le certificat a besoin d’un renouvellement, pas d’un ajustement.

Les codes de connexion échouent pour une raison liée mais différente

Les mots de passe à usage unique basés sur le temps tirent leur valeur du pas de temps courant, généralement trente secondes. Un appareil dont l’horloge est décalée de plus d’un ou deux pas produit des codes que le serveur n’acceptera pas, même si l’utilisateur a saisi les bons chiffres. L’erreur ressemble à un mot de passe erroné, ce qui pousse les gens dans une boucle de réinitialisation qui ne peut pas réparer une horloge.

Déterminez quel composant a rejeté la tentative, car le client VPN, la passerelle et le fournisseur d’identité signalent des étapes différentes. Si le code est rejeté mais le mot de passe accepté, le compte est probablement en règle et l’horloge est le suspect. Si les deux sont rejetés, le compte est peut-être verrouillé et l’horloge est une fausse piste. Suivez les consignes de récupération du fournisseur au lieu d’approuver des demandes que vous n’avez pas lancées.

Ne reculez pas l’horloge pour faire fonctionner un code. Cela cache la cause et casse le contrôle suivant basé sur le temps.

Réparez la source, pas l’heure affichée

La synchronisation est un service réseau, et le tunnel peut changer l’accessibilité de la source de temps. Une source d’entreprise peut exiger le tunnel, tandis qu’une source publique peut être bloquée par la politique. La navigation peut fonctionner alors que la route propre du service de temps échoue, et c’est pourquoi cette dépendance se remarque difficilement. NTP est le protocole derrière l’ajustement, et il a besoin de sa propre route comme tout autre service.

sudo systemctl status systemd-timesyncd
sudo chronyc sources -v
ping -c1 203.0.113.20

Il y a aussi un problème d’ordre de démarrage : une horloge très fausse peut empêcher un tunnel authentifié, et la seule source de temps utilisable peut se trouver derrière ce tunnel. Un parc géré a besoin d’une procédure documentée pour cet état, et contourner la vérification du certificat n’en est pas une. Sur un appareil personnel, utilisez les réglages d’heure du système d’exploitation et découvrez pourquoi l’horloge se perd après un arrêt ou une restauration. Une machine qui dérive à chaque démarrage a un problème de matériel ou de configuration, pas un problème de VPN.

Après la réparation, réessayez la connexion d’origine et lisez la nouvelle erreur séparément. Une mauvaise identité de serveur, un certificat vraiment expiré et un compte rejeté sont trois pannes différentes, et les mélanger est la façon dont une simple correction d’horloge devient une semaine de changements de profil.