TL;DR: Mit ILM-Anforderungsattributen kann ein RA-Profil festlegen, was eine Zertifikatsanforderung benötigt, woher jeder Wert stammt und was ein Client niemals setzen darf. So füllt der Antragsteller ein kurzes Formular aus, statt PKI lernen zu müssen, und die Vertrauensgarantien bleiben genau dort, wo sie waren.
Niemand will ein Zertifikat. Man will das, was ohne Zertifikat nicht mehr funktioniert. Jede zusätzliche Frage ist eine Abgabe, die Sie für Ihre eigene Richtlinie erheben.
Denken Sie daran, womit ein Entwickler normalerweise konfrontiert ist, wenn er ein internes Zertifikat anfordert. Welche Vorlage? Welcher Schlüsselalgorithmus und welche Schlüssellänge? Welche Erweiterungen mit welchen Key Usages? Was gehört in den Subject-Namen und in welcher Reihenfolge? Welcher der verschiedenen Subject-Alternative-Name-Typen gilt hier?
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üheren Anforderung, durch Nachfragen bei einem Kollegen oder durch Raten. Dann wird die Anforderung abgelehnt und der Zyklus beginnt von vorn.
Unterdessen wird dem PKI-Team vorgeworfen, langsam zu sein. Tatsächlich soll es Entscheidungen kontrollieren, die nie vom Antragsteller hätten getroffen werden sollen.
Was Anforderungsattribute tatsächlich festlegen
Ein RA-Profil in ILM kann jetzt eine Konfiguration für Anforderungsattribute enthalten. Diese Konfiguration ist eine Richtlinienerklärung, keine Formulardefinition. Sie legt fest, welche Attribute eine Anforderung besitzt, und bindet jedes davon an eine Wertquelle.
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üher auf einer Wiki-Seite standen.
| Wertquelle | Wer entscheidet | Typisches Beispiel |
|---|---|---|
| Erfasst | Der Antragsteller | Der Hostname, für den das Zertifikat bestimmt ist |
| Abgeleitet | Die Plattform | Eigentümer und Gruppe, übernommen aus der authentifizierten Identität |
| Durch Richtlinie festgelegt | Das PKI-Team, einmalig | Schlüsselalgorithmus, Key Usage, Erweiterungssatz |
Lesen Sie die Tabelle als Arbeitsteilung. Der Antragsteller wird nur nach dem gefragt, was er tatsächlich weiß. Alles andere wird entweder abgeleitet oder wurde bereits entschieden.
Die Richtlinie reicht bis in die Anforderung selbst
Ein Formular, das die richtigen Werte erfasst, löst nur die Hälfte des Problems. Die Werte müssen anschließend korrekt in die Certificate Signing Request gelangen.
ILM überträgt 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ällig zusammengestellt hat. Subject und Erweiterungen werden aus derselben Deklaration erstellt, die der Antragsteller ausgefüllt hat.
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ßerdem kann eine Anforderung zunächst registriert und später ausgestellt werden, sodass Vorregistrierung und Ausstellung getrennte Schritte sein können, wenn ein Workflow dies erfordert.
Fehler, mit denen ein Protokoll-Client arbeiten kann
Hier liegt das Detail, das darüber entscheidet, ob sich all dies nahtlos anfühlt. Die meisten Zertifikatsanforderungen stammen gar nicht von einer Person. Sie kommen von ACME-, EST-, SCEP- oder CMP-Clients, die unbeaufsichtigt laufen.
Wenn ein solcher Client gegen eine Richtlinie verstößt, ist ein allgemeiner Fehler nutzlos. Der Client kann ihn nicht interpretieren, nicht sinnvoll erneut versuchen und nichts Handlungsrelevantes melden. Tage später liest jemand ein Protokoll.
ILM formt Verstöße 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ßerdem lässt sich der erwartete Satz von Anforderungsattributen über den CSR-Attributes-Endpunkt abfragen, sodass ein Client vor dem Erstellen einer Anforderung ermitteln kann, was erwartet wird.
Die Plattform zu fragen, was sie benötigt, ist ein besseres Protokoll, als zu raten und abgewiesen zu werden.
Erweiterungen ohne benutzerdefinierten Code
Zertifikatserweiterungen sind ein häufiger Grund dafür, dass Organisationen maßgeschneiderte Werkzeuge pflegen müssen. Eine Richtlinie braucht eine einzige benutzerdefinierte Erweiterung, und plötzlich enthält der Ausstellungsweg einen Patch.
ILM verfügt jetzt über ein Custom-OID-Register für Zertifikatserweiterungen, registriert die bekannten Systemerweiterungen und stellt einen Endpunkt bereit, der System-OIDs auflistet. Damit wird eine benutzerdefinierte Erweiterung zur Konfiguration. Zusätzlich werden Plattform-RDN-Codes wie EMAIL in Subject-Namen akzeptiert, wodurch eine bekannte Klasse abgelehnter Anforderungen entfällt.
Nahtlos bedeutet nicht nachlässig
All dies könnte leicht als Lockerung der Kontrolle verstanden werden. Das Gegenteil ist der Fall, und dieser Unterschied ist wichtig.
Zuvor konnte ein Antragsteller nahezu alles in eine CSR schreiben, und die Plattform musste es anschließend abfangen. Jetzt legt das Profil fest, was zulässig ist; Werte, die der Client nicht kontrollieren sollte, werden abgeleitet oder fest vorgegeben; und hochgeladene Anforderungen werden gegen dieselbe Richtlinie geprüft. Mit anderen Worten: weniger Fragen für den Antragsteller und weniger Möglichkeiten, etwas falsch zu machen.
Vertrauen in einer PKI entsteht dadurch, dass die Richtlinie konsistent angewendet wird. Es ist nie dadurch entstanden, dass Menschen beweisen müssen, dass sie sie verstehen. Wenn die Komplexität in das Profil verlagert wird, steigt daher die Sicherheit, statt zu sinken.
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.
Wichtigste Erkenntnisse
- Ein RA-Profil legt seine Anforderungsattribute fest und bindet jedes an eine Wertquelle: erfasst, abgeleitet oder durch Richtlinie festgelegt.
- Attributzuordnungen werden in die erzeugte PKCS#10-Anforderung übertragen, sodass die CSR die Richtlinie trägt und nicht die Vermutungen des Clients.
- Hochgeladene CSRs werden gegen dieselbe Richtlinie validiert, und Anforderungen können vorregistriert und später ausgestellt werden.
- Richtlinienverstöße liefern native ACME-, EST-, SCEP- und CMP-Fehler, und Clients können den erwarteten Attributsatz zunächst abfragen.
- Ein Custom-OID-Register und akzeptierte Plattform-RDN-Codes machen die Handhabung von Erweiterungen zu einer Konfigurationsaufgabe.
Anforderungsattribute wurden mit ILM Core 2.19.0 eingeführt. Was sich sonst in dieser Version geändert hat, erfahren Sie unter Änderungen in 2.19.0. Wenn kürzere Zertifikatslaufzeiten Sie zur Automatisierung drängen, lesen Sie den 47-Tage-Countdown und 10 Dinge, die Sie mit ILM aufbauen können. Wenn Sie ein Profil für Ihre eigene Umgebung entwerfen möchten, kontaktieren Sie uns.
