Enrollment-Methoden

Eine zentrale Eigenschaft von Enrollment-Protokollen für Zertifikate ist deshalb, wie sie den Antragsteller eines Zertifikats authentifizieren. Je nachdem, wofür das Zertifikat verwendet wird, ist das eine oder das andere Protokoll im Vorteil.

Eine weitere wichtige Eigenschaft ist die praktische Verbreitung. Die Enrollment-Methode oder das Protokoll muss für den vorgesehenen Anwendungsfall sowohl von der CA als auch auf der Clientseite unterstützt werden.

Die verbreitetsten Enrollment-Protokolle sind:

• SCEP
• ACME
• EST
• RPC/DCOM von Microsoft
• SOAP von Microsoft
• Manuelles Enrollment über die Webseite der CA
• Andere proprietäre Protokolle

SCEP

Geschichte und Spezifikation

Cisco hat das Simple Certificate Enrollment Protocol (SCEP) ursprünglich erfunden. Obwohl es damals keinen Standard gab, fand es in MDM-Systemen weite Verbreitung. Cisco ging sogar weiter und entwarf mit Enrollment over Secure Transport (EST) ein Nachfolgeprotokoll, das SCEP ablösen sollte. EST wurde deshalb in RFC 7030 sehr viel früher zu einem öffentlichen Standard als SCEP, das erst deutlich später in RFC 8894 standardisiert wurde, als es für das Zertifikats-Enrollment in MDM-Systemen längst der De-facto-Standard war.

Technik

SCEP setzt auf HTTP auf. Ein SCEP Request ist ein verschlüsseltes und signiertes PKCS#7, das per GET oder POST an den SCEP-Dienst geschickt wird. Der Dienst antwortet mit einer SCEP Response, wiederum einem verschlüsselten und signierten PKCS#7. Die Anfrage enthält eine Zertifikatsanforderung im Format PKCS#10, die Antwort enthält das ausgestellte X.509-Zertifikat.

Authentifizierung

Die PKCS#10-Anforderung enthält eine „SCEP Challenge“, die die Signieranfrage über ein Out-of-Band-Verfahren authentifiziert und autorisiert, abhängig vom jeweiligen SCEP-Dienst. In der Praxis sind heute drei Arten von SCEP Challenges im Einsatz:

Statische SCEP Challenge

Die einfachste Möglichkeit ist eine statische Passphrase. Stimmt die SCEP Challenge im PKCS#10 mit einem im SCEP-Dienst hinterlegten, vordefinierten Wert überein, wird das Zertifikat ausgestellt, andernfalls wird die Anfrage abgelehnt. Das Problem dieser Methode: Es lässt sich so gut wie nicht prüfen, ob die angeforderten Eigenschaften des Zertifikats zum Antragsteller passen. Für dieses Problem gibt es sogar eine CVE.

Diese Methoden lassen sich weiter unterscheiden:

1. Bei einem direkten SCEP-Enrollment kommuniziert die Instanz, für die das Zertifikat ausgestellt werden soll, unmittelbar mit dem SCEP-Dienst. Beispiel: Ein MDM-System weist ein Android-Telefon an, ein SCEP-Enrollment mit der SCEP Challenge „SecurePassword“ durchzuführen. Das Android-Telefon erzeugt einen CSR, hoffentlich mit den richtigen Werten, und trägt „SecurePassword“ als SCEP Challenge ein. Anschließend schickt es den CSR an den SCEP-Dienst und erhält im Gegenzug das ausgestellte Zertifikat.
2. Ein transparenter SCEP-Proxy verhält sich wie ein HTTP-Reverse-Proxy. Weil SCEP verschlüsselt und signiert ist, kann er weder in die SCEP-Anfragen und -Antworten hineinsehen noch sie verändern. Er kann aber anhand von Netzwerkgrenzen steuern, wer wann Zertifikate beziehen darf.
3. Ein SCEP-Proxy als Protokolladapter ist ein System, das stellvertretend für ein anderes System Zertifikate über SCEP anfordert. So könnte etwa ein MDM-System wie JAMF im Namen eines iPhones ein Zertifikat bei einem SCEP-Dienst anfordern. Sobald es Zertifikat und privaten Schlüssel hat, kann es das Zertifikat über ein anderes Protokoll ausrollen. Auf diese Weise hat nur das MDM-System Zugriff auf die SCEP Challenge und kann zusätzlich den Inhalt des Zertifikats steuern.

Dynamische SCEP Challenge

In diesem Fall ist jede SCEP Challenge nur für eine einzige Zertifikatsanforderung gültig. Dadurch kann der SCEP-Dienst die SCEP-Anfrage zuordnen und prüfen, ob die angeforderten Eigenschaften des Zertifikats zu den für diese Anfrage zulässigen passen.

In der Praxis gibt es grundsätzlich zwei Wege, wie sich ein MDM-System und eine SCEP-CA auf eine SCEP Challenge für eine Anfrage verständigen:

1. Das MDM-System fordert beim SCEP-Dienst einen Einmalcode für einen SCEP Request an, wenn es einen benötigt.
   1. Ein Beispiel ist Microsoft NDES. NDES hat eine eigene Admin-Seite, die per AD-Anmeldedaten authentifiziert wird. Bei jedem Aufruf der Admin-Seite erzeugt und zeigt NDES einen neuen Einmalcode, der für genau eine SCEP-Anfrage verwendet werden kann. In dieser Konfiguration prüft NDES allerdings keinerlei Eigenschaften des Zertifikats, da der Einmalcode generisch ist.
2. Das MDM-System erzeugt einen Einmalcode, wenn es ein verwaltetes System anweist, ein Zertifikat über SCEP anzufordern. Trifft der SCEP Request beim SCEP-Dienst ein, muss der Dienst den Einmalcode beim MDM-System abrufen, üblicherweise über einen Webhook, und prüfen, ob er zur SCEP Challenge in der Anfrage passt. Für dieses Protokoll gibt es keinen Standard, MDM-System und SCEP-Dienst müssen sich also auf ein Format einigen, und ob Eigenschaften der Anfrage geprüft werden, hängt von der Implementierung ab.

Signierte Metadaten

Für die SCEP Challenge gibt es praktisch keine Längenbeschränkung. Sie muss also keine für Menschen lesbare „Passphrase“ sein, sondern kann auch ein BLOB sein.

Intune verwendet als SCEP Challenge ein signiertes und verschlüsseltes XML. Es erzeugt dieses XML serverseitig und schickt es an ein Clientgerät, wenn es ein Zertifikat beziehen will und den SCEP Request erstellt.

Der SCEP-Dienst muss die vollständige PKCS#10-Anforderung an einen Intune SCEP Challenge Service senden. Der SCEP Challenge Service besitzt den privaten Schlüssel, um das XML zu entschlüsseln, und den öffentlichen Schlüssel, um zu prüfen, dass es von einem echten Intune-Dienst erzeugt wurde.

Das XML enthält Metadaten zur Anfrage, etwa wie der Subject aussehen soll. Diese leiten sich zum einen aus dem SCEP-Konfigurationsprofil ab und zum anderen aus den konkreten Objektdaten des Benutzers oder Geräts, für den oder das das Zertifikat ausgestellt werden soll.

Beispiel: Im SCEP-Konfigurationsprofil kann CN={{DeviceId}} als Subject konfiguriert sein. Fordert das Gerät mit der ID xyz ein Zertifikat an, steht im XML, dass der Subject CN=xyz lauten soll. Der SCEP Challenge Service vergleicht dann die Angaben aus dem XML mit dem Subject in der PKCS#10-Anforderung. Unterscheiden sich die Subjects, schlägt die Prüfung fehl. Stimmen sie und die übrigen Eigenschaften überein, ist die Prüfung erfolgreich.

Der SCEP-Dienst stellt das Zertifikat nur aus, wenn die Prüfung erfolgreich ist.

Microsoft erklärt diese Prüfung in einem Artikel.

Microsoft NDES unterstützt das über ein zusätzliches NDES Policy Module, andere SCEP-CAs unterstützen es nativ oder eben nicht.

Microsoft RPC/DCOM

Geschichte

Die Microsoft Active Directory Certificate Services (ADCS), manchmal auch nur „Microsoft CA“ genannt, sind die in Windows Server eingebaute Software für eine Zertifizierungsstelle. Die Software entstand ursprünglich am Ende des letzten Jahrtausends und wurde in den folgenden zehn bis fünfzehn Jahren noch um einiges ergänzt.

Eine Alternative ist SOAP von Microsoft oder SCEP, die Microsoft Web Enrollment beziehungsweise NDES nennt.

Spezifikation und Verbreitung

Uns ist kein anderes CA-System bekannt, das dieses Protokoll implementiert, auch wenn Microsoft inzwischen die Spezifikation in Microsoft OpenSpec veröffentlicht hat. Auf der Clientseite unterstützt Windows das Protokoll von Haus aus, andere Plattformen werden nicht unterstützt.

Technik

Die wichtigste Enrollment-Methode ist ein proprietäres Protokoll auf Basis von RPC oder DCOM.

Auch das Autoenrollment nutzt dieses Protokoll. Damit Autoenrollment funktioniert, brauchst du

• ein in die Domäne eingebundenes Gerät.
• Eine Gruppenrichtlinie, die Autoenrollment aktiviert,
• eine Enterprise CA (im Unterschied zu einer Stand-alone-CA),
• die ein Certificate Template ausstellt, für das
• der Benutzer oder das Gerät die Berechtigungen für Enrollment und Autoenrollment besitzt.

Standardmäßig wird alle 8 Stunden auf Autoenrollments geprüft, erzwingen lässt sich das aber mit certutil -pulse oder oft besser mit gpupdate -force.

Authentifizierung

Dieses Protokoll nutzt die in Active Directory eingebauten Authentifizierungsprotokolle, Benutzer und Computer authentifizieren sich also mit ihren AD-Anmeldedaten.