Zusammenfassung

  • Beim gewöhnlichen CMP-over-HTTP-Austausch verlangt RFC 9811 200 OK und eine CMP-Antwort im Body. Der äußere Erfolg entscheidet nicht, ob der PKI-Vorgang angenommen, verändert bewilligt, abgelehnt oder auf Warten gesetzt wurde.
  • Ein belastbarer Nachweis verbindet Zielinstanz, HTTP, geschützte PKIMessage, transactionID, Polling, Bestätigung, Schlüsselspeicher und Prüfung durch abhängige Systeme, ohne diese Zustände gleichzusetzen.

Die gefährlichste Zeile in einer Zertifikatsautomatisierung kann grün sein: 200 OK, also erledigt.

Nur der erste Teil folgt aus HTTP. RFC 9811, seit Juli 2025 ein Standards-Track-RFC der IETF, bindet das Certificate Management Protocol an HTTP. Eine DER-codierte PKIMessage wird als Inhalt eines POST mit application/pkixcmp versandt. Ist diese gewöhnliche HTTP-Anfrage erfolgreich, steht die CMP-Antwort im Body einer 200-Antwort. Andere erfolgreiche 2xx-Codes dürfen dafür nicht verwendet werden.

Die genaue Form erweitert die Macht von HTTP nicht. Sie hält den äußeren Beleg konstant, damit das innere Protokoll entscheiden kann.

Zwei Statusräume in einer Antwort

RFC 9810 kennt unter anderem accepted, grantedWithMods, rejection und waiting. Deshalb kann 200 eine exakte Bewilligung, eine veränderte Bewilligung, eine Ablehnung oder einen unfertigen Vorgang tragen. Ein HTTP-Erfolgsdiagramm zeigt für alle dieselbe Farbe, obwohl jede Variante eine andere Folgehandlung verlangt.

Auch ein früher Abbruch bei 4xx oder 5xx ist falsch. RFC 9811 verlangt, dass Clients CMP-Antworten im Inhalt von 2xx-, 4xx- und 5xx-Antworten verarbeiten können. Ein äußerer Fehler kann zusammen mit der präzisesten geschützten Erklärung des inneren Protokolls eintreffen.

Die Prüfung ist daher eine Kette: HTTP-Antwort empfangen, Medientyp und Grenzen prüfen, DER lesen, CMP-Schutz und Absender verifizieren, Nachricht der Transaktion zuordnen, anschließend Body-Typ, Status und Fehlerinformation interpretieren. Jede Stufe beweist nur ihren eigenen Übergang.

Keine Antwort ist eine offene Frage

Fehlt die Bestätigung durch eine HTTP-Antwort, muss laut RFC 9811 angenommen werden, dass die CMP-Nachricht nicht erfolgreich zugestellt wurde. Das ist eine vorsichtige Transportregel. Sie verhindert eine unbelegte Erfolgsmeldung, kann aber nicht beweisen, dass der Server keinerlei Zustand erzeugte.

Die Verbindung kann abbrechen, nachdem die Instanz die Anfrage gelesen oder verarbeitet hat. Beim Client bleibt die Zustellung unbestätigt, während bei CA oder RA bereits eine Transaktion bestehen kann. Ein sofortiger Neuversuch mit neuer Kennung riskiert ein Duplikat; gar kein Neuversuch gefährdet die Verlängerung.

Eine sichere Wiederaufnahme bewahrt transactionID, Hash der ursprünglichen Nachricht, Zielinstanz, Vorgangstyp und Zeitgrenze. Wo CMP Fortsetzung oder Polling vorsieht, ist dieser Weg zu nutzen. Lässt sich der Zustand nicht abgleichen, muss er als ungewiss eskaliert werden. Eine neue Transaktion macht die alte Ungewissheit nicht wahrheitsgemäß verschwinden.

Zustand über zustandslosen Transport

Manche PKI-Vorgänge bestehen aus mehreren Anfrage-Antwort-Paaren. HTTP kann jede Übertragung einzeln behandeln; die CMP-transactionID hält sie als einen Vorgang zusammen. Nach ihrer Festlegung muss derselbe Wert in Folgemeldungen erscheinen. Ein Client darf gegenüber demselben Server nicht gleichzeitig zwei Transaktionen mit derselben Kennung führen.

RFC 9810 empfiehlt 128 pseudozufällige Bits für eine vom Client erzeugte Kennung. Ein Server kann je nach Client-Erkennung Eindeutigkeit für {Client, transactionID} oder für die Kennung allein verlangen. Verhindert eine Kollision die richtige Zuordnung, folgt transactionIdInUse.

Zuordnung ist keine Authentisierung. Das Feld beweist weder Identität noch Berechtigung, Integrität oder geschäftliche Idempotenz. CMP-Nachrichtenschutz, Nonces, Anforderungskennungen und lokale Regeln tragen andere Befugnisse. Eine Prüfkette soll sie verbinden, nicht eine Laufnummer zum Berechtigungsnachweis erklären.

waiting läuft nach dem HTTP-Ende weiter

Der Status waiting bedeutet, dass der Anfrageinhalt noch nicht verarbeitet wurde. Der Client sendet pollReq. CA oder RA liefern bei Abschluss die endgültige Antwort, sonst pollRep mit checkAfter. Vor der nächsten Abfrage muss mindestens diese Zeit verstreichen.

Hinter der Wartezeit können Backend-Last, Offline-Transport zwischen PKI-Instanzen oder die Genehmigung durch eine RA-Fachkraft stehen. Die Netzwerkrunde ist beendet, die organisatorische Entscheidung offen.

Automatisierung muss Verantwortlichen, frühesten Poll-Zeitpunkt, Gesamtalter, Eskalationsschwelle und Restlaufzeit des bestehenden Zertifikats speichern. Häufigeres Polling beschleunigt keine menschliche Freigabe und verschärft möglicherweise Kapazitätsprobleme. Wer waiting als Ablehnung wertet, erzeugt Parallelvorgänge; wer es als Bewilligung wertet, meldet ein nicht vorhandenes Zertifikat als fertig.

Ausgestellt heißt nicht abgeschlossen

Mit certConf kann der Client ein zurückgegebenes Zertifikat annehmen oder ablehnen; pkiconf bestätigt den Abschluss. Hat die CA gewünschte Felder verändert, muss das tatsächliche Zertifikat geprüft werden. grantedWithMods ist keine pauschale Installationsfreigabe.

Die Belege verteilen sich auf geschützte Antwort, Status, Fingerabdruck, Abweichung von der Anfrage, Client-Bestätigung, Protokollabschluss, Schreiben in den Speicher, Aktivierung im Dienst und Validierung durch vertrauende Systeme. Ein Fingerabdruck verknüpft sie, beweist sie aber nicht.

Die CA-Datenbank kann das neue Zertifikat enthalten, während ein Load Balancer noch das alte präsentiert. Das Deployment kann grün sein, obwohl wichtige Clients Kette, Name, Zweck oder Laufzeit zurückweisen. Umgekehrt kann ein Dienst funktionieren, während die CMP-Bestätigung fehlt. Betrieb und Protokollabschluss brauchen eigene Nachweise.

Ankündigungen haben einen anderen Beleg

Bei gepushten CA-Schlüssel-, Zertifikats-, Sperr- oder CRL-Ankündigungen wird der CMP-Server zum HTTP-Client. Der Empfänger sendet keine CMP-Antwort, sondern eine leere HTTP-Antwort.

201 Created bedeutet, dass die Information gespeichert wurde oder schon vorhanden war. 202 Accepted bedeutet nur Annahme zur späteren Verarbeitung; der Sender kann nach einer Wartezeit erneut senden, bis die Verarbeitung bestätigt ist. Diese Bedeutungen gehören nicht in den gewöhnlichen Ablauf, in dem 200 die CMP-Entscheidung trägt.

Ohne geeignete Authentisierung und Schutz ist die Verarbeitungsbestätigung nicht vertrauenswürdig. Das PKI-Design darf dann nicht von garantierter Zustellung abhängen. Ein Statuscode wird erst durch Herkunft und Schutz zum Nachweis.

/.well-known/cmp normiert den Pfad, nicht die Instanz

CMP-Server mit HTTP oder HTTPS müssen /.well-known/cmp unterstützen. Weitere Segmente können Vorgang, CA oder Profil unterscheiden. Im IANA-Register für Well-Known URIs ist cmp als permanenter, von der IETF kontrollierter Suffix eingetragen.

Der Pfad sagt, wo auf einer Origin gefragt wird; er findet nicht den richtigen Host. RFC 8615 definiert keine Host-Ermittlung und warnt vor der Origin-weiten Kontrollwirkung solcher Pfade. Konfigurationsquelle, Namensauflösung, Weiterleitung, TLS-Gegenstelle, geschützter CMP-Absender und lokale Vertrauensregel müssen erhalten bleiben.

RFC 9811 erlaubt 3xx, verlangt aber Vorsicht bei automatischer Verfolgung. Ein bösartig gespeichertes 301-Ziel kann den Client dauerhaft vom korrekten Server trennen. HTTP-Komfort darf den PKI-Vertrauenspunkt nicht stillschweigend verschieben.

Übergaben statt Erfolgsbit

Ein Mindestdatensatz umfasst erwartete CA/RA, konfigurierte und endgültige URI, Weiterleitungen, TLS-Gegenstelle, HTTP-Methode, Status, Medientyp und Body-Hashes; CMP-Absender, Empfänger, Nachrichtentyp und Schutzprüfung; transactionID, Nonces und Anforderungskennung; PKIStatus, Fehler und checkAfter; Zertifikatfingerabdruck, Abweichungen, certConf/pkiconf; Speicherversion, Aktivierung, Rollback und unabhängige Beobachtungen wichtiger Dienste.

Er bewahrt auch Grenzen: Ohne Antwort bleibt Zustellung unbestätigt. 200 bedeutet Antwort erhalten. Ausgestellt bedeutet Objekt erzeugt. Installiert bedeutet lokalen Zustand verändert. Eine erfolgreiche Verbindung bedeutet Akzeptanz durch genau diesen Vertrauenden. Keine Stufe darf die nächste erfinden.

Running-Code Primacy verlangt die letzte Prüfung am laufenden Client, am CA/RA-Zustand, am Schlüsselspeicher und an realen Verbindungen. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption rechtfertigt eine enge gemeinsame Bindung, ohne Zertifikatspolitik und Deployment zu zentralisieren. Reality Layers verhindert, dass mehrere wahre Zustände zu einem grünen Symbol verschmelzen.

RFC 9811 schwächt 200 OK nicht. Es macht den Beleg ehrlich: Die HTTP-Anfrage war erfolgreich, die CMP-Antwort kam an. Die Zertifikatsentscheidung muss noch darin gelesen werden.

Quellen