Zusammenfassung

  • MI.ACMEDelegationMethod erlaubt einem autorisierten Downstream-Konto einen begrenzten Zertifikatsantrag; das Downstream-CDN erzeugt und behält das Schlüsselpaar.
  • Delegationsobjekt, CSR-Prüfung und CA-Ausstellung belegen einzelne Schritte. Sie belegen weder die DNS-Projektion noch Aktivierung, SNI-Auswahl und HTTP-Inhalt jedes Standorts.
  • STAR-Stornierung und normale Sperrung folgen verschiedenen Uhren. Autorisierung, Ausstellung, DNS, Deployment, TLS, Inhalt und Beendigung brauchen getrennte Belege.

Ein Zertifikat kann korrekt sein, während der Dienst falsch arbeitet. Ein PoP zeigt noch die alte Identität. Ein anderer hat die neue Datei, wählt aber per SNI das Standardzertifikat. Einige Resolver sehen den alten CNAME. Der erfolgreiche TLS-Endpunkt liefert wegen eines Cachefehlers das falsche Objekt. Nichts davon widerspricht dem Zertifikat.

Der im Februar 2024 als IETF-Standards-Track-Dokument veröffentlichte RFC 9538 löst ein enges, reales Problem. Delegiert ein Upstream-CDN HTTPS per DNS-Umleitung, braucht das Downstream-CDN ein Zertifikat für den Namen des Inhaltsanbieters. Statt einen langlebigen privaten Schlüssel organisationsübergreifend zu kopieren, nutzt das Verfahren RFC 9115: Downstream besitzt den Schlüssel, der Identity Owner begrenzt den Antrag.

Vier Felder starten den Zertifikatspfad

acme-delegation ist die HTTPS-URL des zum Downstream-Konto gehörenden Objekts, time-window das Gültigkeitsfenster. Mit lifetime ist STAR gewählt, ohne das Feld non-STAR; lifetime-adjust verändert die STAR-Laufzeit. Der Typ steht im IANA-CDNI-Register. RFC 8006, RFC 8008 und RFC 7336 liefern Metadaten-, Fähigkeits- und Rollenrahmen.

Die Felder enthalten keine Edge-Liste, Installationsbestätigung, Fingerprints pro Region, DNS-Beobachtung, SNI-Prüfung oder Inhaltsprüfung. Aus „Delegation angekündigt“ folgt nicht „Auslieferung bereit“.

Das Konto berechtigt zur Anfrage

Nach RFC 9115 wird der Name Delegation Consumer vorab registriert. Er holt mit seinem Kontoschlüssel ein Objekt samt CSR-Vorlage, erzeugt Schlüssel und CSR. Der Identity Owner prüft Namen und Erweiterungen und nutzt sein eigenes CA-Konto für ACME nach RFC 8555.

So verlässt der langlebige Upstream-Schlüssel dessen Sphäre nicht. Dafür wird das Downstream-Konto zum kritischen Kontrollpunkt: Kontenauthentisierung und vorkonfigurierte Regeln ersetzen auf diesem Abschnitt die übliche ACME-Challenge. Eine passende CSR beweist Vorlagenkonformität, nicht den Rollout.

RFC 5280 beschreibt X.509-Pfade, RFC 9525 Dienstidentitäten, RFC 8446 TLS 1.3 und RFC 6066 SNI. Sie helfen, die präsentierte Identität zu bewerten. Den HTTP-Inhalt bezeugen sie nicht.

DNS bleibt eine eigene Stellfläche

Das Delegationsobjekt unterstützt CNAME; RFC 9538 nennt eine mögliche spätere Erweiterung auf SVCB/HTTPS. Der Domaininhaber kann die alleinige Zonenhoheit behalten. CAA begrenzt Zertifizierungsstellen, RFC 8557 zusätzlich Konto und Validierungsmethode. Diese Regeln begrenzen Ausstellung, beweisen aber weder Propagation noch das Ziel.

Erforderlich sind autoritative Änderung, RRset, TTL, Beobachtungen aus mehreren Netzen und die Zuordnung jeder Adresse zum Inventar. Eine Zertifikatsseriennummer enthält diese Landkarte nicht.

Zwei Modi, zwei Endzeiten

STAR nach RFC 8739 liefert kurze, automatisch erneuerte Zertifikate. Der Identity Owner stoppt künftige Ausstellung, doch das letzte Zertifikat bleibt bis zum Ablauf gültig. Stornierung, letzte Ausstellung, letzter Abruf, Aktivierung und Ablauf sind getrennt zu messen.

Bei non-STAR kann Upstream die Sperrung beantragen; Downstream kann als Schlüsselinhaber in einer Sicherheitslage ebenfalls direkten Zugriff haben. Eine akzeptierte Sperranfrage löscht keine Edge-Konfiguration. Certificate Transparency macht Ausstellung sichtbar, nicht Installation oder Entfernung. RFC 9325 ersetzt ebenfalls keine Außenmessung.

Eine Kette aus belastbaren Belegen

Das Betriebsdossier trennt Auftrag des Inhaltsanbieters, Konto und Umfang, Delegationsobjekt und CSR-Vorlage, CSR/Schlüssel/Order, Zertifikat/SAN/Kette, autoritatives und beobachtetes DNS, Inventar/Fingerprint/SNI sowie TLS- und HTTP-Proben aus unabhängigen Netzen. Erneuerung und Beendigung durchlaufen dieselbe Kette.

„Ausgestellt, nicht installiert“, „92 Prozent der PoPs konvergiert“ oder „STAR beendet, noch 47 Minuten gültig“ sind entscheidungsfähig. Ein einziges grünes „sicher“ ist es nicht.

RFC 9538 verspricht keinen Ende-zu-Ende-Nachweis. Der Kategorienfehler entsteht, wenn ein Koordinationsartefakt als Zeuge der laufenden Realität behandelt wird.

Quellen und Grenzen

Der Status ist auf der RFC-Editor-Seite, in der IETF-Historie und bei den Errata prüfbar. Verwendet wurden außerdem RFC 9538, 9115, 8739, 8555, 8006, 8008, 7336, 9460, 9325, 9525, 5280, 8659, 8557, 8446, 6066 und 9162. Eine konkrete CDN-Installation oder Störung wurde nicht untersucht.