Certificat feuille valide, chaîne expirée : lisez la profondeur

Vous vérifiez le certificat du serveur, voyez des mois restants sur l'horloge, et le client refuse toujours la connexion avec un message d'expiration. La date que vous lisez appartient à la feuille, et la plainte peut concerner quelque chose de plus profond dans le chemin. La vérification parcourt une chaîne, et tout certificat que ce parcours sélectionne peut échouer dans sa propre fenêtre de validité. Lisez lequel a échoué avant de renouveler quoi que ce soit.

La profondeur nomme le certificat qui a échoué

Dans les diagnostics OpenSSL, la profondeur 0 est le certificat cible et la profondeur 1 est l'émetteur qui l'a signé, les nombres plus élevés continuant vers l'ancre de confiance. Une expiration signalée à la profondeur 1 n'est pas contredite par un notAfter courant sur la feuille, donc revérifier le certificat visible n'expliquera jamais l'erreur.

Notez l'empreinte du certificat défaillant avec son sujet, car différents certificats peuvent porter le même nom de CA. La signature croisée produit exactement cette situation : la même autorité apparaît plus d'une fois, avec des dates de validité différentes, et le vérificateur a choisi celle que vous n'attendiez pas. Une étiquette familière n'est pas un identifiant, et une empreinte est ce qui distingue deux objets qui partagent un nom.

Surveillez aussi les produits ayant plus d'un rôle de certificat. Sur OpenVPN Access Server, les certificats protégeant les interfaces web sont distincts de ceux utilisés pour les connexions VPN, donc un navigateur qui ouvre la page d'administration ne prouve rien sur le chemin du tunnel.

Les entrées de confiance ne sont pas les mêmes que les candidats de chaîne

Donnez au vérificateur les deux entrées séparément et explicitement. Le fichier de confiance contient les ancres que vous acceptez ; le paquet non approuvé contient les certificats intermédiaires proposés pour construire le chemin. Les mélanger, c'est ainsi que des gens promeuvent accidentellement un intermédiaire au rang de racine puis se demandent pourquoi la même erreur les suit d'une machine à l'autre.

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

Désactiver le chemin et le magasin par défaut avec -no-CApath -no-CAstore garde le test honnête : le résultat dépend alors des fichiers que vous avez nommés, et non de ce que le poste de travail approuve par hasard. La référence de vérification OpenSSL documente ces options et les diagnostics qu'elles produisent.

-show_chain affiche la chaîne construite lorsque la vérification réussit, ce qui est utile pour confirmer que le chemin est celui que vous vouliez. Lorsqu'elle échoue, conservez la profondeur et le sujet signalés ; ces deux champs indiquent au lecteur suivant quel certificat inspecter.

Ce que cela ne fait pas, c'est reproduire la politique de chaque client. Un pin, une restriction d'usage ou une vérification d'identité propre au client vit dans le client, pas dans cette commande. Ce sont les réglages à inspecter quand la vérification réussit sur le serveur et que la connexion échoue encore. Gardez les deux diagnostics séparés, sinon vous renouvellerez un certificat sain en poursuivant une erreur de pinning.

Ce que le contrôle prouve et ce qu'il laisse de côté

Il s'agit d'un contrôle de chemin et d'usage contre un fichier de confiance que vous avez fourni. Pour un contrôle de nom HTTPS, ajoutez le nom d'hôte attendu via l'option appropriée ; pour une connexion VPN, conservez les contrôles d'identité configurés du client et utilisez le matériel de confiance que ce client lit réellement.

Ce qu'un serveur envoie est un ensemble de candidats, pas le chemin que votre client finira par construire. La confiance locale et les règles de construction de la bibliothèque façonnent toutes deux le résultat, ce qui explique qu'une même réponse puisse se vérifier sur une machine et échouer sur une autre. Comparez le magasin de confiance maintenu et l'implémentation TLS du client défaillant avec ceux d'un client qui fonctionne avant de supposer une évaluation identique. Une différence à cet endroit explique de nombreux rapports « seul cet ordinateur portable échoue ».

Pour voir la fenêtre de chaque certificat plutôt qu'un à la fois, imprimez-les comme un ensemble :

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

Cette seconde commande liste les sujets et les émetteurs sans décoder chaque fichier à la main, c'est ainsi que vous repérez un intermédiaire dont la date est passée alors que la feuille semble encore correcte.

Réparez le chemin sans affaiblir la vérification

Lorsqu'un intermédiaire expiré ou un certificat croisé obsolète est fourni, obtenez la chaîne actuellement prise en charge de l'émetteur et déployez-la via le flux de certificats documenté du service. Lorsque le client manque l'ancre maintenue prévue, mettez à jour sa configuration de confiance gérée ou le logiciel client. Résistez au raccourci consistant à marquer chaque certificat du paquet comme racine juste pour faire taire le message.

Le traitement de la racine mérite une note, car les résumés l'exagèrent souvent. RFC 5280 traite l'ancre comme une entrée située hors du chemin prospectif, tandis qu'OpenSSL documente des contrôles de validité qui incluent son certificat CA racine. Les deux affirmations sont vraies pour leurs propres systèmes ; généraliser le comportement d'expiration de racine d'une bibliothèque à tous les clients produit des réponses fausses et assurées.

Après le changement, forcez une nouvelle authentification sur le client concerné et confirmez que le message d'expiration spécifique a disparu. Ne renouvelez la feuille que si la feuille elle-même est inadaptée. Désactiver les contrôles de temps ou restaurer un certificat croisé historique ne produit pas un chemin actuel valide ; cela ne fait que retarder la prochaine défaillance.