Grundlagen Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES)

Das Simple Certificate Enrollment Protocol (SCEP) wurde in den frühen 2000er Jahren von Verisign für Cisco entwickelt, um eine vereinfachte Methode zum Beantragen von Zertifikaten verwenden zu können. Zuvor musste für Netzwerkgeräte manuell eine Zertifikatanforderung auf jedem Gerät erzeugt, zu einer Zertifizierungsstelle übermittelt und anschließend das ausgestellte Zertifikat wieder manuell auf dem entsprechenden Gerät installiert werden.

Ursprünglich war SCEP dafür gedacht, Netzwerkgeräte, wie etwa Switche und Router mit Zertifikaten auszurüsten. Heutzutage unterstützen jedoch deutlich mehr Gerätetypen die Zertifikatbeantragung via SCEP.

Hierzu können beispielsweise gehören:

Die Microsoft Actve Directory Zertifikatdienste unterstützen das SCEP Protokoll durch den Registrierungsdient für Netzwerkgeräte (Network Device Enrollment Service, NDES) seit Windows Server 2003.

Funktionsweise

Das Grundlegende Problem im Vergleich zu einem Active Directory Domänen-Mitglied, welchem die Zertifikatbeantragung via RPC/DCOM zur Verügung steht, ist, dass die betreffenden Geräte nicht über eine zentral verwaltete Identität verfügen, die man für deren automatisierte Identifikation verwenden könnte, wie es etwa bei Kerberos in Active Directory der Fall ist. Außerdem müssten alle Geräte eine standardisierte Schnittstelle sprechen, über die Zertifikate von beliebigen Zertifizierungsstellen-Produkten beantragt werden können.

Der SCEP-Server agiert in diesem Fall als Vermittler zwischen dem Endgerät, das ein Zertifikat benötigt, und der Zertifizierungsstelle.

Zunächst meldet sich ein Administrator (im Sinne von: jemand, der ein Endgerät verwaltet, welches ein Zertifikat bekommen soll) mit seiner Kennung am SCEP-Server an. Im Falle des NDES ist dies eine Active Directory-Kennung. Diese ist für die Beantragung von Zertifikaten auf einer Zertifikatvorlage berechtigt, welche wiederum auf dem NDES-Server zur Verwendung konfiguriert ist.

Das ursprüngliche Konzept sah an dieser Stelle vor, dass es sich bei dem genannten Administrator um eine natürliche Person handelt, welche diesen Schritt manuell durchführt. In der Praxis wird dieser Schritt aber üblicherweise an eine Managementsoftware delegiert (beispielsweise Mobile Device Management wie VMware AirWatch oder Microsoft InTune).

Stellt der NDES-Server nun also fest, dass der Administrator für die Beantragung von Zertifikaten berechtigt ist, händigt er ihm ein Einmalkennwort (engl. One Time Password, OTP) aus.

Beispiel: ein von NDES generiertes Einmalkennwort

Dieses Einmalkennwort wird nun zusammen mit der Adresse des NDES-Servers auf dem Endgerät hinterlegt. Das Gerät ist nun in der Lage, ein Schlüsselpaar sowie eine Zertifikatanforderung zu erzeugen und an den NDES-Server zu senden. Es authentifiziert sich mit dem zuvor konfigurierten Einmalkennwort.

Anstelle eines Einmalkennwortes kann das Gerät sich auch mit einem bestehenden Zertifikat ausweisen, wenn es die gleiche Identität enthält und von der gleichen Zertifizierungsstelle ausgestellt wurde (sog. Renewal Modus). Ebenso wäre es möglich, ein statisches, also nicht wechselndes Kennwort zu konfigurieren, oder das Verlangen eines Kennwortes komplett zu deaktivieren, was aus Sicherheitsgründen aber nicht erfolgen sollte.

Bevor die Zertifikatanforderung erzeugt wird, wird eine Anfrage an den NDES-Server gesendet (GetCACaps Operation), um die unterstützen Funktionen des Servers zu ermitteln.

Beispiel: Die von NDES unterstützten Funktionen als Antwort auf die GetCACaps Anfrage

Ebenso wird das Zertifizierungsstellen-Zertifikat (GetCACert Operation) angefragt. Im Falle des NDES wird jedoch nicht nur das Zertifizierungsstellen-Zertifikat zurückgesendet, sondern auch das Registration Authority (RA) Zertifikat, welches die Zertifizierungsstelle dem NDES-Server ausgestellt hat, und ihn somit zu ihrem Stellvertreter ernannt hat (genauer gesagt das "CEP Encryption" Zertifikat).

Beispiel: Eine von NDES auf die GetCACerts Anfrage zurückgegebene Zertifikatkette

Nachdem das Endgerät die Zertifizierungsstelle anhand des Registration Authority Zertifikats authentisiert hat, wird die im Format PKCS#10 erzeugte Zertifikatanforderung in einer Cryptographic Message Syntax (CMS, einer Weiterentwicklung des PKCS#7 Standards) SignedData Datenstruktur verpackt und je nach Fall mit einem selbstsignierten (im Falle einer Erstbeantragung) oder einem bereits von der gleichen Zertifizierungsstelle ausgestellten vorhandenen (im Falle einer Erneuerung) Zertifikat signiert und anschließend an die Zertifizierungsstelle gesendet.

Die vertraulichen Informationen wie das in der Zertifikatanforderung als "ChallengePassword" Attribut enthaltene Einmalkennwort wird mit dem öffentlichen Schlüssel des zuvor angefragten RA-Zertifikats verschlüsselt.

Aus diesem Grund ist es auch meistens nicht möglich, eine manuell generierte Zertifikatanforderung via SCEP durch einen Dritten einzureichen, da diesem in der Regel der private Schlüssel zum Signieren der CMS Nachricht (muss zum öffentlichen Schlüssel der Zertifikatanforderung passen) nicht vorliegt.

Der NDES-Server gibt, sofern die Authentisierung mit Einmalkennwort oder Zertifikat erfolgreich war, die Zertifikatanforderung nun per RPC/DCOM an die Zertifizierungsstelle weiter, wo das Zertifikat ausgestellt (oder die Zertifikatanforderung abgelehnt) wird. Die Zertifikatanforderung wird durch den NDES-Server mittels seines RA-Zertifikats ("Enrollment Agent") signiert, sodass die Zertifizierungsstelle das Vorhandensein einer gültigen Signatur überprüfen kann (in der Standardeinstellung findet diese Überprüfung allerdings leider nicht statt, sie muss gesondert aktiviert werden). Dies verhindert Zertifikatanforderungen am NDES Dienst vorbei direkt gegen die Zertifizierungsstelle.

Hierbei handelt es sich nicht um einen Enroll on Behalf of (EOBO) Prozess. Entsprechend haben die Einstellungen für eingeschränkte Zertifikatregistrierungs-Agenten auf der Zertifizierungsstelle keine Auswirkungen auf den Prozess.

Wurde das Zertifikat ausgestellt, wird es an den NDES Server übergeben, welcher das Zertifikat wiederum an das antragstellende Endgerät ausliefert.

Übersicht: Abfolge der SCEP Kommunikation

Varianten

NDES kann für die folgenden Betriebsmodi konfiguriert werden:

Sicherheitsbedenken

Beim Einsatz eines Registrierungsdienstes für Netzwerkgeräte ist in Hinsicht auf die Sicherheit folgende zu beachten:

Fazit

Mit SCEP und der Microsoft-Implementierung NDES ist eine automatische Verteilung von Zertifikaten an Geräte möglich, welche über keine Active Directory Kennung verfügen. Dies können sowohl Netzwerkgeräte wie Switche oder Router sein, als auch mobile Geräte wie Smartphones und Tablets. Es ist aber beispielsweise auch möglich, Server in der Cloud automatisch mit Zertifikaten auszurüsten, nachdem diese installiert wurden.

Weiterführende Links:

Externe Quellen

15 Gedanken zu „Grundlagen Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES)“

Kommentare sind geschlossen.