Unterscheiden Sie den Ablauf vom Ausfall der Vertrauenskette, bewahren Sie den gemeldeten Endpunkt und validieren Sie das tatsächlich bereitgestellte Zertifikat nach der Erneuerung.
Lesen Sie die Ergebniskategorie genau durch
Referenzen: RFC 8460 §4.3.1, RFC 8460 §4.3.2.
„Zertifikat abgelaufen“ bedeutet, dass der Reporter ein abgelaufenes Zertifikat festgestellt hat. „Zertifikat nicht vertrauenswürdig“ deckt mehrere Bedingungen ab, darunter unbekannte Zertifizierungsstellen, Kettenfehler und Namensbeschränkungen. Der Fehlerursachencode kann die Diagnose einschränken, ist jedoch ein vom Reporter bereitgestellter Text und kein universeller Parser-Vertrag. Kennzeichnen Sie nicht jeden Bericht über ein nicht vertrauenswürdiges Zertifikat als fehlendes Zwischenprodukt ohne Beweise. Beginnen Sie mit dem Richtlinienkontext und dem gemeldeten empfangenden Endpunkt, damit ein SMTP -Zertifikatproblem nicht mit sts-webpki-invalid auf einem verwechselt wird MTA-STS HTTPS-Richtlinienhost.
Überprüfen Sie das Zertifikat, das den Absender erreicht hat
Ein Zertifikatsmanager, der ein erneuertes Zertifikat anzeigt, stellt nicht sicher, dass jeder SMTP Listener es bedient. Zeichnen Sie Seriennummer oder Fingerabdruck, Gültigkeitsintervall, Kette und Testzeitstempel von der tatsächlichen Überprüfung des autorisierten Endpunkts auf. Vergleichen Sie diese Werte über die von den Berichten betroffenen Empfangsrouten. Ein veralteter Prozess, ein vergessener Backup-Host oder eine unvollständige Load-Balancer-Bereitstellung können dazu führen, dass alte Zertifikate aktiv bleiben. Überprüfen Sie die Genauigkeit der Uhr, wenn die Gültigkeitsgrenzen inkonsistent erscheinen, aber ändern Sie die Uhren nicht und vertrauen Sie nicht auf Stores, nur um einen fehlgeschlagenen Test zu bestehen.
Reproduzieren Sie ein Problem mit Erneuerungsüberschneidungen
Die synthetische Übung definiert ein altes Zertifikat, das bis t=100 gültig ist, und ein neues, das von t=90 bis t=200. Bei t=110, der noch das alte Zertifikat bereitstellt, die Gültigkeitsfensterprüfung des Modells nicht, während ein Listener, der das neue Zertifikat bereitstellt, sie besteht. Dadurch wird die Bereitstellungsunterscheidung reproduziert, ohne dass ein echtes Zertifikat generiert wird. Es beweist nicht die Kettenvertrauensstellung, den Namensabgleich, das Widerrufsverhalten oder die Grenzkonventionen der Implementierung. Diese benötigen einen echten TLS Validator und kontrollierte Endpunktnachweise.
Untersuchen Sie Vertrauen, ohne es zu umgehen
Referenzen: RFC 8461 §4.2, RFC 7672 §3.1.1.
Erfassen Sie das Blatt und die bereitgestellte Zwischenkette und vergleichen Sie dann den Grund des Reporters mit einer gepflegten Testumgebung. Ein Aussteller, dem ein lokaler Computer vertraut, wird vom betroffenen Absender möglicherweise nicht akzeptiert. Fehlende Zwischenprodukte, ein unerwartetes selbstsigniertes Zertifikat und eine richtlinienspezifische Einschränkung sind verschiedene Reparaturen. Dokumentieren Sie das ausgewählte Validierungsmodell. SMTP DANE Die Verwendung von DANE-EE hat eine andere Vertrauenssemantik als Web-PKI, sodass eine Schlussfolgerung im STS-Stil über öffentliche Zertifizierungsstellen nicht einfach auf alle angewendet werden kann TLSA Bericht.
Schließen Sie den Kreis für Bereitstellung und Berichterstellung
Referenzen: RFC 8460 §4.1.
Wenden Sie die genehmigte Erneuerung oder Kettenkorrektur auf jeden betroffenen Listener an, überprüfen Sie das Neuladeverhalten und bewahren Sie den Nachweis des vorgelegten Zertifikats nach der Änderung auf. Vergleichen Sie Berichte, deren Beobachtungszeiträume nach der Reparatur liegen, und berücksichtigen Sie Aggregationsverzögerungen. Planen Sie die Erneuerungsüberwachung mit genügend Vorlaufzeit für Besitz und Einführung und überwachen Sie separat, ob das neue Zertifikat tatsächlich bereitgestellt wird. Senken Sie eine erzwingende Transportrichtlinie nicht automatisch ab, um Zertifikatfehler zu verbergen. In diesem Leitfaden werden nur kontrollierte Labortests erfasst; Es werden keine Produktionszertifikate erneuert, Produktionstreuhandspeicher geändert oder eine Produktionswiederherstellung nachgewiesen.
Erhaltene historische Beweise und aktuelle Kontrollen
Die folgenden Transportbeobachtungen wurden am 7. November 2026 erfasst und für diese Überprüfung überprüft und nicht als Netzwerktests wiederholt. Die neuen Offline-Modellprüfungen werden separat erfasst.
Die beibehaltene Loopback-Erfassung umfasst ein von der vertrauenswürdigen Laborzertifizierungsstelle signiertes Zertifikat, dessen Gültigkeit vor dem Test abgelaufen ist. Es schlägt mit Verifizierungscode 10 fehl, das Zertifikat ist abgelaufen. Ein separates selbstsigniertes Blatt schlägt mit Prüfcode 18, selbstsigniertes Zertifikat, fehl. Die gültige Steuerung ist mit demselben erwarteten Hostnamen erfolgreich. Zeitgestempelte Handshake-Beweise und öffentliche Zertifikate werden aufbewahrt, sodass Ablauf- und Vertrauensfehler separat überprüft werden können. Private Schlüssel sind temporär und werden entfernt. Der tatsächliche Rollout der Serviceverlängerung und die Überprüfung der All-Listener-Bereitstellung bleiben außerhalb dieses Labors. Der historische Transport Runner erfordert Python mit Kryptografie und Loopback-Sockets. Die Ergebnisse sind begrenzte Laborbeweise, nicht der aktuelle Servicezustand oder die Produktionsinteroperabilität.
Primärquellenbasis
Die Felddefinitionen und Berichtsgrenzen stammen aus RFC 8460 , SMTP TLS -Berichterstellung, Abschnitte 3 und 4. Wenn die STS-Validierung besprochen wird, konsultieren Sie bitte RFC 8461. Die operativen Empfehlungen unterscheiden sich von den Protokollanforderungen.