Zertifikatbasierte Netzauthentifizierung

Wir empfehlen, unseren RADIUS-as-a-Service als Network Access Controller (NAC) zu verwenden, um zertifikatsbasierte WiFi-, LAN- oder VPN-Authentifizierung zu realisieren, da er eine One-Click-Konfiguration ermöglicht. SCEPman-Zertifikate funktionieren jedoch generell mit allen NACs, die standardmäßige 802.1x-zertifikatsbasierte Authentifizierung unterstützen.

Dieser Artikel beschreibt bemerkenswerte Eigenschaften einiger der gebräuchlichsten NACs.

RADIUS-as-a-Service

Bitte beachten Sie die RADIUS-as-a-Service-Dokumentation um zu sehen, wie man SCEPman-Zertifikate in RADIUS-as-a-Service verwendet.

Cisco ISE

Dies ist nicht mehr erforderlich für Cisco

• ISE Release 3.2 Patch 8 oder später,

• ISE Release 3.3 Patch 5 oder später,

• ISE Release 3.4 Patch 2 oder später

Cisco ISE unterstützt häufig kein HTTP 1.1, sondern nur HTTP 1.0 für OCSP-Anfragen. Dies erfordert einen zusätzlichen Application Proxy vor SCEPman. Siehe unser Fehlerbehebungsartikel für ISE für Details.

Mindestens einige Versionen von Cisco ISE 3.x verlangen eine Extended Key Usage-Erweiterung mit dem OCSP Responder Extended Key Usage, um OCSP-Antworten zu akzeptieren, selbst wenn diese von einer CA stammen, bei der dies laut RFC nicht erforderlich ist. SCEPman-Versionen bis 1.7 fügten standardmäßig keine Extended Key Usage zu ihrem CA-Zertifikat hinzu. Version 1.8 ermöglicht es, diese Erweiterung über eine Konfigurationseinstellung. In SCEPman 1.9 fügt der Standardwert der Konfigurationseinstellung bereits die Extended Key Usage hinzu. Wenn Sie bereits ein CA-Zertifikat ohne Extended Key Usage-Erweiterung haben und Probleme mit Cisco ISE 3.x auftreten, müssen Sie möglicherweise ein neues SCEPman Root CA-Zertifikat mit der Extended Key Usage-Erweiterung erstellen.

Aruba ClearPass

Microsoft Intune ClearPass-Erweiterung

Falls Sie Arubas Microsoft Intune ClearPass-Erweiterung innerhalb des ClearPass Policy Manager verwenden, müssen Sie die Geräte-IDs dem SCEP-Zertifikatvorlage in einem bestimmten Format hinzufügen. Zur Sicherstellung der Kompatibilität mit SCEPman sind unten stehende SAN-Attribute in der folgenden Reihenfolge:

• (URI) Wert: DeviceId:{{DeviceId}}

• (URI) Wert: AAD_Device_ID:{{AAD_Device_ID}}

• (URI) Wert: IntuneDeviceId://{{DeviceId}}

Die ersten beiden Einträge werden von ClearPass verwendet, während der dritte Eintrag von SCEPman verwendet wird.

OCSP HTTP 1.0 Problem

Dies ist nicht mehr erforderlich für ClearPass 6.9.6 oder später.

Analog zu Cisco ISE verwendet Aruba ClearPass HTTP 1.0 für OCSP-Anfragen und erfordert daher zusätzliche Konfigurationsschritte zum Hinzufügen eines Application Proxy um mit SCEPman zu funktionieren.

Microsoft Network Policy Server (NPS)

NPS ordnet Zertifikate Geräte- oder Benutzerentitäten in AD (nicht AAD) zu. Da es keine Out-of-the-Box-Gerätesynchronisation zwischen AAD und AD gibt, ist es in der Regel nicht möglich, NPS mit über Intune verteilten Gerätezertifikaten mit SCEPman oder einer anderen PKI zu verwenden. Benutzerzertifikate können für zwischen AAD und AD synchronisierte Benutzer funktionieren. Die Zertifikate müssen die UPNs der Benutzer enthalten, die NPS verwendet, um sie Benutzern in AD mit demselben UPN zuzuordnen.

Andere

Im Allgemeinen müssen Sie das SCEPman Root CA-Zertifikat als vertrauenswürdige CA im NAC hinzufügen.

Möglicherweise müssen Sie die SCEPman-OCSP-URL manuell hinzufügen. Die OCSP-URL finden Sie in der Authority Information Access (AIA)-Erweiterung eines beliebigen Client-Zertifikats.