Machen Sie die Erneuerung zu einer Servicekontinuitätsaufgabe
Erneuerung des HTTPS-Zertifikats für eine MTA-STS Der Richtlinienhost ist erst dann abgeschlossen, wenn das richtige Zertifikat tatsächlich am erforderlichen Endpunkt bereitgestellt wird und ein validierender Client die Richtlinie abrufen kann. Eine erfolgreiche Ausstellungsbenachrichtigung stellt keine Bereitstellung, Vollständigkeit oder Verfügbarkeit der Vertrauenskette dar. Organisieren Sie die Arbeit rund um den laufenden Dienst und nicht um die Zertifikatsreihenfolge.
Dieser Leitfaden schlägt eine Erneuerungskontrolle und eine fiktive Fehlerüberprüfung vor. Es stellt keine Zertifikate aus, überprüft keine privaten Schlüssel, ändert das Hosting nicht und stellt keine Verbindung zu einer Kundendomäne her. Originalzertifikat und HTTP-Beobachtungen sind weiterhin erforderlich. Eigentümer sollten sich auf das genehmigte Bereitstellungs- und Rollback-Verfahren einigen, bevor ein Betreiber den Dienst in Anspruch nimmt.
Inventarisieren Sie die beiden Zertifikatoberflächen
Das Policy-Host-Zertifikat authentifiziert einen Namen wie mta-sts.example.com während des HTTPS-Abrufs. Empfangende SMTP Server legen separate Zertifikate für ihre MX Hostnamen vor. Diese Dienste können unterschiedliche Eigentümer, Verlängerungssysteme und Ablaufdaten haben. Durch die Erneuerung des einen wird das andere nicht repariert, selbst wenn beide vom selben Hosting-Anbieter verwaltet werden. RFC 8461 Abschnitte 3.3 und 4.2
Notieren Sie den Hostnamen der Richtlinie, das verantwortliche Team, die Bereitstellungsplattform, den aktuellen Fingerabdruck des öffentlichen Zertifikats, das Gültigkeitsintervall und den geplanten Erneuerungsmechanismus. Schließen Sie jede Adresse oder Bereitstellungsebene ein, die für den Endpunkt antworten kann. „notBefore“ und „notAfter“ begrenzen den Gültigkeitszeitraum eines Zertifikats, während die Pfadvalidierung auch von anderen Zertifikatseinschränkungen und der Vertrauenswürdigkeit abhängt. Ein scheinbar in der Zukunft liegendes Ablaufdatum allein ist kein erfolgreiches Validierungsergebnis. RFC 5280 Abschnitte 4.1.2.5 und 6
Überprüfen Sie Identität und Kette vor der Bereitstellung
Der Richtlinienhost muss ein nicht abgelaufenes Zertifikat vorlegen, das für seine erforderliche DNS Identität gültig ist und an einen Stamm verkettet ist, dem der Absender vertraut MTA. Hosting über a delegieren CNAME macht ein Zertifikat für den Hostnamen des Anbieters nicht ausreichend. Behalten Sie den ursprünglichen Richtlinien-Hostnamen in Validierungstests bei und dokumentieren Sie, welche öffentliche Kette der Server voraussichtlich senden wird. RFC 8461 Abschnitte 3.3 und 8.2
Verwenden Sie bei der Beurteilung der beabsichtigten Dienstidentität die alternativen Antragstellernamen des Zertifikats. RFC 9525 ist die aktuelle allgemeine Service-Identitätsspezifikation und ersetzt RFC 6125 , das in RFC 8461 zitiert wird. Halten Sie die anwendungsspezifischen DNS-ID-Regeln von MTA-STS explizit, anstatt stillschweigend das nicht verwandte Anwendungsverhalten zu ersetzen. Ein für Menschen lesbarer allgemeiner Name ist kein Grund, auf eine Nichtübereinstimmung des Hostnamens zu verzichten. RFC 9525 Abschnitte 2 und 6
Planen Sie genügend Zeit ein, um sich sicher zu erholen
Wählen Sie eine interne Verlängerungsfrist, die Zeit für fehlgeschlagene Ausstellungen, Bereitstellungsfehler und Überprüfungen lässt. Die angemessene Marge hängt von der Lebensdauer des Zertifikats und dem operativen Eigentum ab; Hier wird keine allgemeingültige Anzahl von Tagen festgelegt. Weisen Sie eine verantwortliche Person und einen Ersatzkontakt zu. Ein geplanter Auftrag ohne Warnungsziel oder Besitzer ist eine nicht überprüfte Abhängigkeit und kein vollständiger Erneuerungsprozess.
Halten Sie die Zertifikatsverwaltung innerhalb des genehmigten Geheimverwaltungssystems. Das Beweispaket sollte öffentliche Zertifikatsdetails und Validierungsausgaben enthalten, keine privaten Schlüssel oder Kontoanmeldeinformationen. Definieren Sie, was der Bediener zurücksetzen darf, wie die aktuelle Gültigkeit überprüft wird und welche Fehler eine Eskalation erfordern. Die Wiederherstellung eines abgelaufenen Zertifikats, weil es sich um die bekannte Konfiguration von gestern handelte, ist kein sinnvoller Wiederherstellungsplan.
Testen Sie den bereitgestellten Endpunkt und nicht die Zertifikatsdatei
Nach einer autorisierten Bereitstellung sollte die vorgeschlagene Prüfung den genauen Hostnamen, die Adresse, die UTC-Zeit, die beobachtete Kette, das Ergebnis der Namensvalidierung und das Vertrauensergebnis identifizieren. Wenn mehrere Serving-Knoten vorhanden sind, behalten Sie den tatsächlich überprüften Bereich bei. Ein erfolgreicher lokaler Test eines Betreibers kann nicht beweisen, dass jeder externe Absender derselben Wurzel vertraut oder denselben Knoten erreicht. Notieren Sie diese Grenzen, anstatt eine Beobachtung in universelle Bereitschaft umzuwandeln.
Überprüfen Sie dann, ob die ursprüngliche bekannte URL einen direkten HTTP 200 mit der beabsichtigten Richtlinie erzeugt. Die Arbeit mit Zertifikaten kann versehentlich die Auswahl virtueller Hosts, das Routing oder die Zugriffskontrollen für Anwendungen verändern. MTA-STS verbietet das Befolgen von HTTP-Weiterleitungen während des Abrufs, sodass ein Browser-Erfolg nach der Umleitung unzureichend ist. Die gültige TLS -Verbindung und die verwendbare HTTP-Antwort sind eindeutige Akzeptanzbedingungen. RFC 8461 Abschnitte 3.2–3.3
Untersuchen Sie einen fiktiven Teileinsatz
Betrachten Sie das fiktive example.com , dessen Richtlinien-Hostname von zwei Edge-Knoten bedient wird. Ein Erneuerungssystem erhält ein neues Zertifikat, aber nur ein Knoten lädt es neu. Der andere stellt weiterhin ein abgelaufenes Zertifikat zu. Ein Test, der den aktualisierten Knoten erreicht, besteht; Ein Absender, der den zweiten Knoten erreicht, kann die Richtlinie nicht authentifizieren. Diese Beobachtungen sind erfunden und begründen kein tatsächliches Verhalten des Anbieters.
Die vorgeschlagene Untersuchung vergleicht öffentliche Fingerabdrücke und Gültigkeitsintervalle an den bedienenden Knoten, gefolgt von einem authentifizierten Abruf unter dem unveränderten Hostnamen. Es beginnt nicht damit, die Zertifikatsprüfungen zu lockern oder den Erkennungsdatensatz zu löschen. Der Sanierungseigentümer würde die genehmigte Bereitstellung abschließen und beide Knoten überprüfen. SMTP MX Zertifikate benötigen weiterhin eine eigene Validierung, da die Policy-Host-Reparatur nichts über ihren Status aussagt.
Verstehen Sie die Cache-Grenze während eines Ausfalls
Ein unterstützender Absender mit einer gültigen, nicht abgelaufenen zwischengespeicherten Richtlinie muss diese weiterhin verwenden, wenn die Live-Richtlinie nicht abgerufen werden kann. Ein Absender ohne eine solche Richtlinie fährt nach einem Abruffehler fort, als ob MTA-STS nicht vorhanden wäre. Die Cache-Lebensdauer stellt daher für einige Absender einen begrenzten Kontinuitätsvorteil dar und nicht die Erlaubnis, das HTTPS-Zertifikat ablaufen zu lassen. Verschiedene Absender können während desselben Ausfalls legitimerweise unterschiedliche Zustände einnehmen. RFC 8461 Abschnitt 3.3
Die Erkennungs-ID identifiziert die Richtlinieninstanz, nicht die Seriennummer des Zertifikats. Wenn sich nur das Zertifikat ändert und der Richtlinientext identisch bleibt, gehen Sie nicht davon aus, dass eine neue ID erforderlich ist, damit die Verlängerung wirksam wird. Wenn sich auch die Richtlinie ändert, befolgen Sie die Aktualisierungsreihenfolge für den Hauptteil vor der ID und berücksichtigen Sie die zwischengespeicherten Richtlinien. Behalten Sie die Zertifikatbereitstellung und Richtlinienüberarbeitung als separat überprüfbare Änderungen bei. RFC 8461 Abschnitte 3.1 und 8.1
Bewahren Sie Beweise für die nächste Verlängerung auf
Speichern Sie den genehmigten Bereitstellungsdatensatz, öffentliche Vorher-Nachher-Zertifikatdetails, authentifizierte Abrufergebnisse und alle relevanten Informationen TLS-RPT Beobachtungen. Ein Richtlinien-Web-PKI-Fehler gehört zur Richtlinienendpunktuntersuchung; Ein gemeldeter Ablauf SMTP Zertifikats betrifft die empfangende Verbindung. Prüfen Sie, welche Kategorie tatsächlich gemeldet wurde. RFC 8460 Abschnitt 4.3
Das aktuelle RFC 8461 -Errata-Register enthält eine gemeldete Großschreibungskorrektur für abgelaufene Empfangs-MTA-Zertifikate; abgelaufene Zertifikate sind nicht zulässig. Hier werden keine Original-Erneuerungs- oder Hosting-Nachweise vorgelegt. Das letzte Betriebstor bleibt eine zeitgestempelte Demonstration des bereitgestellten Dienstes, die von seinem Eigentümer überprüft wird. RFC 8461 Errata