Cisco ISE Host-Header-Einschränkung

Sowohl Cisco ISE als auch Aruba ClearPass (nur bis einschließlich ClearPass 6.9.5) unterstützen bei der Abfrage von OCSP kein HTTP 1.1 und senden keinen Host-Header in ihrer OCSP-Anfrage. Das 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-Anfragen zu senden, während OpenSSL 1.1.0, veröffentlicht im August 2016, dies automatisch erledigt. Daher können sie keine Verbindung zu einer allgemeinen SCEPman-Instanz herstellen, die auf Azure App Services ausgeführt wird. Die Fehlermeldung könnte wie folgt aussehen:

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

Die folgenden Anweisungen skizzieren die erforderlichen Schritte zur Erstellung eines Azure Application Gateway für SCEPman:

1) Erstellen Sie ein neues Application Gateway

2) Geben Sie die notwendigen 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 Routingregel für HTTP hinzu

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

Anfang Juni hat Microsoft einen Fehler im Azure Application Gateway eingeführt, der das Hinzufügen eines Host-Headers zu host-header-freien Anfragen verhindert, wenn „Hostnamen vom Backend-Ziel auswählen“ aktiviert ist. Wir empfahlen „Hostnamen vom Backend-Ziel auswählen“ in einer früheren Version dieser Dokumentation, aber das funktioniert nicht mehr. Als Workaround wählen Sie „Mit spezifischem Domainnamen überschreiben“ wie unten dargestellt und geben Sie den Namen Ihres SCEPman App Service ein, z. B. contoso-scepman.azurewebsites.net.

6) Optional: Fügen Sie eine Routingregel für HTTPS hinzu

Dieser Schritt erfordert ein HTTPS-Webserverzertifikat.

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

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

7) Routingregeln bestätigen

8) Konfiguration des Application Gateway abschließen

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 für die IP-Adresse

2. Fügen Sie eine Bezeichnung Ihrer Wahl als DNS-Namen-Label hinzu

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

Im geo-redundanten Szenario können Sie weiterhin die benutzerdefinierte SCEPman-Domain-URL (die auf den Traffic Manager zeigt) und die Application Gateway-URL in Cisco ISE 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 Die S/MIME-Funktion ist im neuesten Outlook-Client nicht verfügbar. Mehr Info

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-Anfragen unterstützt.