Zertifikat Enrollment Services im Überblick

Die Verteilung von Zertifikaten über die Microsoft Certificate Services kann auf verschiedene Varianten erfolgen. Für die allermeisten Clients wird dies heutzutage via AutoEnrollment und die RPC erfolgen. Insbesondere die RPC-Kommunikation ist oft unerwünscht und in segmentierten Netzen unschön. Eine Kommunikation über «besser» definierte Protokolle wäre sicherlich mehr en vogue. Vielleicht https?

Vorab müssen wir hier die interaktive Certificate Enrollment Website von dem CES Webservice unterscheiden. Erstere sollte nicht mehr verwendet werden. Zweitere gibt uns die Möglichkeit, die Zertifizierungsstellenserver besser zu schützen und diese auch für Windows Clients, die nicht Mitglied der ActiveDirectory Domain sind, nutzbar zu machen.

Im Rahmen von Segmentierung des Netzwerks und den Privilege Access Workstations bekommt man irgendwann immer die Frage, in welche Zone die Server kommen, auf denen die Certificate Services laufen – die CAs.

Für die RootCA ist das einfach – keine Netztwerk-Kommunkation / immer off! Die CA wird nur eingeschalten, wenn man die CRL erneuern oder ein neues subCA Zertifikat signieren muss. Die Daten werden per shared disk kopiert oder man bemüht ganz old style das Turnschuh-Netz. Diskette rein und los …

Es ist auch eine sehr gute Idee, wenn dies mit dem 4-Augen-Prinzip erfolgt.

Für alle anderen Server wird das etwas komplizierter.

Fangen wir mal mit den einfachen Dingen an. Wenn wir uns noch mal die Grundstruktur aus dem Artikel https://www.tec-bite.ch/public-key-infrastructure-pki-wies-funktioniert-und-leitfragen-fuer-die-implementierung/ ins Gedächtnis rufen, dann gibt es da Webserver für den Abruf der CA-Zertifikate (AIA) und der CRL (CDP), eventuell auch OCSP. Diese Server müssen für Clients und eventuell für bestimmte Gateways erreichbar sein und auch geschützt werden. Dieser Webservice läuft deshalb auf separaten Servern und nicht auf der CA – Segregation of Duties. Sie erinnern sich an unsere Golden Rules.

In internen Zertifikaten ist eventuell auch eine Alternative für AIA, CDP via ldap erreichbar zu machen und damit auf den Domain Controllern – DCs. Aber um die DCs kümmern wir uns hier mal nicht.

Die subordinated oder ausstellenden CAs stellen wir auch, wie die DCs, auf die höchste Schutzebene – Tier 0. Vor allem der private Key des CA Zertifikats sollte jeglichen Schutz erhalten im Optimalfall mit einem HSM.

Die CAs müssen mit den DCs sprechen können, weil sie vor allem auch Updates auf die DCs schreiben, aber diese können auch in separaten FW-Zonen / Netzwerksegementen sein.

Wann müssen nun unsere Clients (User oder Computer) auf die CAs zugreifen?

Im Normalfall, wenn sie ein neues Zertifikat erstellen wollen. Ob nun via Command Line mit certreq, Powershell oder via Certificate Manager (certmgr.msc und certlm.msc), der Client wird per RPC mit dem Server kommunizieren, auf dem die Certificate Services laufen, um seinen Request abzusetzen oder das signierte Zertifikat abzurufen.

Um diese direkte Kommunikation zu verhindern, hat man die Registration Authority erfunden. Diese nimmt Anfragen entgegen und leitet diese an die CA weiter.

Im Falle eines externen public TrustCenter ist der Prozess im Groben so:

• Würfeln – Wir erstellen ein Key Pair aus private und public Key (RSA oder ECC).

• Antrag – Wir nehmen unseren Public Key und fügen beschreibende Information für unseren Zweck hinzu.

• Päckli – Diesen Antrag (Public Key und beschreibende Informationen) senden wir als die Zertifikatsanforderung an das Web-Portal, per E-Mail – mit Geschenkverpackung (Money)!

• Überprüfung – Wenn wir dem «Mitarbeiter» des TrustCenter ausreichend nachweisen konnten, dass wir schon gezahlt haben, die richtige Person oder Institution sind, wird der Antrag bearbeitet.

• Unterschrift – Mit der digitalen Signatur der CA wird nun die Richtigkeit der beschreibenden Informationen und die Zugehörigkeit des Public Keys bestätigt.

• Ausweis – das Zertifikat wurde von einer vertrauenswürdigen Instanz ausgestellt und damit sind wir, unser Rechner oder unser Service gegenüber anderen vertrauenswürdig.

Nun ist dieses Prozedere (und jeder darf diesen Prozess gern noch etwas gestalten) etwas aufwendig und eine Automatisierung wäre da sehr willkommen.

Variante I – Permission

Für die internen Clients und User hat Microsoft das Autoenrollment erfunden. Hier weisen wir uns mit dem Kerberos-Ticket gegenüber dem Server aus und erhalten deshalb ein signiertes Zertifikat. Das Gleiche würde auch bei der manuellen Zertifikatsanforderung passierend, das ist nur eine andere Berechtigung in der Zugriffsliste der Zertifikatsvorlage (ACL of Certificate Template).

Variante II – Enrollment Agent

Dies kann nun auch durch ein Certificate Request Agent Certificate delegiert werden. Der Enrollment Agent, Benutzer oder Computer, bekommt ein solches Certificate Request Agent Certificate. Die Zertifikatsanforderung wird digital signiert und kann nun so von der CA verifiziert werden. Dies verwendet man oft beim Ausstellen von Smart Cards und berechtigt so beispielsweise die Benutzer, die Smart Cards ausstellen, ein Smart Card Management System (CMS) oder einen NDES Server (Network Device Enrollment Service), der ja auch in Stellvertretung für andere Zertifikate anfordert. Beispiel: MobileIron → NDES → CA. Hier ist das CMS, der NDES Server oder auch der spezielle Arbeitsplatz die Registration Authority.

Variante III – CA Approval

Das ist eigentlich das Verfahren, was wir bei dem aufwendigen manuellen Prozedere oben vorgestellt haben. Hier wird die Zertifikatsanforderung von den berechtigten Personen (Certificate Manager) ausgestellt.

Wie machen wir das nun für Rechner, die nicht mit der CA direkt (rpc / dcom) kommunizieren können oder nicht Mitglied der ActiveDirectory Domain sind?

Ganz klar via Web!

Wie schon in unserer Grundstruktur zu erkennen, stellen wir einen Webservice bereit, der genau diese Aufgabe übernimmt. Die benötigten AD CS Komponenten CES/CEP kommen auf einen Webserver auf Tier 1 und die Clients kommunizieren via https mit diesem Server. Man kann sich vor allem für die Nutzung des Service via Internet überlegen, einen Reverse Proxy zum Schutz des Webservers davor zu stellen. Das Ergebnis der Überlegung sollte aber zwingend JA sein.

Um unsere Clients entsprechend zu konfigurieren, gibt es verschiedene Wege. Es sind die üblichen Verdächtigen GPO, Registry und oder Powershell und Ähnliches.

Via Registry HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\PolicyServers,

Oder via Powershell mit Set-CertificateAutoEnrollmentPolicy konfiguriert.

Wahrscheinlich macht man das nur im Labor um zu testen, aber es ginge auch manuell in der MMC (Microsoft Management Console).

Wenn man sich nun im Nachhinein die Standardkonfiguration des Windows Clients anschaut, wird man dieses Vorgehen wiederfinden. Der Client connected nur per AD Certificate Enrollment Policy auf den Default CES, den man unter ldap:///Enrollment Services,cn=Public Key Services,cn=Services,cn=Configuration, DC=yourdomain,dc=tld findet.

Im Setup mit dem Certificate Enrollment Web Service wird der CEP als Connection Point verwendet und dieser verweist dann wieder auf die CES Instanzen.

Folgende Möglichkeiten bestehen für die Authentication:

• Windows integrated Authentication – Kerberos
• UserID und Password

Und in Kombination mit Key based Renewal:

• Certificate based Authentication

Am besten ist hier die Konfiguration via Powershell zu erledigen und damit dann auch gleich dokumentiert.

Install-AdcsEnrollmentPolicyWebService

Install-AdcsEnrollmentWebService

Wie man anhand der Client Parameter entdeckt, muss man sich für eine Authentication entscheiden, was wir vorab auf der Serverseite definiert haben.

Auf der Serverseite wird dies dann mit Kerberos Constrained Delegation an einen SPN Account übergeben und damit die Berechtigung gegenüber der CA geprüft.

Man kann auch das ACME (Automatic Certificate Management Environment) auf Windows aktivieren, was durchaus eine interessante Alternative sein kann. Aber das vertiefen wir vielleicht mal später. Dennoch kurz einen Hinweis zum Einstieg in diese Richtung:

Dazu muss man sich eine Server Komponente wählen. Zum Beispiel auf Github: github.com/topics/acme-server

Und auch der Client braucht ein Addon. Über die bevorzugte Suchmaschine wird man schnell fündig.

Mit dem zusätzlichen Aufwand lassen sich die CAs deutlich besser schützen und sogar die Verwendung auf externe Clients erweitern. Ein hilfreicher Guide für mich ist zum Beispiel hier zu finden:

• social.technet.microsoft.com/wiki/contents/articles/7734.certificate-enrollment-web-services-in-active-directory-certificate-services.aspx#Error_Messages
• www.petenetlive.com/kb/article/0001250

Die Feature in einem Produkt zu verwendet ist aus Sicht der Langfristigkeit und dem gegebenen Support des Herstellers der sicherere Weg, eine Erweiterung der Internet-Community öffnet dafür ganz andere Wege. Eventuell muss man bei Erweiterungen von Github auch mal selbst Hand anlegen und der Support ist vielleicht mühsamer.

Wie immer ist es hilfreich Know How aufzubauen, Erfahrungen zu sammeln und ein glückliches Händchen – Magic Fingers – für die Implementierung zu haben. Wenn man das nun in einem gemeinsamen Projekt einbringen kann, macht es noch viel mehr Spass.