Un serveur dont l’horloge dérive de quelques minutes seulement continue de fonctionner en apparence normalement, jusqu’à ce que cette dérive rejette silencieusement un certificat TLS pourtant valide, ou rende incohérente la corrélation de logs entre plusieurs machines lors d’un incident. La synchronisation d’horloge est l’une des dépendances les plus invisibles d’une infrastructure, précisément parce qu’elle ne casse presque jamais brutalement.

Ce que la validation TLS suppose silencieusement

Un certificat TLS porte une date de début et de fin de validité, vérifiée contre l’horloge locale de la machine qui l’examine, jamais contre une source de temps externe. Un serveur dont l’horloge est en avance de quelques minutes sur la réalité peut rejeter un certificat pourtant valide, parce que sa date de début de validité paraît encore dans le futur du point de vue de cette horloge décalée.

# Une horloge en avance peut faire échouer une validation
# TLS parfaitement légitime, sans message d'erreur clair
# sur la vraie cause (dérive d'horloge, pas le certificat)
openssl s_client -connect example.com:443 -verify_return_error

Ce que la corrélation de logs suppose aussi

Reconstituer la chronologie d’un incident à partir des logs de plusieurs serveurs suppose implicitement que leurs horloges sont alignées : un décalage de quelques secondes entre deux machines peut faire apparaître un événement comme antérieur à sa cause réelle, faussant l’ordre de causalité qu’un post-mortem cherche justement à établir.

chrony : le remplaçant moderne de ntpd

chrony a remplacé ntpd comme implémentation par défaut sur la plupart des distributions modernes, avec un avantage concret : chrony converge plus rapidement vers une synchronisation précise après un redémarrage ou une coupure réseau, et gère mieux les connexions réseau intermittentes qu’un serveur physique peut rencontrer (un poste de travail qui se met en veille, une VM qui migre entre hyperviseurs).

# L'état de synchronisation en une seule commande,
# rarement le premier réflexe de diagnostic
chronyc tracking
# Reference ID    : 5EC5D1CB (time.cloudflare.com)
# Stratum         : 3
# System time     : 0.000123456 seconds fast of NTP time

System time indique l’écart réel entre l’horloge locale et la référence NTP consultée, la métrique à surveiller en continu plutôt que de supposer que la synchronisation fonctionne simplement parce que le service tourne.

Le piège du service qui tourne sans se synchroniser

Un service chronyd actif ne garantit pas une synchronisation réussie : un pare-feu qui bloque le port NTP (123/UDP) vers les serveurs configurés laisse le service tourner sans jamais réellement corriger l’horloge, un état qui ne génère souvent aucune alerte visible tant que personne ne vérifie chronyc tracking explicitement.

# Confirme que des sources NTP sont réellement
# joignables, pas seulement configurées
chronyc sources

Pourquoi les systèmes distribués en dépendent implicitement

Les algorithmes de consensus distribué (comme Raft, déjà abordé pour etcd) supposent une notion approximative de temps synchronisé pour leurs mécanismes de timeout et d’élection de leader : une dérive d’horloge significative sur un seul nœud d’un cluster peut provoquer des élections de leader intempestives, un symptôme qui ressemble à un problème réseau alors que la cause réelle est une horloge désynchronisée sur un seul membre du cluster.

À retenir

La dérive d’horloge casse silencieusement la validation TLS (un certificat valide rejeté par une horloge en avance) et fausse la corrélation de logs entre plusieurs serveurs, deux symptômes qui pointent rarement d’eux-mêmes vers la vraie cause. chronyc tracking révèle en une seule commande l’écart réel entre l’horloge locale et la référence NTP, une vérification à faire explicitement plutôt que de supposer qu’un service chronyd actif garantit une synchronisation réussie. Cette dépendance invisible devient critique dès qu’un système distribué (un cluster etcd, par exemple) suppose une notion de temps approximativement synchronisée pour ses propres mécanismes de consensus.