Zusammenfassung

  • draft-ietf-acme-profiles-02 lässt Server lokale Profile ankündigen und die Auswahl an einen Order binden. Der Text ist ein Standards-Track-Entwurf, keine RFC und kein weltweites Profilregister.
  • Der Profilname belegt eine akzeptierte Richtlinienwahl. Kontoberechtigung, Identifier-Kontrolle, DER-Konformität, Installation und Client-Akzeptanz bleiben getrennt.
  • Der belastbare Nachweis friert Directory und Beschreibung zum Bestellzeitpunkt ein und prüft danach Zertifikat und ausgelieferten Endpunkt.

Der Automatisierungsjob ist grün und der Order enthält tlsserver. Trotzdem liefert ein Knoten das alte Zertifikat, im neuen steht eine unerwartete EKU und ein Client verwirft die Kette. Der Profilname ist nicht falsch; er wurde nur zum Beweis für spätere Vorgänge gemacht.

draft-ietf-acme-profiles-02 vom 28. August 2026 ist laufende Arbeit der ACME Working Group. RFC 8555 kennt keine saubere Fläche, auf der eine CA mehrere Zertifikatspolitiken anbieten und ein Client eine davon auswählen kann. Der Entwurf schließt diese Lücke. Zwei Server und sieben Clients werden genannt, Let’s Encrypt beschreibt Produktion. Das ist Implementierungsevidenz, kein finaler Standard und keine vollständige Verbreitungsstudie.

Ein lokaler Selektor

Der Server veröffentlicht meta.profiles in der Directory. Jeder Kurzname verweist auf eine menschenlesbare Beschreibung. Der Client kann ihn in newOrder senden; der akzeptierte Order gibt ihn zurück.

Die Bedeutung bleibt beim Server. Gleich geschriebene Namen müssen bei verschiedenen CAs nicht dasselbe bedeuten. Die Beschreibung ist kein vorgeschriebenes maschinenlesbares X.509-Schema und darf als Data-URI erscheinen. Der String verweist auf lokale Policy, nicht auf ein universelles Gütesiegel.

Das ist eine Stärke minimaler Spezifikation. Der Client äußert eine Absicht, ohne Produktlogik in den CSR zu packen. Die CA bietet Auswahl ohne Neben-API. Produkt, Preis und interne Genehmigung bleiben lokal.

Zum Namen gehören deshalb Directory-URL, Antwort-Hash, Zeit, TLS-Peer, Dokumentbytes und Kontobedingungen. Wer nur tlsserver speichert, verliert den Namensraum.

Policy verlässt den CSR, der Schlüssel nicht

RFC 8555 nimmt Identifier im Order und später einen CSR entgegen. CSR-Erweiterungen blind zu übernehmen erhöht Parsing- und Fehlerrisiken.

Profiles verschiebt die Auswahl in den Order. Für diese Entscheidung sollen CSR-Inhalte jenseits von SAN und Subject Public Key keine Rolle spielen. Die CA baut nach eigener Vorlage.

Der CSR ist nicht vollständig bedeutungslos. Schlüssel und SAN bleiben wesentlich. Korrekte Konstruktion, Signatur, Kette, Policy und Transparenz bleiben Aufgaben der CA. Die Erweiterung räumt nur die Schnittstelle auf.

Clientwahl oder Serverdefault

Sendet der Client explizit ein Profil, belegt die signierte ACME-Nachricht die Absicht des Kontos. Der Server prüft weiterhin die Zulässigkeit.

Fehlt das Feld, empfiehlt der Entwurf eine serverseitige Auswahl. Dann ist der Wert im Order ein Serverentscheid, keine aktive Subscriberwahl.

Protokolliert werden Ursprung, Clientversion, Konfiguration, Konto, Request, Response, Serverpolicy und Änderungsbefugnis. Nur so lässt sich frühe freiwillige Migration von einem Defaultwechsel bei unverändertem Client trennen.

Die Let’s-Encrypt-Zeitpläne zeigen diesen Unterschied: optionale Profile führen engere EKUs oder kürzere Laufzeiten vor classic ein. Beide Wege können richtig sein, verteilen Verantwortung aber anders.

Berechtigung ist nicht Domainkontrolle

Inkompatible Kombinationen müssen mit dem vorgeschlagenen invalidProfile abgelehnt werden, etwa falscher Identifiertyp oder Konto außerhalb einer Allowlist.

Das ist nicht die ACME-Autorisierung. Ein Konto kann für ein Privatprofil freigeschaltet sein, ohne die Domain nachzuweisen. DNS-01-Erfolg verleiht nicht automatisch Sonderprofilrechte.

Drei Belege gehören auseinander: Profilberechtigung, Prüfung jedes Identifiers und Emissionsentscheidung. EAB, Vertrag, Zahlung, Incident-Freigabe oder Allowlist stützen den ersten; Challenges den zweiten; CA-Akte und Zertifikat den dritten.

Nicht angekündigt heißt nicht unbegründet

Nicht beworbene Namen sollten abgelehnt werden, dürfen aber ausnahmsweise akzeptiert werden. Der Entwurf nennt Privatabsprachen und Ersatz bei Massensperrung.

Die Ausnahme schützt Kontinuität. Sie bedeutet zugleich, dass Abwesenheit in der Directory keine Ungültigkeit beweist. Erforderlich sind Vereinbarung oder Incident, Konten, Zeitraum, Grenzen, Genehmiger, Ersatzzweck und Rücknahme. Privat ist nicht missbräuchlich; nicht nachvollziehbar ist nicht auditierbar.

Zwei Uhren beim Rückzug

Ein Profil kann aus der Directory verschwinden, während Orders weiterleben. Will die CA bei Finalisierung nicht mehr ausstellen, muss invalidProfile folgen. Besser lässt sie bestehende Orders zuerst ablaufen.

Directory-Zeit und Order-Zeit sind verschieden. Erfasst werden Ankündigung, letzter Order, spätester Ablauf, letzte Ausgabe, offene Renewals, Ersatz und Ausnahmen.

Auch ein stabiler Name kann semantisch driften: Laufzeit, EKU, Wiederverwendung oder Kette ändern sich. Daher Definition pro Order einfrieren und jedes Renewal neu prüfen.

Der DER ist das Konformitätsobjekt

Der Order ist das Policyversprechen, das Zertifikat das prüfbare Ergebnis.

Ein Test vergleicht SANs, Identifiertypen, Schlüssel, Key Usage, EKU, Basic Constraints, Policies, Criticality, Laufzeit, Issuer, Signatur, Kette, Seriennummer, Encoding, CT und verbotene Felder mit einem versionierten Prädikat. Zusätzlich bindet er den DER an Order, Autorisierungen und CSR-Schlüssel.

Prosa hilft Menschen bei der Wahl, ist für Automation schwach. Eine CA könnte ein maschinenprüfbares Manifest anbieten. Das ist ein Betriebsvorschlag, keine Draftpflicht. So wird ein lokales Versprechen prüfbar, ohne zentralen Produktkatalog.

Renewals brauchen denselben Test. Gleicher Name garantiert keine gleiche Version oder Kette. Nur die ACME-Antwort zu prüfen heißt, die Credential zu überspringen.

CT, CAA und Trust Path bleiben eigenständig

CT belegt Logging, nicht Profilwahl, Konformität oder Deployment. CAA beschränkt Aussteller unter eigenen Regeln, wählt aber kein Profil und beschreibt nicht den DER.

Die CA kann eine Kette anbieten, der Client kann lokal eine andere bauen. Profilabsicht erzwingt keine Trustentscheidung. Die Kontrollen sind wertvoll, weil sie unabhängig bleiben.

Ausstellung ist kein Rollout

Zertifikat und Schlüssel müssen zum richtigen Ziel. Load Balancer, Regionen, Secret Stores, Sidecars und alte Prozesse verursachen Teilrollouts.

DER- und Schlüsselhash an jedes Ziel binden, extern beobachten, SNI, Identität, Kette, Aktivierung und Ablösung prüfen, dann repräsentative Clients testen.

Die Kette lautet entdecken -> bewahren -> wählen -> berechtigen -> Identifier autorisieren -> Order binden -> finalisieren -> prüfen -> ausrollen -> beobachten -> erneuern. Jede Stufe kann die nächste nicht garantieren.

Produktion zeigt gestufte Migration

Let’s Encrypt beschreibt Profile als Eigenschaften von Validierung und Endzertifikat. Für EKU wurde tlsserver vor dem Default geändert und tlsclient zeitweise erhalten. Kürzere Laufzeiten erscheinen zunächst opt-in.

Das zeigt reale Steuerung zwischen Frühnutzung, Defaultwechsel und befristeter Kompatibilität. Es zeigt zugleich, dass Namen Zeit brauchen. Laufzeit, EKU, Authorization-Reuse und Verfügbarkeit ändern sich getrennt.

Es beweist weder Migration jedes Subscribers noch universellen Clientsupport. Es belegt die Nutzung durch eine CA.

Ein Profilbeleg

Der Beleg verknüpft Directory, Dokumentation, Auswahlursprung, Konto, Konfigurationsmacht, Identifier, Schlüssel, Berechtigung, Autorisierungen, Order, CSR, DER, Serie, Issuer, Kette, CT, Konformität, Ziele, Beobachtung, Clients, Renewal, Ausnahme und Rollback.

„Order gab den Namen zurück“ ist Beobachtung. „DER erfüllt Version X“ ist Test. „Endpoint lieferte DER“ ist weitere Beobachtung. Geschäftsergebnis folgt später.

Das Protokoll bleibt klein; die Beteiligten halten lokale Nachweise. Ein Name muss nicht alle Entscheidungen beherrschen, um nützlich zu sein.