{"id":17803,"date":"2026-08-05T01:50:52","date_gmt":"2026-08-05T08:50:52","guid":{"rendered":"https:\/\/www.omnitrust.com\/blog\/ilm-anforderungsattribute-pki-ohne-pki-vorlesung\/"},"modified":"2026-09-28T21:09:22","modified_gmt":"2026-09-29T04:09:22","slug":"ilm-anforderungsattribute-pki-ohne-pki-vorlesung","status":"publish","type":"post","link":"https:\/\/www.omnitrust.com\/de\/blog\/ilm-anforderungsattribute-pki-ohne-pki-vorlesung\/","title":{"rendered":"ILM-Anforderungsattribute: PKI ohne PKI-Vorlesung"},"content":{"rendered":" \n

TL;DR:<\/strong> Mit ILM-Anforderungsattributen kann ein RA-Profil festlegen, was eine Zertifikatsanforderung ben\u00f6tigt, woher jeder Wert stammt und was ein Client niemals setzen darf. So f\u00fcllt der Antragsteller ein kurzes Formular aus, statt PKI lernen zu m\u00fcssen, und die Vertrauensgarantien bleiben genau dort, wo sie waren.<\/p> \n\r\n

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

Niemand will ein Zertifikat. Man will das, was ohne Zertifikat nicht mehr funktioniert. Jede zus\u00e4tzliche Frage ist eine Abgabe, die Sie f\u00fcr Ihre eigene Richtlinie erheben.<\/p> \n<\/div>\r\n\r\n

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

Denken Sie daran, womit ein Entwickler normalerweise konfrontiert ist, wenn er ein internes Zertifikat anfordert. Welche Vorlage? Welcher Schl\u00fcsselalgorithmus und welche Schl\u00fcssell\u00e4nge? Welche Erweiterungen mit welchen Key Usages? Was geh\u00f6rt in den Subject-Namen und in welcher Reihenfolge? Welcher der verschiedenen Subject-Alternative-Name-Typen gilt hier?<\/p> \n \n

Auf jede Frage gibt es eine richtige Antwort. Der Entwickler ist jedoch nur selten die Person, die sie kennt. Deshalb entsteht die Antwort durch Kopieren einer fr\u00fcheren Anforderung, durch Nachfragen bei einem Kollegen oder durch Raten. Dann wird die Anforderung abgelehnt und der Zyklus beginnt von vorn.<\/p> \n \n

Unterdessen wird dem PKI-Team vorgeworfen, langsam zu sein. Tats\u00e4chlich soll es Entscheidungen kontrollieren, die nie vom Antragsteller h\u00e4tten getroffen werden sollen.<\/p> \n\r\n

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

Was Anforderungsattribute tats\u00e4chlich festlegen<\/h2> \n \n

Ein RA-Profil in ILM kann jetzt eine Konfiguration f\u00fcr Anforderungsattribute enthalten. Diese Konfiguration ist eine Richtlinienerkl\u00e4rung, keine Formulardefinition. Sie legt fest, welche Attribute eine Anforderung besitzt, und bindet jedes davon an eine Wertquelle.<\/p> \n \n

Diese Bindungen sind der entscheidende Teil. Ein Wert kann vom Antragsteller erfasst, von der Plattform abgeleitet oder durch eine Richtlinie fest vorgegeben werden. Damit kodiert das Profil drei verschiedene Arten von Wissen, die fr\u00fcher auf einer Wiki-Seite standen.<\/p> \n \n

\n \n \n \n \n \n \n \n
Wertquelle<\/th> \nWer entscheidet<\/th> \nTypisches Beispiel<\/th> \n<\/tr> \n<\/thead> \n
Erfasst<\/td> \nDer Antragsteller<\/td> \nDer Hostname, f\u00fcr den das Zertifikat bestimmt ist<\/td> \n<\/tr> \n
Abgeleitet<\/td> \nDie Plattform<\/td> \nEigent\u00fcmer und Gruppe, \u00fcbernommen aus der authentifizierten Identit\u00e4t<\/td> \n<\/tr> \n
Durch Richtlinie festgelegt<\/td> \nDas PKI-Team, einmalig<\/td> \nSchl\u00fcsselalgorithmus, Key Usage, Erweiterungssatz<\/td> \n<\/tr> \n<\/tbody> \n<\/table> \n
Anforderungsattribute binden jeden Wert an die Stelle, die berechtigterweise f\u00fcr diese Entscheidung verantwortlich ist.<\/figcaption> \n<\/figure> \n \n

Lesen Sie die Tabelle als Arbeitsteilung. Der Antragsteller wird nur nach dem gefragt, was er tats\u00e4chlich wei\u00df. Alles andere wird entweder abgeleitet oder wurde bereits entschieden.<\/p> \n\r\n

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

Die Richtlinie reicht bis in die Anforderung selbst<\/h2> \n \n

Ein Formular, das die richtigen Werte erfasst, l\u00f6st nur die H\u00e4lfte des Problems. Die Werte m\u00fcssen anschlie\u00dfend korrekt in die Certificate Signing Request gelangen.<\/p> \n \n

ILM \u00fcbertr\u00e4gt die Feldzuordnungen der Attribute in die erzeugte PKCS#10-Anforderung. Dadurch spiegelt die CSR die Richtlinie des Profils wider und nicht das, was eine Client-Bibliothek zuf\u00e4llig zusammengestellt hat. Subject und Erweiterungen werden aus derselben Deklaration erstellt, die der Antragsteller ausgef\u00fcllt hat.<\/p> \n \n

Hochgeladene Anforderungen werden genauso behandelt. Wenn Sie Ihre eigene CSR mitbringen, validiert ILM sie gegen die Anforderungsattribut-Richtlinie des RA-Profils, statt ihr einfach zu vertrauen. Au\u00dferdem kann eine Anforderung zun\u00e4chst registriert und sp\u00e4ter ausgestellt werden, sodass Vorregistrierung und Ausstellung getrennte Schritte sein k\u00f6nnen, wenn ein Workflow dies erfordert.<\/p> \n\r\n

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

Fehler, mit denen ein Protokoll-Client arbeiten kann<\/h2> \n \n

Hier liegt das Detail, das dar\u00fcber entscheidet, ob sich all dies nahtlos anf\u00fchlt. Die meisten Zertifikatsanforderungen stammen gar nicht von einer Person. Sie kommen von ACME-, EST-, SCEP- oder CMP-Clients, die unbeaufsichtigt laufen.<\/p> \n \n

Wenn ein solcher Client gegen eine Richtlinie verst\u00f6\u00dft, ist ein allgemeiner Fehler nutzlos. Der Client kann ihn nicht interpretieren, nicht sinnvoll erneut versuchen und nichts Handlungsrelevantes melden. Tage sp\u00e4ter liest jemand ein Protokoll.<\/p> \n \n

ILM formt Verst\u00f6\u00dfe gegen Anforderungsattribut-Richtlinien in native ACME-, EST-, SCEP- und CMP-Fehler um. Da der Fehler im eigenen Vokabular des Protokolls ankommt, kann der Client korrekt reagieren. Au\u00dferdem l\u00e4sst sich der erwartete Satz von Anforderungsattributen \u00fcber den CSR-Attributes-Endpunkt abfragen, sodass ein Client vor dem Erstellen einer Anforderung ermitteln kann, was erwartet wird.<\/p> \n \n

\n
\n

Die Plattform zu fragen, was sie ben\u00f6tigt, ist ein besseres Protokoll, als zu raten und abgewiesen zu werden.<\/p> \n<\/blockquote> \n<\/figure> \n\r\n

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

Erweiterungen ohne benutzerdefinierten Code<\/h2> \n \n

Zertifikatserweiterungen sind ein h\u00e4ufiger Grund daf\u00fcr, dass Organisationen ma\u00dfgeschneiderte Werkzeuge pflegen m\u00fcssen. Eine Richtlinie braucht eine einzige benutzerdefinierte Erweiterung, und pl\u00f6tzlich enth\u00e4lt der Ausstellungsweg einen Patch.<\/p> \n \n

ILM verf\u00fcgt jetzt \u00fcber ein Custom-OID-Register f\u00fcr Zertifikatserweiterungen, registriert die bekannten Systemerweiterungen und stellt einen Endpunkt bereit, der System-OIDs auflistet. Damit wird eine benutzerdefinierte Erweiterung zur Konfiguration. Zus\u00e4tzlich werden Plattform-RDN-Codes wie EMAIL in Subject-Namen akzeptiert, wodurch eine bekannte Klasse abgelehnter Anforderungen entf\u00e4llt.<\/p> \n\r\n

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

Nahtlos bedeutet nicht nachl\u00e4ssig<\/h2> \n \n

All dies k\u00f6nnte leicht als Lockerung der Kontrolle verstanden werden. Das Gegenteil ist der Fall, und dieser Unterschied ist wichtig.<\/p> \n \n

Zuvor konnte ein Antragsteller nahezu alles in eine CSR schreiben, und die Plattform musste es anschlie\u00dfend abfangen. Jetzt legt das Profil fest, was zul\u00e4ssig ist; Werte, die der Client nicht kontrollieren sollte, werden abgeleitet oder fest vorgegeben; und hochgeladene Anforderungen werden gegen dieselbe Richtlinie gepr\u00fcft. Mit anderen Worten: weniger Fragen f\u00fcr den Antragsteller und weniger M\u00f6glichkeiten, etwas falsch zu machen.<\/p> \n \n

Vertrauen in einer PKI entsteht dadurch, dass die Richtlinie konsistent angewendet wird. Es ist nie dadurch entstanden, dass Menschen beweisen m\u00fcssen, dass sie sie verstehen. Wenn die Komplexit\u00e4t in das Profil verlagert wird, steigt daher die Sicherheit, statt zu sinken.<\/p> \n \n

Ein ehrlicher Vorbehalt: Jemand muss die Richtlinie weiterhin schreiben. Anforderungsattribute entscheiden nicht, was Ihre PKI erlauben sollte. Sie machen diese Entscheidung explizit, wiederverwendbar und an einer Stelle durchsetzbar, statt sie immer wieder von Menschen interpretieren zu lassen, die im Zweifel raten.<\/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