Cisco ISE Host-Header-Einschränkung

Sowohl Cisco ISE als auch Aruba ClearPass (nur bis einschließlich ClearPass 6.9.5) unterstützen HTTP 1.1 beim Nachschlagen von OCSP nicht und senden in ihrer OCSP-Anforderung keinen Host-Header. Dies liegt wahrscheinlich daran, dass OpenSSL bis Version 1.0.2, das offenbar im Backend verwendet wird, einen zusätzlichen Parameter erforderte, um den Host-Header für OCSP-Anforderungen zu senden, während OpenSSL 1.1.0, das im August 2016 veröffentlicht wurde, dies automatisch erledigt. Daher können sie keine Verbindung zu einer allgemeinen SCEPman-Instanz herstellen, die auf Azure App Services läuft. Die Fehlermeldung kann etwa so aussehen:

Cisco untersucht derzeit zukünftige Verbesserungen, aber vorerst können Sie Azure Application Gateway verwenden, um eine SCEPman-Instanz bereitzustellen, die keinen Host-Header erfordert.

Die folgenden Anweisungen beschreiben die Schritte, die erforderlich sind, um ein Azure Application Gateway für SCEPman zu erstellen:

1) Erstellen Sie ein neues Application Gateway

2) Geben Sie die erforderlichen Basisinformationen an

3) Erstellen Sie eine neue statische öffentliche IP-Adresse

4) Erstellen Sie einen neuen Backend-Pool und verweisen Sie ihn auf Ihren SCEPman App Service

Im geo-redundanten Szenario müssen Sie beide SCEPman-App-Services zum Backend-Pool hinzufügen.

5) Fügen Sie eine Routing-Regel für HTTP hinzu

5b) Fügen Sie eine neue HTTP-Einstellung mit Host-Header hinzu (Ihr öffentlicher SCEPman-FQDN)

Anfang Juni hat Microsoft einen Fehler im Azure Application Gateway eingeführt, der das Hinzufügen eines Host-Headers zu host-headerfreien Anforderungen verhindert, wenn „Hostnamen vom Backendziel auswählen“ ausgewählt ist. In einer früheren Version dieser Dokumentation haben wir „Hostnamen vom Backendziel auswählen“ empfohlen, aber das funktioniert nicht mehr. Wählen Sie als Workaround wie unten dargestellt „Mit spezifischem Domänennamen überschreiben“ und geben Sie den Namen Ihres SCEPman App Service ein, z. B. contoso-scepman.azurewebsites.net.

6) Optional: Fügen Sie eine Routing-Regel für HTTPS hinzu

Für diesen Schritt ist ein HTTPS-Webserverzertifikat erforderlich.

Die Verwendung von HTTP ohne TLS ist keine Sicherheitslücke; PKI-basierte Ressourcen werden üblicherweise per HTTP ohne TLS veröffentlicht, da der TLS-Handshake möglicherweise Zugriff auf diese Ressourcen erfordert. Die Verwendung von TLS würde ein Henne-Ei-Problem erzeugen, bei dem der TLS-Handshake Zugriff auf die PKI-Ressourcen erfordert und der Zugriff auf die PKI-Ressourcen einen TLS-Handshake erfordert. Daher verwenden diese PKI-Ressourcen einschließlich der Protokolle SCEP und OCSP ihre eigene Verschlüsselung und/oder Signaturen, wo dies erforderlich ist.

6b) Fügen Sie eine neue HTTPS-Einstellung mit Host-Header hinzu (Ihr öffentlicher SCEPman-FQDN)

7) Bestätigen Sie die Routing-Regeln

8) Schließen Sie die Konfiguration des Application Gateway ab

9) Konfigurieren Sie den DNS-Namen für die IP

Fügen Sie dann einen DNS-Namen für das Gateway hinzu:

1. Öffnen Sie die Ressource der IP-Adresse

2. Fügen Sie einen Namen Ihrer Wahl als DNS-Namensbezeichnung hinzu

Optional: Sie können in Ihrem eigenen DNS-Server einen CNAME-Eintrag für den DNS-Namen hinzufügen.

Im geo-redundanten Szenario können Sie in Cisco ISE weiterhin die benutzerdefinierte SCEPman-Domain-URL (die auf den Traffic Manager verweist) und die URL des Application Gateway als OCSP-Responder verwenden.

Die OCSP-Responder-URL wäre: http://<Application-Gateway-URL>/ocsp

Hinweis: Die OCSP-Responder-URL sollte HTTP und nicht HTTPS sein, siehe hier

Intune/JAMF-Konfiguration

Sie können in der Intune-Konfiguration weiterhin die URL des App Service anstelle der des Azure Application Gateway verwenden. Wenn Sie dies tun, kommunizieren die Clients direkt mit dem App Service. Sie müssen die URL des Azure Application Gateway in Cisco ISE konfigurieren, da nur diese URL HTTP-1.0-Anforderungen unterstützt.