TL;DR: ILM 2.19.0 macht Signing und Timestamping zu vollwertigen Plattformfunktionen und verlagert PKI-Komplexität weg von der Person, die ein Zertifikat anfordert. Unter der Oberfläche wird der Zertifikatsstatus jetzt durch eine explizite Zustandsmaschine verwaltet statt durch eine Reihe verstreuter Aktualisierungen.
Die meisten Releases ergänzen Funktionen. Dieses entfernt vor allem Gründe, die Plattform zu verlassen: um etwas zu signieren, einen Zeitstempel anzubringen oder einem Entwickler PKI zu erklären, der einfach nur ein funktionierendes Zertifikat möchte.
Eine Release Note ist eine Liste von Pull Requests. Sie zeigt selten, was sich an Ihrer Arbeitsweise ändert. Statt den Changelog zu wiederholen, führt dieser Beitrag durch die vier Themen, die den täglichen Einsatz von ILM 2.19.0 tatsächlich prägen, und verweist auf die jeweiligen Änderungen dahinter.
Der vollständige Changelog ist mit dem Core-2.19.0-Release auf GitHub veröffentlicht. Alles Folgende stammt daraus.
Signing-Vorgänge werden jetzt aufgezeichnet, nicht nur ausgeführt
ILM 2.18.0 führte die Verwaltung von Signing-Profilen ein. Damit gab es einen Ort, an dem festgelegt wird, wie Signing erfolgt. Eine offensichtliche Frage blieb jedoch offen: Was ist passiert, wann und im Namen von wem?
2.19.0 beantwortet diese Frage. Jeder Signiervorgang erzeugt jetzt einen Signing-Datensatz. Zusätzlich stellt jedes Signing-Profil einen Endpunkt bereit, der seine Datensätze auflistet, und das Dashboard zeigt Signing-Statistiken neben den bereits vorhandenen Zertifikats- und Schlüsselkennzahlen.
Das ist wichtiger, als es klingt. Eine Signing-Funktion ohne Audit-Trail ist schwer zu betreiben und bei einer Überprüfung noch schwerer zu verteidigen. In der Praxis ist „Wer hat was signiert?“ die erste Frage eines Auditors und die letzte, die ein nachträglich angebundener Signing-Service beantworten kann.
Timestamping, das sich tatsächlich aufrufen lässt
Timestamping kam in Etappen. Die Verwaltung von TSP-Profilen wurde in 2.18.0 eingeführt; 2.19.0 vervollständigt den Weg zu einem nutzbaren Dienst.
Drei Änderungen erledigen die Arbeit. Erstens führt eine verwaltete TSP-Timestamping-Engine den Vorgang selbst aus. Zweitens stellen aufrufbare RFC-3161-Endpunkte ihn Clients bereit, die den Standard bereits sprechen. Drittens erhielten TSP-Profile Authentifizierungsmethoden und Basic-Credentials, mit einem eigenen Authentifizierungsfilter vor den Timestamping-Endpunkten.
Da die Endpunkte RFC 3161 entsprechen, funktionieren bestehende Tools ohne Änderungen. Außerdem hält ein TSP-Profil-Cache die Profilsuche vom Request-Pfad fern – wichtig, wenn Timestamping Teil einer Build-Pipeline ist.
Anforderungsattribute verlagern die Komplexität weg vom Antragsteller
Dies ist das größte Thema des Releases und verdient einen eigenen Beitrag. Trotzdem lohnt es sich, die Grundidee hier zu beschreiben.
Ein RA-Profil kann jetzt eine Konfiguration für Anforderungsattribute mit Wertquellen-Bindungen enthalten. Dadurch weiß die Plattform, welche Werte sie erfassen muss, welche sie ableiten kann und welche sie niemals von einem Client akzeptieren sollte. Diese Attributzuordnungen werden in die erzeugte PKCS#10-Anforderung übertragen, sodass die Certificate Signing Request die Richtlinie widerspiegelt und nicht Vermutungen.
Auch hochgeladene Anforderungen werden berücksichtigt. ILM validiert eine mitgebrachte CSR gegen dieselbe Anforderungsattribut-Richtlinie und kann ein Zertifikat aus einer zuvor registrierten Anforderung ausstellen. Schließlich werden Richtlinienverstöße in native ACME-, EST-, SCEP- und CMP-Fehler übersetzt, statt als undurchsichtige Fehler aufzutauchen.
Dieses letzte Detail fällt Operatoren besonders auf. Ein Protokoll-Client, der einen korrekten Protokollfehler erhält, kann darauf reagieren. Mit einem internen Fehler kann er das nicht.
Der Zertifikatslebenszyklus wurde zu einer Zustandsmaschine
Der Zertifikatsstatus wurde früher von mehreren Stellen aus aktualisiert. Dadurch führten Randfälle zu Zuständen, die niemand beabsichtigt hatte, und Korrekturen waren meist lokal begrenzt.
2.19.0 führt eine Zertifikats-Zustandsmaschine für Lifecycle-Übergänge ein und leitet die v3-Zertifikatsregistrierung durch diese. Zusätzlich ersetzt asynchrones Polling des Zertifikatsstatus das synchrone Warten, und ein CERTIFICATE_REGISTERED-Ereignis wird ausgelöst, wenn die Vorregistrierung abgeschlossen ist. Authority-Instanzen erhielten v3-Unterstützung sowohl für Lifecycle- als auch Provider-Vorgänge.
Architektonisch ist dies die folgenreichste Änderung des Releases, obwohl sie am wenigsten sichtbar ist. Eine explizite Zustandsmaschine macht ungültige Übergänge unmöglich, statt sie nur unwahrscheinlich zu machen.
Was Sie außerdem wissen sollten
Mehrere kleinere Änderungen sind für bestimmte Teams relevant.
| Bereich | Änderung | Warum das wichtig ist |
|---|---|---|
| Governance | Auditor-Systemrolle mit gehärteter Schreib- und Rollenzuweisungsautorisierung | Schreibgeschützte Aufsicht ohne Vergabe operativer Rechte |
| Erweiterungen | CERTIFICATE_EXTENSION-Custom-OID-Register, Endpunkt zur Auflistung von System-OIDs, registrierte Systemerweiterungen |
Benutzerdefinierte Erweiterungen werden zur Konfiguration statt zu Code |
| Benennung | Plattform-RDN-Codes wie EMAIL werden in Subject-DNs akzeptiert, RDN-Code-Konflikte wurden gelöst | Weniger abgelehnte Anforderungen aufgrund gewöhnlicher Subject-Namen |
| Performance | Connector-Roundtrips wurden aus der Ausstellungstransaktion entfernt; redundante Metadaten-Neuschreibungen beim Discovery-Import werden übersprungen | Kürzere Transaktionen und schnellere große Discoveries |
| Protokolle | SCEP-Erneuerung ohne Challenge-Passwort, SCEP-Zustellung an EC-Clientschlüssel, mehrere CMP-Korrekturen | Weniger Protokoll-Sackgassen in realen Bereitstellungen |
Das Release behebt außerdem eine lange Reihe von Fehlern in Benachrichtigungen, Discovery und CMP-Verarbeitung. Wenn Sie einen dieser Fehler bislang umgehen mussten, lohnt sich ein Blick in den vollständigen Changelog.
Wie sich dadurch die Rolle von ILM verändert
ILM begann als Plattform für den Zertifikatslebenszyklus. Mit der Zeit kamen Schlüssel hinzu, dann Secrets und schließlich Cryptographic Bills of Materials. 2.19.0 setzt diese Entwicklung fort, doch die Ergänzungen sind keine bloß angrenzenden Funktionen mehr. Signing und Timestamping sind eigenständige Disziplinen, für die die meisten Organisationen separate Produkte einsetzen.
Ihre Konsolidierung hat eine praktische statt nur eine marketingbezogene Folge. Eine Plattform bedeutet ein Inventar, ein Autorisierungsmodell und einen Audit-Trail für Zertifikate, Schlüssel, Secrets, Signaturen und Zeitstempel. Dadurch hat die Frage „Welche kryptografischen Vorgänge fanden letzten Monat statt?“ eine einzige Antwort statt vier Teilantworten.
Wir benennen den Umfang offen. ILM ersetzt kein HSM und entscheidet Ihre kryptografische Richtlinie nicht für Sie. Es gibt diesen Entscheidungen einen zentralen Ort und einen Nachweis darüber, dass sie angewendet wurden.
Wichtigste Erkenntnisse
- Jeder Signing-Vorgang hinterlässt jetzt einen Signing-Datensatz, der pro Signing-Profil aufgelistet werden kann und in den Dashboard-Statistiken sichtbar ist.
- Timestamping ist über RFC 3161 aufrufbar, unterstützt durch eine verwaltete Engine und authentifizierte TSP-Profile.
- RA-Profile enthalten Anforderungsattribut-Richtlinien mit Wertquellen-Bindungen; Verstöße liefern native ACME-, EST-, SCEP- und CMP-Fehler.
- Übergänge im Zertifikatslebenszyklus laufen durch eine explizite Zustandsmaschine, dahinter arbeitet asynchrones Status-Polling.
- Eine Auditor-Rolle und ein Custom-OID-Register machen Aufsicht und Zertifikatserweiterungen zu Konfiguration statt zu Sonderarbeit.
ILM ist Open Source, sodass Sie jede Änderung hinter diesem Release selbst nachvollziehen können. Wenn Sie vor einer Entscheidung sehen möchten, was die Plattform abdeckt, beginnen Sie mit 10 Dingen, die Sie mit ILM aufbauen können, oder lesen Sie, warum wir ILM als Open Source veröffentlicht haben. Wenn Sie eine konkrete Bereitstellung besprechen möchten, sprechen Sie mit uns.
