Choisir le contrôle adapté à la panne
Un site peut accepter une connexion TCP, présenter un certificat puis afficher une page d’erreur. Ces étapes répondent à des questions différentes. Le test de port vérifie si une connexion aboutit depuis le serveur de contrôle. Le contrôle du certificat examine la connexion TLS et le certificat reçu pour un nom précis. Une requête HTTP observe ensuite la réponse de l’application. Repérez l’étape qui échoue avant de modifier les réglages.
Commencez par l’adresse exacte qui échoue dans le navigateur, avec son sous-domaine, par exemple boutique.example.com. Notez le message, l’heure et les appareils concernés. Un problème limité à un ancien téléphone n’appelle pas la même recherche qu’un délai dépassé sur tous les appareils. Modifiez un seul réglage puis refaites le même contrôle. Le changement du résultat pourra alors être rapproché d’une modification connue de la configuration.
| Contrôle | Observation utile | Ce qu’il ne prouve pas |
|---|---|---|
| Port TCP | Une connexion au port choisi a abouti | Un certificat valide ou une page fonctionnelle |
| Certificat TLS | Le certificat reçu et les résultats de validation | La sécurité complète du site ou tous les clients |
| Réponse HTTP | Un état et un contenu renvoyés par le serveur | Le fonctionnement de chaque lien, connexion et paiement |
Saisir le nom réellement utilisé par les visiteurs
Pour consulter un certificat, utilisez le nom public du serveur, sans mot de passe, chemin privé ni adresse du panneau d’hébergement. Dans https://boutique.example.com/panier, le nom est boutique.example.com. Le chemin /panier ne choisit pas le certificat TLS. Le port HTTPS habituel est 443, mais le port correct dépend du service configuré. Une adresse HTTPS qui redirige vers une autre doit déjà établir une connexion TLS avant de transmettre cette redirection.
Le domaine principal et sa version avec www sont deux noms distincts. Un certificat pour example.com ne couvre pas automatiquement www.example.com. Un joker tel que *.example.com couvre généralement boutique.example.com, mais pas example.com ni un nom plus profond comme payer.boutique.example.com. Comparez les noms alternatifs inscrits dans le certificat avec le nom testé. Le libellé pratique du panneau ne remplace pas la liste de couverture réelle.
Lire les champs dans un ordre utile
Vérifiez d’abord la correspondance du nom, la période de validité et le résultat de confiance. Les noms alternatifs du sujet, souvent appelés SAN, indiquent les noms présents dans le certificat. L’émetteur désigne l’entité indiquée comme responsable de son émission. Ces champs n’évaluent ni les produits du site, ni les pratiques de son exploitant, ni les défauts de son logiciel. Une connexion authentifiée peut également mener à un site malveillant.
Comparez la date et l’heure d’expiration avec l’heure du contrôle, plutôt qu’avec une ancienne capture. Vérifiez aussi le début de validité : un certificat peut expirer dans plusieurs mois sans être encore valable. Un résumé limité à la date masque les cas proches de minuit. Le nombre de jours restants aide à planifier le renouvellement ; conservez toutefois les horodatages complets pour signaler une anomalie.
Les dates ne sont qu’un contrôle du certificat
Distinguer le bon nom et la confiance
Un certificat peut contenir le nom attendu tout en échouant à la validation de confiance. Une chaîne incomplète, un certificat intermédiaire expiré, une autorité privée ou un magasin de confiance ancien donnent des pistes différentes. La chaîne relie le certificat du site à une autorité reconnue par le client. L’installation du serveur et la configuration du client comptent toutes les deux. Remplacer seulement le certificat final ne corrige pas nécessairement ces problèmes.
Un contrôle effectué côté serveur utilise la bibliothèque TLS et le magasin de confiance de ce serveur. Il ne garantit pas le même résultat sur chaque navigateur, téléphone ou équipement connecté. Comparez la version du client en échec, son horloge et son avertissement exact avec un navigateur à jour. N’installez pas une autorité inconnue et ne désactivez pas la validation pour faire disparaître le message. Demandez à l’hébergeur sa procédure d’installation et la chaîne compatible recommandée.
Examiner la CSR avant de demander le certificat
Une demande de signature de certificat, ou CSR, contient une clé publique et des informations d’identité demandées. Ce n’est pas le certificat émis et son décodage n’interroge pas le site en ligne. Collez uniquement le bloc CSR dans le décodeur, en conservant ses marqueurs de début et de fin. Un fichier marqué PRIVATE KEY doit rester dans un stockage protégé, jamais dans un formulaire public, une demande d’assistance ouverte ou une capture.
Comparez les noms et les informations de clé avec la commande du certificat et le déploiement prévu. Le décodeur montre les champs présents ; il ne détermine pas les noms nécessaires à l’entreprise et ne garantit pas les extensions que l’autorité émettra. L’absence d’un SAN demandé ne prouve pas le contenu d’un futur certificat. Vérifiez les options de la commande, puis examinez séparément le certificat effectivement délivré.
Comprendre la limite du décodage
Lire la structure d’une CSR ne revient pas à vérifier sa signature ni à prouver que la clé privée correspondante est disponible sur le serveur. Un nom décodé reste une déclaration de la demande, pas une preuve de contrôle du domaine. L’autorité de certification effectue sa propre validation. Le décodeur de Savvy Toolkit sert à examiner la demande ; une lecture réussie ne signifie pas que la commande est approuvée ou que l’installation est prête.
Un administrateur peut examiner une copie locale avec openssl req -in request.csr -text -verify -noout. L’option -verify contrôle la signature de la demande elle-même ; elle n’établit pas la confiance publique dans un futur certificat. Exécutez la commande sur la CSR enregistrée et gardez les clés privées hors des terminaux et journaux partagés. Lire les champs sans vérifier la signature répond à une question plus limitée, qui doit être présentée comme telle.
Interpréter correctement un test de port TCP
Testez un seul port d’un service public qui vous appartient ou pour lequel vous disposez d’une autorisation. Saisissez le nom ou l’adresse IP publique et le port TCP configuré. Une connexion acceptée signifie qu’un équipement a répondu à cette destination, depuis le réseau du vérificateur et à cet instant. Cela n’identifie pas le programme, ne valide pas sa connexion utilisateur et ne prouve pas que le service doit rester exposé à Internet.
Une connexion refusée et un délai dépassé appellent des vérifications différentes. Le refus correspond généralement à un rejet explicite quelque part sur le trajet. Le délai dépassé signifie que la connexion n’a pas abouti dans le temps imparti ; filtrage, routage, adresse erronée ou panne du service restent possibles. N’étiquetez pas chaque délai dépassé comme un port fermé. Le test ne contrôle pas UDP : TCP 53 ne prouve pas le fonctionnement de DNS sur UDP.
Vérifier tout le trajet d’une redirection de port
Pour tester un serveur domestique, son application doit fonctionner et écouter sur l’adresse locale et le port attendus. La règle de redirection dirige un port externe vers cet appareil et ce service. Le pare-feu de l’ordinateur, le routeur et le réseau du fournisseur peuvent chacun modifier le résultat. Contrôlez le service dans le réseau local avant d’ajuster le routeur. Conservez les réglages sans rapport avec la panne et évitez d’ouvrir des plages entières pour diagnostiquer un port.
Comparez l’adresse WAN du routeur avec l’adresse publique observée depuis l’extérieur. Une adresse privée, le CGNAT ou un second routeur peuvent signifier que la règle du routeur le plus proche ne décrit pas tout le trajet. L’IPv6 public utilise un modèle d’exposition et de pare-feu différent du NAT IPv4. Un essai réalisé depuis le même Wi-Fi peut aussi suivre un chemin différent de celui d’une connexion extérieure.
Quand le DNS et l’hébergement divergent
Après une migration, certaines adresses peuvent encore atteindre l’ancien serveur et d’autres le nouveau. Un domaine peut publier des enregistrements IPv4 et IPv6 dont les destinations présentent des certificats différents. Un réseau de diffusion de contenu peut terminer la connexion TLS du visiteur avant de transmettre le trafic à l’origine. Le certificat visible publiquement peut donc appartenir à ce service intermédiaire, plutôt qu’au serveur d’hébergement récemment modifié.
Notez le nom testé et l’adresse de destination lorsque le résultat fournit réellement cette information. Comparez les enregistrements DNS aux instructions de l’hébergeur et examinez les deux familles d’adresses. Conservez le nom dans le test TLS : une connexion à la seule adresse IP peut faire renvoyer le certificat par défaut d’un serveur partagé. Évitez de modifier le DNS à répétition pendant la comparaison ; cela ajoute des variables au lieu d’isoler la cause.
Un diagnostic fondé sur des observations
Prenons une boutique fictive où https://example.com fonctionne, mais où https://www.example.com affiche un avertissement de nom. Le test de port aboutit sur 443 pour les deux noms. Le certificat reçu pour www.example.com contient seulement example.com dans ses SAN. Ces résultats orientent vers la couverture du nom ou l’affectation du certificat au serveur virtuel. Ouvrir un autre port du pare-feu ne corrige pas le nom absent. Vérifiez le certificat prévu pour la version avec www.
Changeons l’observation : les deux noms présentent le certificat attendu, mais un ancien appareil annonce un émetteur non reconnu. Contrôlez la chaîne fournie, l’horloge et les autorités prises en charge par cet appareil. Le résultat ne prouve pas que tous les visiteurs ont besoin d’un nouveau certificat. Ces exemples illustrent une méthode de raisonnement ; ils ne sont pas des mesures d’une boutique réelle et ne garantissent pas une réparation universelle.
Rendre la réparation vérifiable
Après une modification du certificat ou de sa chaîne, recommencez le contrôle du nom initial. Conservez le nouveau numéro de série, l’empreinte ou les dates uniquement lorsque ces champs sont disponibles. La mention installé du panneau est moins probante qu’une nouvelle connexion recevant le certificat prévu. Testez chaque nom public, le navigateur initialement en échec et les ports distincts utiles à l’application. Retirez toute exposition temporaire créée pour le diagnostic.
Pour demander de l’aide, fournissez le nom public, le port, l’heure, le message exact et un bref résultat avant et après modification. Excluez les mots de passe, clés privées, cookies de session et données de clients. Demandez au fournisseur de confirmer l’affectation du certificat, les intermédiaires et le renouvellement. Un contrôle est ponctuel : désignez la personne chargée des renouvellements et le moyen de détecter leurs échecs plutôt que de compter sur le souvenir du test présent.