TLS-Zertifikatsrotation braucht beidseitige Belege

Eine Zertifizierungsstelle kann genau das Zertifikat ausstellen, das ein KI-Agent angefordert hat, während der Dienst weiter das alte präsentiert. Ich habe Rotationsjobs erlebt, die eine heruntergeladene PEM-Datei, ein aktualisiertes Secret oder einen grünen Reload-Befehl feierten und im ungünstigsten Moment feststellten, dass ein Listener nie gewechselt hatte. Erfolgreiche Ausstellung und erfolgreiche Bereitstellung sind verschiedene Aussagen und brauchen verschiedene Belege.

Eine verlässliche Rotation erfasst, was die CA ausgestellt hat, stellt genau dieses Artefakt bereit und öffnet eine neue TLS-Verbindung, um die tatsächliche Client-Sicht zu beobachten. Der abschließende Vergleich muss eine stabile Zertifikatsidentität, den vorgesehenen Hostnamen und den echten Netzwerkpfad verwenden. Kann der Agent nicht beide Seiten liefern, läuft die Änderung noch.

Der Abschluss braucht einen festen Belegvertrag

Eine Rotation ist erst abgeschlossen, wenn der Datensatz des ausgestellten Zertifikats mit den Beobachtungen aller Endpunkte im Bereitstellungsumfang übereinstimmt. Schreiben Sie diese Regel fest, bevor ein Agent Zugangsdaten oder Befehle erhält. Sonst optimiert er auf das Erfolgssignal seines Werkzeugs, das möglicherweise nur einen Dateischreibvorgang und keine clientseitig sichtbare Änderung bestätigt.

Der Ausstellungsdatensatz sollte Auftrags- oder Anforderungs-ID, angeforderte DNS-Namen, Seriennummer, SHA-256-Fingerabdruck, Gültigkeitszeitraum, Aussteller und einen Hash des öffentlichen Schlüssels enthalten. Er sollte auch nennen, wo vollständige Kette und privater Schlüssel gespeichert wurden, ohne den Schlüssel ins Protokoll zu kopieren. Der Fingerabdruck identifiziert das gesamte Blattzertifikat; der Public-Key-Hash zeigt, ob eine Neuausstellung den Schlüssel behielt oder wechselte.

Der Bereitstellungsdatensatz beantwortet andere Fragen: Welches Ziel erhielt das Artefakt, welche Konfiguration verweist darauf, welcher Prozess akzeptierte einen Reload und wann geschah das? Eine erfolgreiche Control-Plane-API-Antwort gehört hierher, beweist aber nicht den Dienstzustand. Sie belegt nur, dass ein Übergangsversuch das Bereitstellungssystem erreicht hat.

Der Beobachtungsdatensatz stammt aus einer neuen Verbindung nach der Bereitstellung. Er braucht angeforderten Hostnamen, aufgelöste oder erzwungene Adresse, Port, beobachtete Seriennummer und Fingerabdruck, Prüfergebnis, Zeitstempel und Standort des Prüfers. Der Standort zählt, weil interne, externe und hinter einem Unternehmensproxy laufende Probes verschiedene TLS-Endpunkte erreichen können.

Halten Sie das Abschlusskriterium mechanisch:

complete = issuance.valid
        && deployment.accepted
        && every(expected_endpoint,
                 observation.chain_valid
                 && observation.name_valid
                 && observation.leaf_fingerprint == issuance.leaf_fingerprint)

Damit wird ein unbequemer Zustand sichtbar: Das Zertifikat existiert und die Bereitstellung wurde akzeptiert, doch der ausgelieferte Fingerabdruck weicht noch ab. Nennen Sie ihn deployed_unverified, nicht complete. Präzise Zustände verhindern, dass Dashboard oder Agentenzusammenfassung zwei Aussagen still zusammenlegen.

ACME-Ausstellung beweist keine Bereitstellung

ACME beweist, dass eine CA nach der nötigen Autorisierung einen Auftrag angenommen und ein Zertifikat ausgestellt hat. Das Protokoll beweist nicht, dass Ihre Anwendung es ausliefert. RFC 8555 beschreibt vier Hauptschritte: Auftrag einreichen, Kontrolle der Identifikatoren belegen, mit einer Signieranfrage abschließen, dann auf Ausstellung warten und Zertifikat herunterladen. Die Grenze endet beim Abruf.

Diese Grenze wird leicht übersehen, weil viele ACME-Clients nach der Erneuerung einen Deploy-Hook ausführen. Der Hook liegt außerhalb der CA-Transaktion. Er kann an geändertem Pfad, altem Container-Secret, Reload des falschen Prozesses, asynchron angenommener Remote-Aktualisierung oder unerreichbarem Knoten scheitern. Der Auftrag bleibt trotz all dieser Fehler gültig.

Erfassen Sie das endgültige ACME-Auftragsobjekt oder die entsprechende CA-Antwort. Bei ACME beweisen status: valid und eine gesetzte Zertifikat-URL die Ausstellung. Lesen Sie Identifikatoren und Blatt-Fingerabdruck aus dem heruntergeladenen Zertifikat. Die bloße Existenz einer neuen Datei taugt nicht als Artefaktidentität; temporäre Dateien, Symlinks und wiederverwendete Namen sind schwache Belege.

Certificate Transparency schließt die Lücke ebenfalls nicht. Ein Logeintrag kann zeigen, dass ein öffentliches Zertifikat für einen Namen ausgestellt wurde. Er sagt nicht, ob Load Balancer, Ingress, Webserver oder CDN es jetzt präsentieren. CT ist unabhängiger Ausstellungsbeleg, kein Bereitstellungsmonitor.

Die Trennung ändert die Fehlerbehandlung. Ein Ausstellungsfehler heißt, dass der Agent den vorgesehenen Berechtigungsnachweis nie erhielt. Ein Bereitstellungsfehler heißt, dass er einen sensiblen Nachweis erhielt, der gespeichert sein kann, aber nicht ausgeliefert wird. Der zweite Fall braucht oft Bereinigung, Wiederholung oder Rollback und eine eigene Warnung.

Prüfen Sie das Artefakt vor dem Listener

Bestätigen Sie vor der Bereitstellung, dass das Blattzertifikat angeforderte Namen, erwartete Gültigkeit, vorgesehenen Aussteller und den zum privaten Schlüssel passenden öffentlichen Schlüssel hat. Diese Schranke findet fehlerhafte Bundles und falsche Dateien ohne Produktionseingriff. Sie ersetzt nicht die Live-Probe.

RFC 9525 formuliert die Identitätsregel klar: Clients bilden zulässige Referenzidentifikatoren unabhängig und vergleichen sie dann mit denen im Zertifikat. Bei gewöhnlichen DNS-Diensten stehen relevante Namen in subjectAltName. Der RFC lehnt den Rückfall auf einen domainähnlichen Common Name ausdrücklich ab. Ein Agent, der nur subject=CN=... prüft, kann ein Zertifikat genehmigen, das moderne Clients ablehnen müssen.

Untersuchen Sie das Blattartefakt mit echten Ausgabefeldern:

openssl x509 -in leaf.pem -noout \
  -serial -fingerprint -sha256 -dates -issuer -subject \
  -ext subjectAltName

Eine typische Ausgabe sieht so aus:

serial=03A17C...
sha256 Fingerprint=6B:19:8A:...
notBefore=Jul 24 08:15:00 2026 GMT
notAfter=Oct 22 08:14:59 2026 GMT
issuer=C=US, O=Example CA, CN=Example Issuing CA
subject=CN=api.example.net
X509v3 Subject Alternative Name:
    DNS:api.example.net, DNS:www.example.net

Nutzen Sie openssl x509 -checkhost api.example.net -noout als maschinelle Schranke, wenn Ihre OpenSSL-Version es unterstützt. OpenSSL dokumentiert -checkhost eigens zum Abgleich eines Zertifikats mit einem Host. Werten Sie den Exit-Status aus, nicht freundlichen Text, der sich zwischen Versionen ändern kann.

Vergleichen Sie öffentliche Schlüssel, ohne privates Material offenzulegen. Diese Befehle hashen den DER-kodierten öffentlichen Schlüssel beider Seiten. Gleiche Zeilen zeigen, dass Zertifikat und privater Schlüssel zusammengehören:

openssl x509 -in leaf.pem -pubkey -noout \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256

openssl pkey -in private-key.pem -pubout -outform DER \
  | openssl dgst -sha256

Geben Sie nie den Inhalt von private-key.pem, Command-Tracing oder eine Umgebungsvariable mit Schlüssel in den Agentenkontext. Lassen Sie einen eingeschränkten Executor vergleichen und Hash plus Exit-Status zurückgeben. Der Agent braucht das Ergebnis, nicht das Secret.

Erfolgreiches Schreiben braucht noch Aktivierung

Die Bereitstellung hat zwei Vorgänge: neues Material atomar platzieren und den TLS-Terminator zum Laden bringen. Agenten erledigen oft den ersten und folgern den zweiten. Lang laufende Server halten geparste Zertifikate gewöhnlich im Speicher, daher ändert ein Dateiaustausch auf Disk nicht zwingend neue Handshakes.

Legen Sie Dateien neben dem Ziel bereit, setzen Sie Eigentümer und restriktive Rechte, validieren Sie die Konfiguration und benennen Sie sie dann um. Umbenennen im selben Dateisystem verhindert ein teilweise geschriebenes PEM. Behalten Sie die vorherigen funktionierenden Dateien oder eine versionierte Secret-Referenz bis zur erfolgreichen Live-Prüfung; sofortige Löschung zerstört den schnellsten Rollback.

Die Aktivierung hängt vom Terminator ab. Laut nginx-Dokumentation lässt HUP den Master die neue Konfiguration prüfen, neue Worker starten und alte geordnet beenden; schlägt die Anwendung fehl, läuft nginx mit der alten Konfiguration weiter. Das schützt Verfügbarkeit, erzeugt aber einen perfekten Fehlalarm, wenn der Agent nur das gesendete HUP erfasst. Apaches Graceful Restart prüft ebenfalls Syntax und startet eine neue Generation, während alte Verbindungen auslaufen. Verwaltete Load Balancer und CDNs können eine Aktualisierung annehmen und später abschließen.

Erfassen Sie Aktivierungsbefehl oder API-Vorgangs-ID, Exit-Status und Zielprozessidentität. Prüfen Sie danach dienstspezifischen Status oder Logs. Machen Sie aus festem Warten keinen Beleg. 30 Sekunden Pause verdecken manchmal Eventual Consistency und verschwenden manchmal 29 Sekunden; einen dokumentierten Zustand bis zur Frist abzufragen ist klarer.

Aktivierungsfehler sollten den Ablauf stoppen, bevor öffentliche Wiederholungen den Dienst belasten. Bei Syntaxfehler, unerwarteter Prozessidentität oder terminalem Control-Plane-Fehler bleibt das alte Zertifikat erhalten und die Bereitstellung gilt als fehlgeschlagen. Meldet die Aktivierung Erfolg, aber der Endpunkt bleibt alt, prüfen Sie innerhalb eines begrenzten Fensters weiter, weil geordneter Austausch und verteilte Ausbreitung Zeit brauchen.

Prüfen Sie Client-Sicht und Namen

Die entscheidende Prüfung öffnet eine neue TLS-Verbindung, sendet den vorgesehenen Server Name Indication, validiert Kette und Hostname und erfasst das Blatt. Eine lokale Datei beantwortet nicht, was ein Client erhält. Eine wiederverwendete Keep-Alive-Verbindung ebenfalls nicht, weil ihr Handshake das Zertifikat schon gewählt hat.

Verwenden Sie OpenSSL mit SNI und Hostname-Prüfung:

openssl s_client \
  -connect api.example.net:443 \
  -servername api.example.net \
  -verify_hostname api.example.net \
  -verify_return_error \
  </dev/null 2>/dev/null \
| openssl x509 -noout -serial -fingerprint -sha256 -dates -issuer

-servername steuert SNI, das auf gemeinsam genutzten Listenern den virtuellen Host auswählt. -verify_hostname prüft Identität, -verify_return_error beendet bei Prüfungsfehler statt nur Diagnose auszugeben. -showcerts zeigt die vom Server gesendete Kette, doch laut Dokumentation ist diese Liste allein keine geprüfte Kette.

Fügen Sie nicht -k, --insecure oder eine gleichwertige Option hinzu, um die Automatisierung bestehen zu lassen. Das curl-Handbuch sagt, dass eine normale TLS-Anfrage CA-Vertrauen und Hostname prüft. Eine unsichere Probe kann den Fingerabdruck bestätigen und genau die defekte Kette oder den falschen Namen übersehen, die Nutzer trifft.

Der Fingerabdruck allein reicht auch nicht. Ein Server kann das erwartete Blatt mit unvollständiger Zwischenkette präsentieren und einige Clients brechen. Die Abschlussschranke muss gültigen Vertrauenspfad, Namen und erwartete Blattidentität verlangen. Gehören Widerrufsprüfung oder CT-Richtlinie zum echten Clientprofil, führen Sie auch dieses Profil aus; die einfache OpenSSL-Probe deckt es nicht ab.

Führen Sie jede Beobachtung in einem frischen Prozess aus oder deaktivieren Sie Wiederverwendung. Erfassen Sie stderr bei Fehlern und bereinigen Sie es vor dem Agentenkontext. Halten Sie die Fehlerklasse klar: Verbindung, Handshake, Vertrauenspfad, Identität oder abweichender Fingerabdruck.

Jeder TLS-Terminierungspunkt ist ein eigenes Ziel

Ein Hostname ist kein Bereitstellungsumfang. Der Umfang umfasst alle Stellen, die TLS für ihn terminieren können: Load-Balancer-Adressen, CDN-Standorte, Ingress-Replikate, regionale Frontends, IPv4- und IPv6-Pfade sowie erreichbare Origin-Listener. Eine bestandene Verbindung beweist eine Route zu einem Zeitpunkt.

Bauen Sie den erwarteten Endpunktbestand aus dem Infrastrukturzustand, nicht aus einer zufälligen DNS-Antwort. Dynamisches DNS und Anycast erschweren vollständige öffentliche Stichproben. Definieren Sie daher eine vertretbare Menge: jeden konfigurierten Listener oder jede Zertifikatszuordnung plus Probes aus wichtigen Clientregionen. Verwaltet ein Anbieter die Edge-Flotte, prüfen Sie dessen Bereitstellungsstatus und testen extern aus mehreren Blickpunkten.

Für adressspezifische Tests ist curl --resolve sicherer als eine IP in der URL, weil der ursprüngliche Hostname für SNI und Zertifikatsprüfung erhalten bleibt:

curl --fail --silent --show-error \
  --resolve api.example.net:443:192.0.2.18 \
  --output /dev/null \
  https://api.example.net/health

Wiederholen Sie das für jede bekannte Adresse, einschließlich unterstützter IPv6-Adressen in Klammern. Danach folgt die OpenSSL-Fingerabdruckprobe derselben Adresse mit -servername api.example.net. Erfolgreiches HTTP prüft mehr als TLS, also wählen Sie einen günstigen, nicht mutierenden Endpunkt; die Zertifikatsbeobachtung bleibt der Rotationsbeleg.

Beschreiben Sie Proxys genau. Eine Probe vom Entwickler-Laptop kann ein Zertifikat der Unternehmensinspektion sehen. Eine Cluster-Probe kann das öffentliche CDN umgehen. Erfassen Sie Standort und Netzwerkpfad und verwerfen Sie eine Beobachtung, wenn Aussteller oder Fingerabdruck zeigen, dass sie den vorgesehenen Terminator nicht erreichte.

Während einer rollenden Änderung ist eine Mischung alter und neuer Fingerabdrücke zu erwarten. Das ist ein gültiger Übergangszustand, keine Erlaubnis zum Mehrheitsabschluss. Alle Endpunkte müssen konvergieren oder der fehlerhafte wird ausdrücklich aus dem Dienst genommen.

Lassen Sie den Agenten vergleichbare Datensätze liefern

Ein KI-Agent sollte strukturierte Belege erzeugen, die ein anderes Programm ohne Prosainterpretation vergleicht. Aussagen wie "Erneuerung erfolgreich, Website sieht gut aus" löschen Ziel, Zeit und Abweichungen. Behalten Sie die Erklärung für Menschen, aber binden Sie Übergänge an typisierte Felder.

Ein kompaktes Ereignispaar kann so aussehen:

{"type":"certificate.issued","rotation_id":"rot_7f2","order_id":"ord_91c","dns_names":["api.example.net"],"serial_hex":"03A17C","leaf_sha256":"6B:19:8A:...","spki_sha256":"9f4c...","not_before":"2026-07-24T08:15:00Z","not_after":"2026-10-22T08:14:59Z"}
{"type":"certificate.observed","rotation_id":"rot_7f2","host":"api.example.net","address":"192.0.2.18","port":443,"leaf_sha256":"6B:19:8A:...","chain_valid":true,"name_valid":true,"observed_at":"2026-07-24T08:19:22Z","vantage":"external-us-east"}

Nutzen Sie eine rotation_id über Ausstellung, Bereitstellungsversuche, Beobachtungen, Wiederholungen, Rollback und Abschluss. CA-Auftrags-ID und Infrastruktur-Vorgangs-ID bleiben getrennt. Eine generische Job-ID erschwert die Rekonstruktion unnötig.

Wiederholungen brauchen eigene Semantik. Der Agent kann die Antwort verlieren, nachdem CA oder Control Plane einen Vorgang annahm. Blindes Wiederholen erzeugt Extrazertifikate, Limits oder konkurrierende Deployments. Geben Sie jeder Mutation ein aus Rotation und Phase abgeleitetes Idempotenz-Token und fragen Sie den Remote-Vorgang ab, bevor Sie Ersatz starten. Erfassen Sie, ob eine Antwort neu oder wiederholt ist.

Frische braucht ebenfalls eine Regel. Eine Stunde vor der Bereitstellung bestandene Probe beweist deren Ergebnis nicht, selbst wenn sie bei einem früheren Versuch denselben Fingerabdruck sah. observed_at muss nach der akzeptierten Aktivierung liegen und beim Abschluss ein Höchstalter einhalten. Nutzen Sie eine vertrauenswürdige Workflow- oder Prüferuhr, nicht Zeitangaben aus Modellprosa.

Speichern Sie Zertifikats- und Dienstidentität getrennt. Der Fingerabdruck fragt, ob es das ausgestellte Blatt ist, der Hostname, ob es zum angefragten Dienst passt, und die Kette, ob der Prüfer einen akzeptablen Vertrauenspfad baut. Alles in tls_ok zu bündeln erzwingt spätere Wiederholung, wenn Belege verschwunden sind.

Auch der Endpunktbestand braucht eine Revision. Kommt mitten in der Rotation ein Listener hinzu, muss der Abschluss die neue Revision übernehmen und ihn beobachten oder an der genehmigten alten Revision bleiben und Nacharbeit eröffnen. Eine bewegte Liste still zu lesen erzeugt ein Rennen. Speichern Sie die Revision, damit Prüfer rekonstruieren können, was "alle" bedeutete.

Belegsammlung muss sicher wiederholbar sein. Nutzen Sie schreibgeschützte Routen, kurze Verbindungs-Timeouts und begrenzte Parallelität. Eine Health-URL, die Cache oder Sitzung ändert, ist ungeeignet; TLS läuft vor HTTP, daher genügt eine Minimalanfrage oder direkter Handshake. Bei Tausenden Adressen planen Sie je Ziel und wiederholen nur Fehler.

Trennen Sie Beobachtung und Interpretation. Die Probe meldet Handshake-Daten und Prüfergebnis, der Comparator entscheidet über die Rotation. So können Sie einen Comparator-Fehler mit gespeicherten Belegen korrigieren, ohne Produktion zu berühren, und der Agent kann Abweichungen nicht beruhigend umformulieren.

Der Comparator muss Beobachtungen vor dem akzeptierten Deployment, zu unerwartetem Host oder Adresse und aus anderer Rotation ablehnen. Er vergleicht normalisierte binäre Fingerabdrücke statt Anzeigeformat, da Doppelpunkte und Großschreibung variieren. Das Original bleibt für Menschen erhalten.

Lassen Sie den Agenten keine Felder auslassen. Definieren Sie das Schema und scheitern Sie geschlossen bei fehlenden Belegen. Signierte Ereignisse stärken Herkunft, reparieren aber keine schwache Aussage. Auch signiertes "Befehl endete mit null" sagt nicht, welches Zertifikat der Client bekam.

Speichern Sie fehlgeschlagene Beobachtungen. Abweichender Fingerabdruck, abgelaufenes Zertifikat oder falscher Name erklären den offenen Job und trennen langsame Ausbreitung von falscher Zuordnung. Wer Fehler mit späterem Erfolg überschreibt, kann das Störungsfenster nicht erklären.

Der bekannte Fehler ist ein geteiltes Deployment

Es beginnt unauffällig. Ein Agent holt ein Zertifikat für api.example.net, erfasst den ACME-Auftrag als gültig, aktualisiert api-tls und erhält Erfolg von der Orchestrierungs-API. Er sieht eine neue Secret-Version und schließt das Ticket.

Der öffentliche Hostname löst auf zwei Load-Balancer-Adressen auf. Ein Controller beobachtet api-tls im Produktions-Namespace und lädt das neue Zertifikat. Der andere Listener verweist auf dasselbe Secret im alten Namespace. Kein API-Aufruf scheiterte: Der Agent änderte ein echtes Objekt, aber nicht jedes für den Hostnamen zuständige.

Die meisten Nutzer erreichen die erste Adresse und sehen das neue Zertifikat. Ein anderer Pfad liefert das alte Blatt. Nahe am Ablauf wirken Fehler sporadisch und Wiederholen scheint zu helfen, weil DNS oder Balancer ein anderes Ziel wählt. Betreiber verdächtigen Caches, obwohl TLS bei jedem neuen Handshake auswählt.

Beidseitige Belege zeigen die Teilung sofort. Die Ausstellung sagt 6B:19:8A:...; die Adressen liefern diesen Wert und 41:D0:72:.... Die Rotation bleibt deployed_unverified, die Abweichung nennt die zu reparierende Adresse.

Der beliebte Rat "im Browser prüfen" taugt schlecht für Automation. Browser können Verbindungen wiederverwenden, die Adresse verbergen, andere Trust Stores nutzen oder hinter Inspektion sitzen. Als unabhängiger Incident-Check ist das nützlich, nicht als Abschlusskriterium. Adressfixierte Probes mit Hostname-Prüfung liefern wiederholbare Belege.

Nach Korrektur der alten Zuordnung prüfen Sie beide Adressen mit neuen Verbindungen. Behalten Sie erste Abweichung, Korrekturereignis und bestandene Beobachtungen. Diese Historie belegt, was sich änderte und warum der Ablauf schließen durfte.

Privilegierte Aktionen brauchen enge Befugnisse

Rotation gibt Zugriff auf CA-APIs, Secrets und Produktions-Reloads. Der Executor sollte deshalb enge Aktionen statt Rohzugangsdaten anbieten. "Diesen CSR senden", "Artefakt X Listener Y zuordnen" oder "Host H über A prüfen" sind brauchbare Grenzen. Ein wiederverwendbares API-Token im Modell erhöht Risiko ohne besseren Schluss.

Jedes Ergebnis sollte Remote-Vorgangs-ID und Belegfelder enthalten, aber keine Zugangsdaten oder Private-Key-Bytes. Trennen Sie Befugnisse für Ausstellung, Bereitstellung, Prüfung und Rollback. Wer ein Zertifikat anfordern darf, soll es nicht automatisch überall zuordnen dürfen.

Sallyport hält API- und SSH-Zugangsdaten im verschlüsselten Vault, während der Agent HTTP- und SSH-Aktionen durch die App ausführt, ohne diese Daten zu erhalten. Activity- und Sessions-Journal stammen aus einem schreibblinden, verschlüsselten und hashverketteten Audit-Log. Das eignet sich zur Zuordnung der Aufrufe, ersetzt aber nicht die Zertifikatsbeobachtung.

Setzen Sie menschliche Genehmigung dort ein, wo die Wirkung steigt. Routinemäßige Erneuerung für vorab benannten Host und Listener kann Sitzungsautorisierung nutzen; neuer Name, Schlüsselwechsel, Wildcard oder Rollback rechtfertigen Genehmigung pro Aufruf. Sie muss Ziel und Fingerabdruck binden. "Zertifikatsupdate erlauben" ist zu vage für einen falschen Listener.

Auditieren Sie den Prüfer so streng wie den Bereitsteller. Kann derselbe unbeschränkte Agent Bestand ändern, bereitstellen und seine unvollständige Stichprobe für ausreichend erklären, ist der Vertrag Dekoration. Berechnen Sie Ziele aus kontrollierter Quelle und lehnen Sie fehlende Beobachtungen ab.

Schließen Sie erst bei Konvergenz und halten Sie Rollback bereit

Der Abschluss sollte unveränderliche Ausstellungs-, Bereitstellungs- und Beobachtungsereignisse deterministisch vergleichen. Er sollte den Agenten nicht fragen, ob die Rotation "fertig aussieht". Präsentieren alle Endpunkte das ausgestellte Blatt über gültige, namenspassende Ketten, erfassen Sie das Prädikat und schließen.

Setzen Sie Fristen für Ausbreitung. Wiederholen Sie innerhalb des Fensters nur noch nicht konvergierte Ziele mit begrenztem Backoff. Zur Frist schlägt die Rotation mit angehängten Abweichungen fehl. Rollback hängt von Gültigkeit und Dienstzustand ab: Ein altes Zertifikat mit Restlaufzeit kann vorübergehend sicherer sein, ein abgelaufenes oder widerrufenes verlangt Vorwärtsreparatur.

Rollback trägt dieselbe Beweislast. Das erneute Zuordnen des früheren Artefakts ist nur ein Versuch; der Ablauf muss den alten Fingerabdruck live sehen, bevor er Wiederherstellung meldet. War der private Schlüssel kompromittiert, ist Rückkehr keine Erholung. Stellen Sie mit neuem Schlüssel aus und widerrufen Sie nach Incident-Plan.

Bewahren Sie beide Zertifikate, bis Connection Draining und Richtlinie Bereinigung erlauben. Ein geordneter Reload kann alte Worker bestehende Verbindungen bedienen lassen, neue Probes sollten aber die neue Generation erreichen. Löschen Sie altes privates Material über den kontrollierten Secret-Pfad und erfassen Sie dies nach dem Abschluss statt als Voraussetzung für das neue Zertifikat.

Die erste Änderung ist klein und streng: Entfernen Sie "Zertifikat heruntergeladen" und "Secret aktualisiert" als endgültigen Erfolg. Fordern Sie auf einer Seite den ausgestellten Fingerabdruck und auf der anderen frische, hostnamegeprüfte Fingerabdrücke des gesamten Bestands. Der Agent darf jeden Schritt ausführen, doch nur passende Belege dürfen Abschluss melden.