{"id":17815,"date":"2026-08-04T01:01:55","date_gmt":"2026-08-04T08:01:55","guid":{"rendered":"https:\/\/www.omnitrust.com\/blog\/ilm-2-19-0-signing-timestamping-und-anforderungsattribute\/"},"modified":"2026-09-28T21:09:23","modified_gmt":"2026-09-29T04:09:23","slug":"ilm-2-19-0-signing-timestamping-und-anforderungsattribute","status":"publish","type":"post","link":"https:\/\/www.omnitrust.com\/de\/blog\/ilm-2-19-0-signing-timestamping-und-anforderungsattribute\/","title":{"rendered":"ILM 2.19.0: Signing, Timestamping und Anforderungsattribute"},"content":{"rendered":" \n

TL;DR:<\/strong> ILM 2.19.0 macht Signing und Timestamping zu vollwertigen Plattformfunktionen und verlagert PKI-Komplexit\u00e4t weg von der Person, die ein Zertifikat anfordert. Unter der Oberfl\u00e4che wird der Zertifikatsstatus jetzt durch eine explizite Zustandsmaschine verwaltet statt durch eine Reihe verstreuter Aktualisierungen.<\/p> \n\r\n

\u00a0<\/div>\r\n\r\n
\n

Die meisten Releases erg\u00e4nzen Funktionen. Dieses entfernt vor allem Gr\u00fcnde, die Plattform zu verlassen: um etwas zu signieren, einen Zeitstempel anzubringen oder einem Entwickler PKI zu erkl\u00e4ren, der einfach nur ein funktionierendes Zertifikat m\u00f6chte.<\/p> \n<\/div>\r\n\r\n

\u00a0<\/div>\r\n \n

Eine Release Note ist eine Liste von Pull Requests. Sie zeigt selten, was sich an Ihrer Arbeitsweise \u00e4ndert. Statt den Changelog zu wiederholen, f\u00fchrt dieser Beitrag durch die vier Themen, die den t\u00e4glichen Einsatz von ILM 2.19.0 tats\u00e4chlich pr\u00e4gen, und verweist auf die jeweiligen \u00c4nderungen dahinter.<\/p> \n \n

Der vollst\u00e4ndige Changelog ist mit dem Core-2.19.0-Release<\/a> auf GitHub ver\u00f6ffentlicht. Alles Folgende stammt daraus.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

Signing-Vorg\u00e4nge werden jetzt aufgezeichnet, nicht nur ausgef\u00fchrt<\/h2> \n \n

ILM 2.18.0 f\u00fchrte 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?<\/p> \n \n

2.19.0 beantwortet diese Frage. Jeder Signiervorgang erzeugt jetzt einen Signing-Datensatz. Zus\u00e4tzlich stellt jedes Signing-Profil einen Endpunkt bereit, der seine Datens\u00e4tze auflistet, und das Dashboard zeigt Signing-Statistiken neben den bereits vorhandenen Zertifikats- und Schl\u00fcsselkennzahlen.<\/p> \n \n

Das ist wichtiger, als es klingt. Eine Signing-Funktion ohne Audit-Trail ist schwer zu betreiben und bei einer \u00dcberpr\u00fcfung noch schwerer zu verteidigen. In der Praxis ist \u201eWer hat was signiert?\u201c die erste Frage eines Auditors und die letzte, die ein nachtr\u00e4glich angebundener Signing-Service beantworten kann.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

Timestamping, das sich tats\u00e4chlich aufrufen l\u00e4sst<\/h2> \n \n

Timestamping kam in Etappen. Die Verwaltung von TSP-Profilen wurde in 2.18.0 eingef\u00fchrt; 2.19.0 vervollst\u00e4ndigt den Weg zu einem nutzbaren Dienst.<\/p> \n \n

Drei \u00c4nderungen erledigen die Arbeit. Erstens f\u00fchrt 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.<\/p> \n \n

Da die Endpunkte RFC 3161 entsprechen, funktionieren bestehende Tools ohne \u00c4nderungen. Au\u00dferdem h\u00e4lt ein TSP-Profil-Cache die Profilsuche vom Request-Pfad fern \u2013 wichtig, wenn Timestamping Teil einer Build-Pipeline ist.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

Anforderungsattribute verlagern die Komplexit\u00e4t weg vom Antragsteller<\/h2> \n \n

Dies ist das gr\u00f6\u00dfte Thema des Releases und verdient einen eigenen Beitrag. Trotzdem lohnt es sich, die Grundidee hier zu beschreiben.<\/p> \n \n

Ein RA-Profil kann jetzt eine Konfiguration f\u00fcr Anforderungsattribute mit Wertquellen-Bindungen enthalten. Dadurch wei\u00df 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 \u00fcbertragen, sodass die Certificate Signing Request die Richtlinie widerspiegelt und nicht Vermutungen.<\/p> \n \n

Auch hochgeladene Anforderungen werden ber\u00fccksichtigt. ILM validiert eine mitgebrachte CSR gegen dieselbe Anforderungsattribut-Richtlinie und kann ein Zertifikat aus einer zuvor registrierten Anforderung ausstellen. Schlie\u00dflich werden Richtlinienverst\u00f6\u00dfe in native ACME-, EST-, SCEP- und CMP-Fehler \u00fcbersetzt, statt als undurchsichtige Fehler aufzutauchen.<\/p> \n \n

Dieses letzte Detail f\u00e4llt Operatoren besonders auf. Ein Protokoll-Client, der einen korrekten Protokollfehler erh\u00e4lt, kann darauf reagieren. Mit einem internen Fehler kann er das nicht.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

Der Zertifikatslebenszyklus wurde zu einer Zustandsmaschine<\/h2> \n \n

Der Zertifikatsstatus wurde fr\u00fcher von mehreren Stellen aus aktualisiert. Dadurch f\u00fchrten Randf\u00e4lle zu Zust\u00e4nden, die niemand beabsichtigt hatte, und Korrekturen waren meist lokal begrenzt.<\/p> \n \n

2.19.0 f\u00fchrt eine Zertifikats-Zustandsmaschine f\u00fcr Lifecycle-\u00dcberg\u00e4nge ein und leitet die v3-Zertifikatsregistrierung durch diese. Zus\u00e4tzlich ersetzt asynchrones Polling des Zertifikatsstatus das synchrone Warten, und ein CERTIFICATE_REGISTERED<\/code>-Ereignis wird ausgel\u00f6st, wenn die Vorregistrierung abgeschlossen ist. Authority-Instanzen erhielten v3-Unterst\u00fctzung sowohl f\u00fcr Lifecycle- als auch Provider-Vorg\u00e4nge.<\/p> \n \n

Architektonisch ist dies die folgenreichste \u00c4nderung des Releases, obwohl sie am wenigsten sichtbar ist. Eine explizite Zustandsmaschine macht ung\u00fcltige \u00dcberg\u00e4nge unm\u00f6glich, statt sie nur unwahrscheinlich zu machen.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

Was Sie au\u00dferdem wissen sollten<\/h2> \n \n

Mehrere kleinere \u00c4nderungen sind f\u00fcr bestimmte Teams relevant.<\/p> \n \n

\n \n \n \n \n \n \n \n \n \n
Bereich<\/th> \n\u00c4nderung<\/th> \nWarum das wichtig ist<\/th> \n<\/tr> \n<\/thead> \n
Governance<\/td> \nAuditor-Systemrolle mit geh\u00e4rteter Schreib- und Rollenzuweisungsautorisierung<\/td> \nSchreibgesch\u00fctzte Aufsicht ohne Vergabe operativer Rechte<\/td> \n<\/tr> \n
Erweiterungen<\/td> \nCERTIFICATE_EXTENSION<\/code>-Custom-OID-Register, Endpunkt zur Auflistung von System-OIDs, registrierte Systemerweiterungen<\/td> \nBenutzerdefinierte Erweiterungen werden zur Konfiguration statt zu Code<\/td> \n<\/tr> \n
Benennung<\/td> \nPlattform-RDN-Codes wie EMAIL werden in Subject-DNs akzeptiert, RDN-Code-Konflikte wurden gel\u00f6st<\/td> \nWeniger abgelehnte Anforderungen aufgrund gew\u00f6hnlicher Subject-Namen<\/td> \n<\/tr> \n
Performance<\/td> \nConnector-Roundtrips wurden aus der Ausstellungstransaktion entfernt; redundante Metadaten-Neuschreibungen beim Discovery-Import werden \u00fcbersprungen<\/td> \nK\u00fcrzere Transaktionen und schnellere gro\u00dfe Discoveries<\/td> \n<\/tr> \n
Protokolle<\/td> \nSCEP-Erneuerung ohne Challenge-Passwort, SCEP-Zustellung an EC-Clientschl\u00fcssel, mehrere CMP-Korrekturen<\/td> \nWeniger Protokoll-Sackgassen in realen Bereitstellungen<\/td> \n<\/tr> \n<\/tbody> \n<\/table> \n
Ausgew\u00e4hlte \u00c4nderungen in ILM 2.19.0 au\u00dferhalb der vier Hauptthemen.<\/figcaption> \n<\/figure> \n \n

Das Release behebt au\u00dferdem 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\u00e4ndigen Changelog.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

Wie sich dadurch die Rolle von ILM ver\u00e4ndert<\/h2> \n \n

ILM begann als Plattform f\u00fcr den Zertifikatslebenszyklus. Mit der Zeit kamen Schl\u00fcssel hinzu, dann Secrets und schlie\u00dflich Cryptographic Bills of Materials. 2.19.0 setzt diese Entwicklung fort, doch die Erg\u00e4nzungen sind keine blo\u00df angrenzenden Funktionen mehr. Signing und Timestamping sind eigenst\u00e4ndige Disziplinen, f\u00fcr die die meisten Organisationen separate Produkte einsetzen.<\/p> \n \n

Ihre Konsolidierung hat eine praktische statt nur eine marketingbezogene Folge. Eine Plattform bedeutet ein Inventar, ein Autorisierungsmodell und einen Audit-Trail f\u00fcr Zertifikate, Schl\u00fcssel, Secrets, Signaturen und Zeitstempel. Dadurch hat die Frage \u201eWelche kryptografischen Vorg\u00e4nge fanden letzten Monat statt?\u201c eine einzige Antwort statt vier Teilantworten.<\/p> \n \n

Wir benennen den Umfang offen. ILM ersetzt kein HSM und entscheidet Ihre kryptografische Richtlinie nicht f\u00fcr Sie. Es gibt diesen Entscheidungen einen zentralen Ort und einen Nachweis dar\u00fcber, dass sie angewendet wurden.<\/p> \n\r\n

\u00a0<\/div>\r\n
\r\n
\u00a0<\/div>\r\n\r\n
\n

Wichtigste Erkenntnisse<\/h3> \n\r\n\r\n \n