Zusammenfassung

  • RFC 9345 erlaubt dem Zertifikatsinhaber, ein begrenztes Credential zu signieren. Dessen privater Schlüssel kann kompatible TLS/DTLS-1.3-Handshakes abschließen; der Peer prüft weiterhin die ursprüngliche Kette und erwartete Identität.
  • Sieben Tage sind die Standardobergrenze, keine sofortige Einzelwiderrufsfunktion. Ein gestohlener delegierter Schlüssel bleibt bis zum Ablauf nutzbar; früheres Zurückziehen verlangt den breiteren Widerruf des signierenden Zertifikats oder externe Maßnahmen.
  • Belastbare Evidenz verbindet Zertifikats-Opt-in, Credential-Bytes, Signiervorgang, Schlüsselherkunft, Edge-Menge, Client-Aushandlung, CertificateVerify, Fallback, Wiederaufnahme und Ablehnung nach Ablauf.

Was das Backend tatsächlich aus der Hand gibt

Der langlebige Zertifikatsschlüssel bleibt in einem kontrollierten Signierdienst. Dieser bestätigt einen neuen öffentlichen Schlüssel für einen kurzen Zeitraum. Das Edge besitzt den passenden privaten Schlüssel und kann CertificateVerify lokal erzeugen. Die Verzögerung einer Signaturreise entfällt, und der Langzeitschlüssel muss nicht an jedem Standort liegen.

Das ist erhebliche Ausführungsgewalt, aber keine Eigentumsübertragung. Das Edge darf das Zertifikat nicht verlängern, Namen ändern, mit der CA handeln, aus dem Kurzzeitschlüssel Nachfolger schaffen oder Altclients zur Annahme zwingen.

Ein Delegated Credential ist deshalb kein kurzlebiges X.509-Zertifikat. Seine Struktur enthält Ablauf, erwarteten CertificateVerify-Algorithmus und SubjectPublicKeyInfo. Die Signatur bindet die vollständigen Zertifikatsbytes, den Gegenstand, den Algorithmus und einen getrennten Kontext für Client- oder Serverauthentisierung. Das Design delegiert eine Funktion, nicht die reichhaltigen Rechte einer Unter-CA.

Zustimmung steht im Endzertifikat

Das End-Entity-Zertifikat benötigt DelegationUsage und KeyUsage digitalSignature. Ohne beides muss der Empfänger ablehnen. Der ausdrückliche Schalter verhindert, dass zeitweiliger Zugriff auf einen gewöhnlichen Schlüssel oder ein altes Signatur-Orakel unbemerkt zur Herstellung künftiger Credentials berechtigt.

Bei Serverauthentisierung meldet der Client Extension 34 und akzeptierte Algorithmen im ClientHello. Erst danach darf das Server-Credential im End-Entity CertificateEntry stehen. Bei Clientauthentisierung muss der Server die Fähigkeit im CertificateRequest ankündigen. Unaufgefordert gesendete Delegation erzeugt einen Fehler, keine automatische Aufwertung.

Der Peer prüft weiterhin Zertifikatskette und erwartete Identität. Dann folgen Uhrzeit, Standardmaximum, Zertifikatsende, beide Algorithmusbeziehungen, Opt-in und Credential-Signatur. Erst danach verifiziert der delegierte öffentliche Schlüssel CertificateVerify.

Damit bleiben vier Zuständigkeiten sichtbar: CA für das Zertifikat, Inhaber für die begrenzte Delegation, Edge für den Besitzbeweis und Anwendung für fachliche Rechte. Erfolgreiches TLS gewährt nicht automatisch Zugriff auf Daten oder Aktionen.

Ablauf begrenzt Schaden, widerruft aber nicht sofort

Ohne anderes Profil darf die Restlaufzeit standardmäßig höchstens sieben Tage betragen und nicht über das Zertifikat hinausgehen. Cloudflare dokumentiert für Keyless eine kürzere Produktregel: nach Abschaltung werden von Cloudflare erzeugte Credentials binnen 24 Stunden ungültig. Diese Frist ist eine Betriebsentscheidung unterhalb der RFC-Grenze.

Beide Zeiträume sind Wartefenster. RFC 9345 bietet keinen separaten Frühwiderruf für genau ein Credential. Aus regulären Edges entfernen und neue Signaturen stoppen holt eine gestohlene Kopie nicht zurück. Der Widerruf des Stammzertifikats wirkt breiter und trifft auch nicht delegierte Verbindungen.

Die Uhr ist Teil der Verfügbarkeit. valid_time bezieht sich auf notBefore des Zertifikats, der Client urteilt mit eigener Zeit. Drift nahe der Grenze verursacht Ablehnungen trotz grüner Serveranzeige. Rotation braucht Überlappung, Sicherheitsmarge und gemessene Fehler.

Auch Session Resumption darf den Ablauf nicht konservieren. Wer die Kette zwischenspeichert und neu bewertet, sollte das zugehörige Credential ebenfalls speichern und prüfen. Sonst lebt eine abgelaufene Grundlage in einer früheren Entscheidung weiter.

Zwei Verwahrungsmodelle, zwei Beweisprobleme

RFC 9677 erlaubt dem Downstream-CDN, sein Schlüsselpaar selbst zu erzeugen und nur den öffentlichen Schlüssel autorisieren zu lassen. Der private Schlüssel reist nicht, doch Enrollment muss Herkunft und Ziel beweisen. Alternativ liefert der Upstream eine verschlüsselte private Kopie mit. Das vereinfacht zentrale Erzeugung und schafft dauerhaftes Ciphertext-Inventar samt wichtigem Entschlüsselungsschlüssel.

Der RFC rät vom privaten Schlüsseltransport über Metadaten ab. Wird er gewählt, ist starke Verschlüsselung Pflicht, ohne Forward Secrecy gegen späteren Verlust des Transportkeys. Ablauf macht neue Handshakes unmöglich; Archive verschwinden nicht.

Ein Credential für viele Nodes senkt Rotation und vergrößert Blast Radius sowie Zuordnungsproblem. Pro Edge wird die Grenze enger, aber Signatur-, Verteilungs- und Ablaufzustände nehmen zu. Die sichere Einheit ist die kleinste, die sich bei Teilausfall noch rechtzeitig erneuern lässt.

Fallback bleibt ein Autoritätspfad

Der Mechanismus gilt nur für TLS/DTLS 1.3 und nach vorheriger Anzeige. IANAs empfohlene Registrierung belegt stabile Semantik, keine flächendeckende Nutzung. Cloudflare nennt Firefox 77 und neuer, zugleich aber sehr wenige Clients und CAs mit Unterstützung.

Gemischte Flotten brauchen daher Remote Signing, Zugriff auf den normalen Zertifikatsschlüssel oder ein weiteres Zertifikat. Remote Signing bringt Latenz und Backend-Abhängigkeit zurück. Schlüsselkopien bringen Langzeitrisiko zurück. Ein separates Zertifikat bringt Erneuerungs- und Widerrufsinventar zurück.

BoringSSL testet Ablehnung in TLS 1.2, getrennte Algorithmusfelder und den normalen Zertifikatspfad ohne passendes Credential. NSS verwendet beim Signieren den delegierten privaten und beim Prüfen den delegierten öffentlichen Schlüssel. Aktivierte Funktion und tatsächlich ausgeführter Pfad sind unterschiedliche Nachweise.

Das Beweisbuch einer Delegation

Festhalten: Zertifikatsfingerprint, Seriennummer, Namen, Laufzeit, KeyUsage und DelegationUsage; Hash von Credential und SPKI; Rolle, Algorithmen, berechnetes Ende; Genehmiger und Signaturereignis des Langzeitschlüssels.

Festhalten: Erzeuger oder Empfänger des privaten Schlüssels, Enrollment- oder Lieferweg, erlaubte Edges, Deployment-Quittungen und Fan-out. Je Handshake: Client-Angebot, Auswahl, Prüfungen, CertificateVerify, Version und Fallback.

Beim Ende: Stopp neuer Ausgabe, Entfernung je Node, letzter möglicher Zeitpunkt, Zertifikatswiderrufsentscheidung, Resumption und negativer Test nach Ablauf. Leere Konfiguration ist ein lokaler Zustand, kein Beleg für das Ende aller Kopien.

Quellen