Zusammenfassung

  • RFC 9773 erlaubt einer Zertifizierungsstelle, einen Zeitraum für den Erneuerungsversuch zu empfehlen, und einem neuen Auftrag, das Vorgängerzertifikat zu benennen. Zufällige Zeitwahl, dauerhafter Backoff, Ersatzplan, ACME-Ausstellung und Auslieferung bleiben lokale Aufgaben.
  • suggestedWindow, akzeptiertes replaces, Auftrag im Zustand valid, Download, CT-Eintrag, installierte Datei und ein in einem frischen TLS-Handshake beobachtetes Zertifikat sind unterschiedliche Belege. Keiner darf die nächste Stufe vorwegnehmen.

Sechs Zeitgeber hinter einem grünen Status

Auf dem Dashboard steht „erneuert“. Das Wort wirkt eindeutig, weil es mindestens sechs verschiedene Uhren verdeckt.

Die Zertifizierungsstelle bestimmt den Zeitraum, in dem sie Arbeit bevorzugt. Der Client wählt darin einen Zeitpunkt. Retry-After steuert die nächste Abfrage der Erneuerungsinformation. Der Fehlerzustand begrenzt den nächsten Versuch. Das Auslieferungssystem bestimmt Verteilung und Prozessneustart. Schließlich zeigt erst der laufende Dienst in einer neuen Verbindung, welches Zertifikat er tatsächlich präsentiert.

Wer all diese Zeiten in ein Feld namens next_run schreibt, verliert die Ursache einer Verzögerung. Die Betriebsführung kann nicht mehr unterscheiden, ob sie auf neue Information, auf den gewählten Zeitpunkt, auf das Ende eines Backoffs, auf die CA, auf einen lokalen Reload oder auf noch nicht konvergierte Edges wartet.

Nehmen wir eine Flotte, die ein Zeitfenster von 24 Stunden erhält. Die CA hat ihre zentrale Sicht sinnvoll eingesetzt: Sie hat Arbeit von einer künftigen Spitze wegbewegt und Raum für Verteilung geschaffen. Beim nächsten gemeinsamen Aufwachen der Scheduler steigt die Kurve dennoch wie eine Wand.

Vielleicht rundeten Clients ihre Auswahl auf dieselbe Cron-Grenze. Vielleicht konnten sie nicht exakt schlafen und führten aus, weil der gewählte Zeitpunkt vor dem nächsten normalen Lauf lag. Manche Instanzen könnten Fehlerzustand beim Neustart verloren haben. Ein Flotten-Orchestrator könnte viele Einzelentscheidungen wieder zu einem gemeinsamen Job verdichtet haben.

Das ist ein analytisches Szenario, kein Bericht über einen benannten Vorfall. Es zeigt die operative Kernfrage von ARI: Wer darf welchen Zeitgeber bewegen, und welcher Beleg erlaubt den Übergang zur nächsten Stufe?

Das Directory veröffentlicht eine Beratungsquelle

Ein ACME-Server mit ARI-Unterstützung veröffentlicht eine renewalInfo-URL in seinem Directory-Objekt. Der Client bildet für ein Zertifikat eine reproduzierbare Kennung: base64url-Codierung des keyIdentifier aus dem Authority Key Identifier, ein Punkt und die base64url-Codierung der DER-Bytes der Seriennummer, jeweils ohne abschließendes Padding. Danach stellt er einen nicht authentisierten GET.

So können unabhängige Implementierungen dasselbe Zertifikat benennen. Die Antwort wird dadurch nicht zum Auslieferungsbefehl.

Das RenewalInfo-Objekt enthält zwingend suggestedWindow.start und suggestedWindow.end. Sie begrenzen den Zeitraum, in dem die CA den Erneuerungsversuch empfiehlt. Eine optionale explanationURL kann dynamischen Lastausgleich oder die Vorbereitung auf einen Massenwiderruf erläutern.

Drei Bedeutungsgrenzen sind entscheidend.

Das Fenster ist nicht die X.509-Gültigkeit und ändert weder notBefore noch notAfter. Es ist keine CRL- oder OCSP-Aussage über den Widerrufsstatus. Und seine Existenz beweist nicht, dass ein Client es abgefragt, akzeptiert oder einen Auftrag begonnen hat.

Eine CA kann das ganze Fenster in die Vergangenheit legen, um sofortige Erneuerung zu empfehlen. Ein Client mit nachgehender Uhr kann es noch für zukünftig halten. Ein Client ohne ARI sieht es gar nicht. Zentrale Kenntnis verbessert das Signal, erzeugt aber keine lokale Übernahme.

Der Client wählt und bewahrt den Zeitpunkt

RFC 9773 empfiehlt, einen Zeitpunkt gleichverteilt aus dem Fenster zu wählen. Liegt er in der Vergangenheit, versucht der Client sofort zu erneuern. Kann er sich exakt einplanen, wartet er. Liegt die Auswahl vor seinem nächsten normalen Aufwachen, handelt er jetzt. Andernfalls wartet er bis zur nächsten RenewalInfo-Abfrage und bewertet neu.

Die CA teilt also keinen exakten Termin je Zertifikat zu. Dafür müsste sie Scheduler-Auflösung, Wartungsregeln und Fehlerbehandlung jedes Teilnehmers kennen. Ein gemeinsames Fenster koordiniert das Gesamtsystem, ohne die lokale Ausführung zu übernehmen.

Zufall allein garantiert jedoch keine glatte Verteilung. Der gewählte Zeitpunkt muss Neustarts überleben. Sonst zieht der Client bei jedem Lauf neu, bis ein bequemer Wert erscheint. Geklonte Instanzen dürfen nicht denselben pseudozufälligen Zustand teilen. Eine grobe Stundenauflösung kann ein breites Fenster auf wenige Punkte zusammendrücken. Ein übergeordneter Flottenjob darf Einzelentscheidungen nicht durch einen globalen Start ersetzen.

Periodisch laufende Clients müssen außerdem Fehlerhistorie erhalten. Eine höhere Prüffrequenz ohne Anzahl und Zeitpunkt der letzten Fehlschläge zerstört den Backoff. Ein zustandsloser Scheduler verwandelt bessere Beobachtung in zusätzlichen Druck auf die CA.

Ist end gleich oder kleiner als start, ist das Fenster ungültig. Der Client behandelt es wie eine nicht nutzbare Antwort und folgt einer erneuten Abfrage oder seinem lokalen Ersatzplan. Erwartete Herkunft verleiht widersprüchlichen Daten keine Ausführungsgewalt.

Retry-After steuert die nächste Beobachtung

Bei ARI bezeichnet Retry-After die gewünschte Dauer bis zum nächsten Abruf von RenewalInfo. Sie ist angefordertes Minimum und Maximum zugleich, begrenzt durch vernünftige lokale Schranken und nachrangig gegenüber Fehler-Backoff.

Sie terminiert nicht den Zertifikatsauftrag.

Bei Retry-After: 21600 lernt der Client einen Informationsrhythmus von ungefähr sechs Stunden. Der im Fenster gewählte Erneuerungszeitpunkt bleibt eine andere Zustandsgröße. Wer beides vermischt, kann geplantes Warten nicht von veralteter Information unterscheiden.

Verbindungs- und Anfrage-Timeouts sowie 5xx-Antworten sind vorübergehende Fehler; der Client nutzt exponentiellen Backoff mit begrenzten Versuchen. Sind sie erschöpft oder tritt ein langfristiger Fehler auf — fehlendes oder ungültiges Retry-After, ungültiges Objekt, DNS-Fehler, abgelehnte Verbindung oder Nicht-5xx-Fehler —, fragt er nach sechs Stunden oder einem lokalen Ersatzwert wieder an.

Let’s Encrypt empfiehlt operativ, ARI für jedes Zertifikat mindestens zweimal täglich zu prüfen und zusätzlich eine Regel anhand der Restgültigkeit zu behalten. Das ist die Praxis einer CA, kein universeller Zahlenwert aus RFC 9773. Im Bestand sollte erkennbar sein, welche Grenze aus dem Standard, von der CA oder vom Betreiber stammt.

replaces schafft Ausstellungsabstammung

ARI ergänzt den optionalen Auftragsschlüssel replaces. Er verwendet dieselbe Zertifikatskennung und erklärt, welches Vorgängerzertifikat der neue Auftrag ablösen soll.

Diese Abstammung ist nützlich. Die CA kann Erneuerungen erkennen, Priorität oder Rate-Limit-Behandlung nach eigener Richtlinie anwenden und Nachfolger für von einem Vorfall betroffene Zertifikate verfolgen. Der Server prüft Konto und Identifikatoren. Hat ein anderer nicht ungültiger Auftrag den Vorgänger bereits als ersetzt markiert, antwortet er mit HTTP 409 und alreadyReplaced.

Die Annahme belegt trotzdem nur eine Beziehung in der Ausstellung. Sie beweist nicht, dass der Client den Nachfolger heruntergeladen, den Schlüssel geprüft, das Zertifikat zum Load Balancer gebracht, den Prozess neu geladen oder die Präsentation des Vorgängers beendet hat.

Auch „ersetzt“ im CA-System ist im ACME-Sinn zu lesen: Es gibt eine anerkannte Auftragsfolge. Daraus eine Aussage über Teilnehmerinfrastruktur zu machen, die die CA nicht beobachtet, vergrößert nützliche Information zu falscher Gewissheit.

valid lädt keine Datei in den Dienst

RFC 8555 regelt weiterhin die Ausstellung. Der Client erstellt einen Auftrag, erfüllt bei Bedarf Identifikator-Autorisierungen, sendet einen CSR an die Finalize-URL, wartet auf Ausstellung und lädt über die im Auftrag eingetragene Zertifikats-URL herunter.

ready bedeutet, dass die Anforderungen erfüllt sind und Finalisierung erwartet wird. processing kennzeichnet laufende Ausstellung. valid bedeutet, dass die CA ausgestellt und die URL bereitgestellt hat. Ein erfolgreicher Download beweist den Empfang der Bytes.

Keine dieser Stufen aktiviert sie in einem Dienst.

Danach folgen Schlüsselverwahrung, Kettenbildung, Zuordnungsprüfung, Dateirechte, Verteilung, Konfigurationsprüfung, Reload, Umgang mit bestehenden Verbindungen, regionale Replikation und Rückkehr. Eine neue Datei kann neben einem alten Prozess liegen, der sie nie wieder geöffnet hat. Eine Region kann konvergieren, während eine andere den Vorgänger zeigt.

Ein erklärbarer Zustand braucht eigene Übergänge:

  1. RenewalInfo abgerufen und validiert;
  2. Zeitpunkt gewählt und dauerhaft gespeichert;
  3. Auftrag mit Vorgängerabstammung erstellt;
  4. Autorisierung und Finalisierung abgeschlossen;
  5. Zertifikat geladen, Fingerprint berechnet, Schlüssel geprüft;
  6. Artefakt an benannte Ziele geliefert;
  7. Konfiguration validiert und Prozess neu geladen;
  8. neue lokale Verbindung präsentiert den erwarteten Fingerprint;
  9. externe Beobachtung deckt vorgesehene Pfade ab;
  10. Vorgänger nach einer begrenzten Wiederherstellungsfrist entfernt.

Ein boolesches „erneuert“ vereinfacht diese Kette nicht. Es löscht den Ort des Fehlers.

CT beleuchtet Ausstellung, nicht den aktiven Edge

RFC 9162 beschreibt öffentliche Logs für ausgestellte oder beobachtete TLS-Serverzertifikate. Certificate Transparency ermöglicht die Prüfung von CA-Aktivität, die Entdeckung unerwarteter Ausstellung und die Kontrolle der nur anhängenden Log-Struktur.

Ein CT-Eintrag ist ein starker Beleg für Ausstellung oder Einreichung. Er ist kein Auslieferungsbeleg.

Ein Precertificate kann während der Ausstellung eingetragen werden. Dritte können eine Kette einreichen. Der Eintrag kann existieren, bevor der Teilnehmer das Ergebnis lädt. Das Log besucht nicht jeden Endpunkt und weiß nicht, welcher Load Balancer den passenden privaten Schlüssel hält.

Die richtige Folgerung lautet: Zertifikat oder Precertificate ist nach den Log-Regeln in den Transparenzmechanismus gelangt. Für die Aussage, der öffentliche Dienst präsentiere es, muss der Dienst beobachtet werden.

Ein frischer Handshake liegt näher am Betrieb

Bei zertifikatsbasierter Authentisierung in TLS 1.3 sendet der Server seine Kette in Certificate, weist den privaten Schlüssel mit CertificateVerify nach und schließt das authentisierte Transkript mit Finished ab.

Eine neue, nicht auf vorherigem Sitzungszustand beruhende Verbindung zeigt daher, welchen Fingerprint ein Endpunkt zu diesem Zeitpunkt präsentiert. Er ist mit Download, Aussteller, Identifikatoren und Gültigkeit zu vergleichen. Die Prüfung muss relevante Adressfamilien, Regionen, SNI-Namen, Terminierungsebenen und Pfade abdecken.

Auch dieser Beleg ist begrenzt. Ein aktueller IPv4-Pfad beweist IPv6 nicht. Ein Anycast-Standort beweist nicht alle. Eine interne Sonde kann vor der öffentlichen Ebene terminieren. Eine wiederaufgenommene Sitzung liefert möglicherweise nicht den vollständigen Zertifikatsaustausch.

„Zur Zeit T präsentierte Endpunkt E auf Pfad P im frischen Handshake Fingerprint F“ ist prüfbar. „Global ausgerollt“ verlangt einen Beobachtungsplan, der dieses Global tatsächlich umfasst.

Ein kausales Belegbuch je Zertifikat

Getrennt, aber verknüpft zu bewahren sind:

  • ARI-Kennung, ACME-Directory und letzte erfolgreiche Abfrage;
  • Fensterbeginn und -ende, Erklärung, Antwort-Fingerprint und Retry-After;
  • gewählter Zeitpunkt, Methode, Uhrenabweichung, Auflösung und Persistenz;
  • Ersatzschwelle, Fehlerzahl, letzter Fehler und nächster erlaubter Versuch;
  • Vorgänger, Konto, Auftrags-URL und replaces-Ergebnis;
  • Zeitpunkte von Autorisierung, Finalisierung, Ausstellung und Download;
  • Fingerprint, Kette, Schlüsselzuordnung und Verwahrungsort;
  • Ziele, Prüfungen, Reloads und Rückkehrstatus;
  • frische Handshakes nach Region, Adressfamilie und Terminierung;
  • Entfernung des Vorgängers und der Beleg, der sie erlaubte.

Private Schlüssel, vollständige Kontodaten und ungefilterte Topologie gehören nicht in eine allgemeine Analyseoberfläche. Fingerprints, kontrollierte Zielkennungen und verantwortete Quittungen erhalten Kausalität, ohne Geheimniszugriff auszuweiten.

Die CA berichtet Beratung und Ausstellung. Der Client berichtet Auswahl und Auftrag. Die Auslieferung berichtet Verwahrung und Reload. Der Endpunkt präsentiert ein Zertifikat. Der Beobachter berichtet einen Pfad. Keine Ebene muss die Gewissheit der nächsten borgen.

Laufende Systeme vollenden den Wechsel

Die Veröffentlichung einer Koordinationsregel schafft noch keine Betriebswirklichkeit. Diese entsteht, wenn Teilnehmer implementieren, lokal validieren, ausrollen und verwenden.

Die gemeinsame ARI-Schicht ist schmal: Ressource ankündigen, Zertifikat identifizieren, Fenster ausdrücken, Abfragerhythmus nennen und Vorgänger benennen. Sie zentralisiert weder den Auslieferungsplan des Teilnehmers noch erklärt sie einen Dienst für geändert.

Lokale Entscheidung bleibt in Zeitpunkt, Backoff und Ersatzplan. Freiwillige Übernahme zeigt sich darin, ob und wie ein Client ARI integriert. Der Vorrang laufender Systeme erscheint am Ende: Das neue Zertifikat wird zur Dienstrealität, wenn aktive Endpunkte es präsentieren.

Die CA kontrolliert das Fenster, nicht alle Uhren. Der Client kontrolliert den Versuch, nicht die Ausstellung. Die Auslieferung kontrolliert die Installation, nicht alle Pfade. Eine Sonde kontrolliert ihre Beobachtung, nicht die ganze Flotte.

Diese Trennung schwächt Automatisierung nicht. Sie macht sie messbar, stoppbar und umkehrbar.

Quellen