SCEP einfach erklärt: Zertifikate automatisch für Geräte

Ein Unternehmen mit 3.000 Notebooks, 500 Druckern und 200 Routern kann nicht jedes Zertifikat von Hand beantragen. Für dieses Problem entstand um das Jahr 2000 bei Cisco und VeriSign das Simple Certificate Enrollment Protocol, kurz SCEP. Es lässt Geräte ihr Zertifikat selbst bei einer Zertifizierungsstelle anfordern, ohne dass jemand eine Datei kopiert. Erst im September 2020 wurde SCEP als RFC 8894 offiziell beschrieben, obwohl es da längst in Millionen Geräten steckte. Dieser Artikel erklärt den Ablauf, das berüchtigte Challenge-Passwort, die Schwächen des Protokolls und wo es heute noch eingesetzt wird.

Wozu SCEP gebraucht wird

Ein Zertifikat bekommt man normalerweise so: Schlüsselpaar erzeugen, Zertifikatsantrag (CSR) erstellen, Antrag bei der CA einreichen, Zertifikat zurückbekommen und installieren. Wie das von Hand funktioniert, zeigt Schlüsselpaar und CSR erstellen. Für einen Webserver ist das zumutbar, für tausende Geräte nicht. SCEP automatisiert genau diese Schritte:

Das Gerät erzeugt sein Schlüsselpaar selbst; der private Schlüssel verlässt es nie.
Es holt sich das CA-Zertifikat und prüft es.
Es schickt den CSR an den SCEP-Server und erhält das fertige Zertifikat zurück.
Kurz vor Ablauf erneuert es das Zertifikat auf demselben Weg.

Typische Einsatzzwecke sind WLAN- und VPN-Zugang mit Zertifikat, Router und Firewalls, die sich untereinander ausweisen, und verwaltete Smartphones. Die Zertifikate stammen fast immer von einer firmeneigenen CA; siehe Eigene CA betreiben.

So läuft eine SCEP-Anforderung ab

SCEP nutzt einfaches HTTP. Jede Aktion ist ein Aufruf mit dem Parameter operation:

GetCACaps: Der Client fragt, was der Server kann, etwa SHA-256, AES oder POST-Anfragen.
GetCACert: Der Client lädt das Zertifikat der CA (und gegebenenfalls einer Registrierungsstelle, RA).
PKIOperation: Der eigentliche Antrag. Der Client packt seinen CSR im Format PKCS#10 in eine CMS-Nachricht, verschlüsselt sie für die CA und signiert sie. Die Antwort (CertRep) lautet SUCCESS mit Zertifikat, FAILURE oder PENDING.
Bei PENDING wartet ein Mensch oder ein Prüfprozess auf die Freigabe; der Client fragt dann regelmäßig nach (Polling).

Weil HTTP selbst nichts verschlüsselt, schützt SCEP die Nachrichten selbst: Der CSR ist für das CA-Zertifikat verschlüsselt, die Antwort für den Client. Wichtig ist der erste Schritt. Das CA-Zertifikat kommt ungeschützt über HTTP, deshalb muss das Gerät dessen Fingerabdruck mit einem bekannten Wert vergleichen, den der Administrator hinterlegt. Sonst könnte ein Angreifer im Netz ein eigenes CA-Zertifikat unterschieben.

Ein Blick auf die Fähigkeiten eines Microsoft-SCEP-Servers (NDES) sieht so aus; die Antwort ist ein Beispiel:

curl "http://ndes.beispiel.local/certsrv/mscep/mscep.dll/pkiclient.exe?operation=GetCACaps"
POSTPKIOperation
Renewal
SHA-256
AES
SCEPStandard

SCEPStandard bedeutet, dass der Server die Mindestanforderungen von RFC 8894 erfüllt: AES, SHA-256 und POST.

Fünf Schritte von links nach rechts: Fähigkeiten abfragen, CA-Zertifikat laden, Fingerabdruck prüfen, verschlüsselten Antrag senden, Antwort SUCCESS, PENDING oder FAILURE empfangen. — Die fünf Schritte einer SCEP-Anforderung nach RFC 8894.

Das Challenge-Passwort und seine Schwächen

Woher weiß der SCEP-Server, dass ein Antrag berechtigt ist? Die klassische Antwort ist das Challenge-Passwort: ein Attribut im CSR, das der Server prüft. Genau hier liegt die größte Schwäche des Protokolls.

Statische Passwörter: In vielen Netzen steht ein einziges Passwort in allen Gerätekonfigurationen. Wer es aus einem ausgemusterten Router ausliest, kann beliebig viele Zertifikate beantragen.
Freie Namenswahl: Prüft der Server die Namen im CSR nicht, beantragt ein Angreifer ein Zertifikat für einen fremden Namen, etwa den eines Servers oder Administrators.
Kein Gerätenachweis: SCEP beweist nicht, auf welchem Gerät der Schlüssel erzeugt wurde. Ein Zertifikat für das Firmen-Notebook kann auch auf einem privaten Rechner landen.
Alte Algorithmen: Ältere Implementierungen nutzen noch DES, 3DES, MD5 oder SHA-1. RFC 8894 empfiehlt AES und SHA-256.

Besser sind Einmal-Passwörter. Microsofts SCEP-Dienst NDES (Network Device Enrollment Service) erzeugt sie auf einer Admin-Seite, und sie verfallen nach kurzer Zeit. MDM-Systeme wie Microsoft Intune gehen weiter: Sie erzeugen für jedes Gerät eine eigene, signierte Challenge, die ein Prüfmodul am NDES-Server kontrolliert. Damit bekommt nur ein Gerät, das Intune kennt, genau das vorgesehene Zertifikat.

Zwei Spalten: links die Nachteile eines statischen Challenge-Passworts, rechts die Vorteile einer Einmal-Challenge pro Gerät, die das MDM signiert und ein Prüfmodul kontrolliert. — Die größte Schwäche von SCEP und wie Einmal-Challenges sie entschärfen.

Wo SCEP heute eingesetzt wird

Trotz seines Alters ist SCEP weit verbreitet, weil fast alles es spricht:

Mobilgeräte-Verwaltung (MDM): Intune, Jamf und andere verteilen SCEP-Profile an Windows, iPhone, Mac und Android.
Netzwerkgeräte: Router, Switches und Firewalls vieler Hersteller beantragen damit ihre Zertifikate.
Microsoft-Umgebungen: NDES verbindet SCEP mit den Active Directory Certificate Services; zu Active Directory siehe Active Directory und LDAP.
Freie CA-Software: step-ca, EJBCA und Dogtag bieten einen SCEP-Endpunkt.

Für neue Projekte gibt es modernere Protokolle: EST nutzt TLS verschlüsselte Verbindung. Erkennbar am Schloss-Symbol im Browser.">HTTPS statt eigener Verschlüsselung, CMP ist für Industrie und Mobilfunk gedacht, und ACME prüft wie bei Let’s Encrypt automatisch, ob der Antragsteller die Domain kontrolliert; siehe ACME und Let’s Encrypt. Apple empfiehlt für seine Geräte inzwischen ACME mit Gerätenachweis statt SCEP.

Tabelle mit vier Protokollen: SCEP über HTTP mit Challenge-Passwort, EST über HTTPS mit Zertifikat oder Passwort, CMP über HTTP, CoAP oder Datei mit MAC oder Signatur, ACME über HTTPS mit Domainprüfung. — SCEP, EST, CMP und ACME auf einen Blick.

Häufige Fragen

Ist SCEP unsicher? Nicht grundsätzlich. Mit Einmal-Passwörtern, geprüften Namen, AES und SHA-256 und einer kontrollierten CA ist es vertretbar. Gefährlich sind statische Passwörter und Server, die jeden Namen ausstellen.

Brauche ich für SCEP einen Windows-Server? Nein. NDES ist nur eine Umsetzung. Auch freie CAs wie step-ca oder EJBCA und viele Cloud-PKI-Dienste bieten SCEP an.

Warum nutzt SCEP kein HTTPS? Das Protokoll stammt aus einer Zeit, in der Geräte oft noch kein TLS konnten. Es verschlüsselt deshalb jede Nachricht selbst. Ein Betrieb hinter HTTPS ist möglich, aber nicht vorgeschrieben.

Kann ein SCEP-Zertifikat gesperrt werden? Ja, wie jedes andere über die CA. Siehe Zertifikatssperrung.

Fazit

SCEP lässt Geräte ihr Zertifikat selbst anfordern: CA-Zertifikat holen, Fingerabdruck prüfen, verschlüsselten Antrag senden, Zertifikat empfangen. Seine Schwachstelle ist das Challenge-Passwort. Mit Einmal-Passwörtern, Namensprüfung und einem MDM, das jede Challenge an ein bekanntes Gerät bindet, bleibt SCEP brauchbar; neue Projekte prüfen EST, CMP oder ACME. Mehr in der Übersicht Verschlüsselung und IT-Sicherheit.