Distinguez l'expiration de l'échec de la chaîne de confiance, préservez le point de terminaison signalé et validez le certificat réellement servi après le renouvellement.
Lire précisément la catégorie de résultat
Références : RFC 8460 §4.3.1, RFC 8460 §4.3.2.
certificat expiré signifie que le déclarant a observé un certificat expiré. Le certificat non approuvé couvre plusieurs conditions, notamment les autorités de certification inconnues, les erreurs de chaîne et les contraintes de nom. Le code de motif d'échec peut affiner le diagnostic, mais il s'agit d'un texte fourni par le journaliste et non d'un contrat d'analyseur universel. N'étiquetez pas chaque rapport de certificat non fiable comme un intermédiaire manquant sans preuve. Commencez par le contexte de stratégie et le point de terminaison de réception signalé afin qu'un problème de certificat SMTP ne soit pas confondu avec sts-webpki-invalid sur un MTA-STS Hôte de stratégie HTTPS.
Vérifiez le certificat qui est parvenu à l'expéditeur
Un gestionnaire de certificats affichant un certificat renouvelé n'établit pas que chaque écouteur SMTP le sert. Enregistrez la série ou l'empreinte digitale, l'intervalle de validité, la chaîne et l'horodatage du test à partir de la vérification réelle du point final autorisé. Comparez ces valeurs sur les itinéraires de réception impliqués par les rapports. Un processus obsolète, un hôte de sauvegarde oublié ou un déploiement incomplet de l'équilibrage de charge peuvent laisser les anciens certificats actifs. Vérifiez la précision de l'horloge lorsque les limites de validité semblent incohérentes, mais ne modifiez pas les horloges ou les magasins de confiance simplement pour réussir un test qui échoue.
Reproduire un problème de chevauchement de renouvellement
L'exercice de synthèse définit un ancien certificat valable jusqu'à t=100 et un nouveau valable de t=90 jusqu'à t=200. À t=110, un écouteur qui sert toujours l'ancien certificat échoue à la vérification de la fenêtre de validité du modèle, tandis qu'un écouteur qui sert toujours le nouveau certificat le réussit. Cela reproduit la distinction de déploiement sans générer de véritable certificat. Cela ne prouve pas la confiance en chaîne, la correspondance de noms, le comportement de révocation ou les conventions de limites de l'implémentation. Ceux-ci ont besoin d’un véritable validateur TLS et de preuves contrôlées des points finaux.
Enquêter sur la confiance sans la contourner
Références : RFC 8461 §4.2, RFC 7672 §3.1.1.
Capturez la feuille et la chaîne intermédiaire servie, puis comparez la raison du journaliste avec un environnement de test maintenu. Un émetteur approuvé par une machine locale peut ne pas être accepté par l'expéditeur concerné. Des intermédiaires manquants, un certificat auto-signé inattendu et une contrainte spécifique à la politique sont des réparations différentes. Documentez le modèle de validation sélectionné. SMTP DANE avec DANE-EE, l'utilisation a une sémantique de confiance différente de celle du Web PKI, donc une conclusion de type STS sur les autorités de certification publiques ne peut pas simplement être appliquée à chaque TLSA rapport.
Boucler la boucle sur le déploiement et le reporting
Références : RFC 8460 §4.1.
Appliquez le renouvellement approuvé ou la correction de chaîne à chaque auditeur concerné, vérifiez le comportement de rechargement et conservez la preuve du certificat présenté après le changement. Comparez les rapports dont les périodes d'observation tombent après la réparation et tiennent compte des retards d'agrégation. Planifiez la surveillance du renouvellement avec suffisamment de temps pour la propriété et le déploiement, et surveillez séparément si le nouveau certificat est réellement déployé. N’abaissez pas automatiquement une politique de transport en vigueur pour masquer les échecs de certificat. Ce guide enregistre uniquement les tests de laboratoire contrôlés ; il ne renouvelle pas les certificats de production, ne modifie pas les magasins de confiance de production et ne démontre pas la reprise de la production.
Preuves historiques conservées et contrôles en cours
Les observations de transport ci-dessous ont été capturées le 7 novembre 2026 et inspectées, et non réexécutées sous forme de tests de réseau, pour cet examen. Les nouveaux contrôles de modèle hors ligne sont enregistrés séparément.
La capture de bouclage conservée comprend un certificat signé par l'autorité de certification du laboratoire de confiance dont la validité a pris fin avant le test ; il échoue avec le code de vérification 10, le certificat a expiré. Une feuille auto-signée distincte échoue avec le code de vérification 18, certificat auto-signé. Le contrôle valide réussit avec le même nom d'hôte attendu. Les preuves de poignée de main horodatées et les certificats publics sont conservés, ce qui permet d'inspecter séparément les expirations et les échecs de confiance. Les clés privées sont temporaires et supprimées. Le déploiement réel du renouvellement du service et la vérification du déploiement de tous les auditeurs restent en dehors de cet atelier. Le programme d'exécution de transport historique nécessite Python avec des sockets de cryptographie et de bouclage. Ses résultats sont des preuves limitées en laboratoire, et non l’état actuel des services ou l’interopérabilité de la production.
Base de source primaire
Les définitions de champs et les limites de déclaration proviennent de RFC 8460 , rapports SMTP TLS, sections 3 et 4. Lorsque la validation STS est abordée, consulter RFC 8461. Les recommandations opérationnelles se distinguent des exigences protocolaires.