Les problèmes de certificat les plus coûteux sont ceux qu’un navigateur vous cache. Chrome accepte une chaîne à laquelle il manque un intermédiaire tant qu’il a vu cet intermédiaire ailleurs — pendant ce temps, chaque curl, chaque client Java, chaque vieil Android et chaque sonde de supervision échouera. Un renouvellement qui a livré la mauvaise liste de SAN n’apparaîtra pas avant qu’un premier utilisateur du mauvais hôte ne visite. Un protocole ou un chiffrement faible est invisible jusqu’à ce qu’un balayage de conformité le signale. Le Vérificateur de certificat SSL/TLS de PortJar tire chaque fait sur ce que le serveur sert réellement et le pose sur une seule page.
Ce que fait l’outil
Le vérificateur ouvre une connexion TLS vers un hôte et un port que vous spécifiez (443 par défaut) et analyse le certificat que le serveur présente. Il retourne le sujet et l’émetteur, la fenêtre de validité, la liste complète des Subject Alternative Names, la chaîne telle que le serveur l’a réellement envoyée, la version TLS et la suite de chiffrement négociées, et un verdict sur la confiance de la chaîne par un trousseau d’AC standard. Il signale les certificats expirés, les autosignés, et les chaînes qui ne valident pas contre les racines publiques. Le résultat est ce qu’un client TLS frais et bien élevé voit à la première connexion — aucun intermédiaire en cache, aucune correction propre au navigateur.
Le vérificateur fonctionne contre n’importe quel hôte sur n’importe quel port qui parle TLS, pas seulement les serveurs web. SMTP sur 465, IMAPS sur 993, LDAPS sur 636, une base de données sur un port personnalisé — tout ce qui complète une poignée de main TLS retournera un certificat que l’outil peut analyser.
Comment l’utiliser
Ouvrez portjar.com/tools/ssl-certificate, entrez le nom d’hôte (avec le port s’il n’est pas 443), et lancez. Le verdict revient en quelques secondes. L’URL est sans état et partageable — déposez-la dans un billet et la prochaine personne voit le même certificat en rechargeant.
Quand vous y recourriez
- Vérifier qu’un renouvellement a réellement été livré. Après un renouvellement Let’s Encrypt, ACM ou d’une AC commerciale, le vérificateur confirme que la nouvelle fenêtre de validité est en place et que la liste des SAN couvre encore chaque hôte qui en a besoin. Faire cela avant de pointer la supervision vers le certificat vous épargne de courir après votre propre queue.
- Diagnostiquer « ça marche dans Chrome mais ça casse dans curl ». Presque toujours un intermédiaire manquant. La vue de chaîne vous dit exactement ce que le serveur a envoyé, qui est le vrai problème — Chrome a comblé la pièce manquante depuis son propre cache.
- Confirmer qu’un sous-domaine personnalisé ou partenaire est sur un certificat qui le couvre. Les certificats joker manquent souvent un seul hôte ajouté plus tard. La liste des SAN vous montre si l’hôte qui vous intéresse est couvert ou non.
- Vérifier la santé des certificats sur les services non web. Les relais SMTP, les serveurs IMAP/POP, les annuaires LDAP et les écouteurs de bases de données servent tous des certificats que personne ne regarde jusqu’au jour du renouvellement qui échoue. Lancer le vérificateur sur le port 465, 993, 636 ou là où le service vit fait surgir les problèmes avant qu’ils ne causent une panne.
- Auditer la posture TLS avant un balayage de conformité. Le vérificateur rapporte la version TLS et la suite de chiffrement négociées. Un serveur qui accepte encore TLS 1.0 ou 1.1, ou qui négocie une suite à échange de clés RSA, est un constat qu’un scanner attrapera au prochain passage. Mieux vaut le trouver vous-même.
Quoi faire de la sortie
Commencez par la fenêtre de validité. Un certificat qui expire dans moins de 30 jours sur un hôte en production qui ne se renouvelle pas automatiquement est un billet à déposer aujourd’hui. Un certificat déjà expiré et toujours servi est la cause immédiate de toutes les erreurs TLS que l’utilisateur voit — corrigez-le avant de déboguer quoi que ce soit d’autre.
Lisez la liste des SAN contre la liste des noms d’hôte que le certificat est censé couvrir. Un hôte manquant est la cause unique la plus courante de « le site charge bien mais le sous-domaine API lance une erreur de cert ». Les jokers couvrent un seul niveau de sous-domaine, pas plus — *.example.com couvre api.example.com mais pas eu.api.example.com.
Regardez la chaîne. Une chaîne complète se termine sur un certificat racine présent dans le magasin de confiance public. Une chaîne qui s’arrête un niveau avant la racine est correcte tant que la racine manquante est bien connue ; une chaîne à laquelle il manque un intermédiaire est cassée même si Chrome le pardonne. Combinez le constat avec le guide PortJar sur la chaîne de certificat SSL incomplète pour le correctif.
Regardez le protocole et le chiffrement négociés. TLS 1.2 est le minimum acceptable aujourd’hui ; TLS 1.3 est préféré. Tout ce qui est plus vieux est un constat. Les suites de chiffrement devraient être des AEAD modernes (AES-GCM, ChaCha20-Poly1305) — toute suite avec CBC ou RC4 est un constat à remonter.
Un certificat autosigné sur un hôte public est presque toujours une mauvaise configuration — quelqu’un a pointé le mauvais écouteur vers le mauvais cert. Sur un hôte interne, ça peut être délibéré, mais ça vaut la peine de confirmer.
Stack Harbor gère le cycle de vie des certificats, l’automatisation des renouvellements et la posture TLS sur de nombreux hôtes dans le cadre du soutien et de la supervision.