Certificat VPN pas encore valide : trois causes, un ordre de vérification
Pas encore valide signifie que l’horloge de l’appareil retarde, que la fenêtre commence réellement plus tard ou qu’un certificat intermédiaire n’est pas encore ouvert. Vérifiez-les dans cet ordre.
Vous ouvrez le client, vous choisissez le profil que vous utilisez depuis des mois, et il s’arrête sur « certificate is not yet valid ». Rien dans votre connexion n’a changé, et le magasin de confiance est probablement intact : le certificat présenté lors de la poignée de main porte une fenêtre de validité qui commence plus tard que l’instant utilisé par le vérificateur. Trois situations différentes produisent exactement ce message, et elles appellent des actions différentes. L’ordre ci-dessous vous dit laquelle vous avez avant de toucher à une horloge ou à un fichier de certificat.
Laquelle des trois causes vous avez
La première cause est locale : l’appareil qui effectue le contrôle a une horloge antérieure à la date de début du certificat. On la voit sur du matériel dont la pile CMOS est morte, sur des machines virtuelles restaurées depuis un ancien instantané, sur des équipements restés éteints assez longtemps pour perdre l’heure, et sur des réseaux où le NTP sortant est bloqué sans que personne ne l’ait remarqué. Le certificat peut être parfaitement valide et échouer quand même de cette façon.
La deuxième cause appartient à l’émetteur, car le certificat commence réellement dans le futur : émis tôt, généré avec une heure de début explicite, ou signé dans le cadre d’une étape d’activation qui n’a pas encore eu lieu. La troisième cause fait perdre le plus de temps, car le certificat feuille est à jour alors qu’un autre certificat de la chaîne présentée ne l’est pas, si bien que l’erreur nomme un matériel que vous n’avez jamais installé.
Une question les sépare. La panne suit-elle l’appareil ou le service ? Deux machines sur le même réseau qui se comportent différemment pointent vers les horloges. Tous les clients qui échouent de la même manière pointent vers la fenêtre du certificat et la chaîne derrière elle.
Lisez la fenêtre depuis le certificat réellement présenté
N’inspectez pas un fichier PEM laissé par un déploiement précédent ; demandez au service la chaîne qu’il envoie maintenant. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts imprime chaque certificat de la chaîne. Enregistrez le bloc qui vous intéresse et exécutez openssl x509 -noout -subject -issuer -dates ; le dernier imprime notBefore et notAfter, et ce sont ces deux valeurs qui décident. Sous Windows, la boîte de dialogue de certificat de la connexion et certutil -dump sur un fichier exporté affichent les mêmes champs.
Lisez les deux extrémités de la fenêtre, pas seulement le début. Un certificat qui ouvre dans deux heures et un qui ferme dans deux heures échouent avec des messages différents et impliquent des équipes différentes. Notez quel certificat l’erreur nomme — feuille, intermédiaire ou racine —, car cela décide si quelque chose peut être corrigé côté client.
Vous pouvez aussi tester la fenêtre sans l’attendre. La vérification accepte une heure explicite : openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem évalue la chaîne à cet horodatage. Exécutez-le avec l’heure actuelle pour reproduire la panne, puis avec l’heure de début du certificat pour confirmer que la même chaîne passe dès que la fenêtre s’ouvre. RFC 5280 définit le champ de validité et la règle selon laquelle un certificat ne doit pas être utilisé en dehors, et c’est exactement la règle que votre client vient d’appliquer.
Votre horloge, ou la leur
Comparez l’horloge de l’appareil avec le début du certificat en UTC, depuis une source à laquelle vous faites confiance. date -u donne l’instant, et timedatectl status sur un hôte systemd indique aussi si l’horloge est synchronisée. Sous Windows, w32tm /query /status affiche la source actuelle et la dernière synchronisation réussie. Le fuseau horaire affiché dans la barre des tâches est un choix d’affichage, pas une horloge fausse ; le vérificateur compare des instants UTC.
| What you see | Most likely reading | Next step |
|---|---|---|
| Clock behind, one device affected | Local time fault | Resync time, keep validation on, retest |
| Clock correct, window opens soon | Certificate staged early | Wait for the window or follow the cutover plan |
| Clock correct, intermediate not yet valid | Chain material mismatch | Operator replaces the intermediate |
| Some peers pass, others do not | Inconsistent nodes | Record each peer's chain before changing anything |
Si l’horloge retarde, resynchronisez et retestez avant de modifier le moindre matériel de certificat. Un appareil décalé de quelques minutes ou heures rejette tous les certificats récemment émis qu’il rencontre, pas seulement un service, donc une explication par un seul service est généralement la mauvaise. Si l’horloge est correcte et synchronisée, cessez de regarder l’appareil : la fenêtre appartient à l’émetteur, et aucun réglage local ne doit être ajusté pour la faire passer.
Ce tableau est toute la décision. Déplacer son horloge vers ce que le certificat attend n’est pas une réparation, et désactiver les contrôles d’heure ne l’est pas non plus, car les deux masquent la condition qui a produit l’erreur.
Pourquoi la chaîne échoue alors que la feuille semble correcte
Les feuilles renouvelées et les intermédiaires de remplacement sont généralement livrés ensemble, et ils n’arrivent pas toujours au même moment. Un service peut envoyer une nouvelle feuille signée par un intermédiaire dont la propre fenêtre commence plus tard, ou continuer à servir un intermédiaire plus ancien sous une feuille fraîche. Dans les deux cas, la chaîne échoue alors que les dates de la feuille elle-même semblent raisonnables.
Les points de terminaison répartis par charge transforment cela de cassé en incohérent. Si une nouvelle tentative réussit, ou si un réseau fonctionne et un autre non, notez quel pair a répondu et quelle chaîne il a envoyée avant de changer les réglages. openssl s_client imprime l’adresse connectée, donc quelques tentatives révèlent si chaque nœud sert la même chaîne.
Des chemins de réparation qui gardent la validation intacte
Un problème d’horloge se corrige sur l’appareil, validation laissée active. Un problème de certificat se corrige par l’opérateur avec un matériel émis pour une fenêtre qui inclut déjà maintenant. Aucun réglage client ne rend valide un certificat pas encore valide ; les indicateurs qui sautent les contrôles d’heure existent pour confirmer un diagnostic, pas pour être déployés.
Lorsque le certificat est préparé pour une activation planifiée, suivez le plan de bascule. Installez-le à l’ouverture de sa fenêtre, ou utilisez la procédure de chevauchement documentée par le fournisseur, plutôt que de l’installer tôt et d’apprendre aux utilisateurs à cliquer à travers les avertissements. Les avertissements que les gens apprennent à ignorer coûtent plus qu’un court délai.
Enfin, retestez comme la panne s’est produite : une nouvelle session, le même client, la ressource dont vous avez réellement besoin. Les bibliothèques TLS peuvent mettre en cache une chaîne vérifiée pendant toute la durée d’une connexion, et une session reprise ne la revérifie pas forcément, donc une ancienne session peut continuer d’échouer après la correction ou continuer de fonctionner après une régression. Un fichier qui s’ouvre dans une visionneuse prouve seulement que le fichier est lisible ; une poignée de main terminée prouve que la chaîne valide.
Avant de clore le ticket, confirmez quatre choses : l’heure UTC et l’état de synchronisation de l’appareil en échec, les valeurs notBefore et notAfter de chaque certificat de la chaîne présentée, la même chaîne depuis un second client, et le nom que l’erreur donne au certificat. Si l’horloge est correcte et que la fenêtre ne s’est pas ouverte, le reste est le travail de l’opérateur, et le bon geste de votre côté est d’attendre la fenêtre plutôt que d’affaiblir le contrôle.