Cisco ISE Host Header Limitation

Both Cisco ISE as well as Aruba ClearPass (only up to and including ClearPass 6.9.5) do not support HTTP 1.1 when looking up OCSP and do not send a host header in their OCSP request. This is likely because OpenSSL up to version 1.0.2, which seems to be used in the backend, required an extra parameter to send the host header for OCSP requests, while OpenSSL 1.1.0 released in August 2016 does that automatically. Therefore, they cannot connect to a general SCEPman instance running on Azure App Services. The error message may look like this:

Cisco is currently investigating future enhancements but for the time being you can use an Azure Application Gateway to provide an instance of SCEPman not requiring a Host Header.

The following instructions outline the steps required to create an Azure Application Gateway for SCEPman:

1) Create a new Application Gateway

2) Provide the necessary basic information

3) Create a new static public IP address

4) Create a new Backend Pool and point it to your SCEPman App Service

In the Geo-Redundant scenario, you must add both SCEPman app services to the backend pool.

5) Add a routing rule for HTTP

5b) Add a new HTTP Setting with Host Header (your SCEPman public FQDN)

Around the beginning of June, Microsoft introduced a bug in Azure Application Gateway that prevents adding a host header to host-header-free requests when "Pick host name from backend target" is selected. We recommended "Pick host name from backend target" in a previous version of this documentation, but this does no longer work. As a workaround, choose "Override with specific domain name" as depicted below and insert the name of your SCEPman App Service, e.g. contoso-scepman.azurewebsites.net.

6) Optional: Add a routing rule for HTTPS

This step requires an HTTPS web server certificate.

The use of HTTP without TLS is not a security vulnerability; PKI-based resources are commonly published via HTTP without TLS, as the TLS handshake may require access to these resources. Using TLS would create a chicken-and-egg problem where the TLS handshake requires access to the PKI resources and access to the PKI resources requires a TLS handshake. Therefore, these PKI resources including the protocols SCEP and OCSP employ their own encryption and/or signatures where it is required.

6b) Add a new HTTPS Setting with Host Header (your SCEPman public FQDN)

7) Confirm Routing Rules

8) Finalize the Application Gateway configuration

9) Configure the DNS name for the IP

Then, add a DNS name for the Gateway:

Open the IP Address resource
Add a name of your choice as DNS name label

Optional: You can add a CNAME entry for the DNS name in your own DNS server.

In Geo-Redundant scenario, you can still use the SCEPman custom domain URL (which points to the traffic manager) and the Application Gateway URL in Cisco ISE as an OCSP responder.

OCSP responder URL would be: http://<Application-Gateway-URL>/ocsp

Note: The OCSP responder URL should be HTTP not HTTPS, see here

Intune/JAMF configuration

You may still use the App Service's URL instead of the Azure Application Gateway's in the Intune configuration. If you do this, the clients communicate directly with the App Service. You must configure the Azure Application Gateway's URL in Cisco ISE, as only this URL supports HTTP 1.0 requests.

Last updated 8 months ago

Was this helpful?

5b) Add a new HTTP Setting with Host Header (your SCEPman public FQDN)

6) Optional: Add a routing rule for HTTPS

This step requires an HTTPS web server certificate.

9) Configure the DNS name for the IP

Then, add a DNS name for the Gateway:

Open the IP Address resource

Add a name of your choice as DNS name label

Optional: You can add a CNAME entry for the DNS name in your own DNS server.

In Geo-Redundant scenario, you can still use the SCEPman custom domain URL (which points to the traffic manager) and the Application Gateway URL in Cisco ISE as an OCSP responder.

OCSP responder URL would be: http://<Application-Gateway-URL>/ocsp

Note: The OCSP responder URL should be HTTP not HTTPS, see here