Limitation d'en-tête d'hôte Cisco ISE

Tant Cisco ISE que Aruba ClearPass (uniquement jusqu'à et y compris ClearPass 6.9.5) ne prennent pas en charge HTTP 1.1 lors de la vérification OCSP et n'envoient pas d'en-tête Host dans leur requête OCSP. Cela est probablement dû au fait qu'OpenSSL jusqu'à la version 1.0.2, qui semble être utilisé en arrière-plan, exigeait un paramètre supplémentaire pour envoyer l'en-tête Host pour les requêtes OCSP, tandis qu'OpenSSL 1.1.0 publié en août 2016 le fait automatiquement. Par conséquent, ils ne peuvent pas se connecter à une instance SCEPman générale exécutée sur Azure App Services. Le message d'erreur peut ressembler à ceci :

Cisco étudie actuellement des améliorations futures mais pour l'instant vous pouvez utiliser un Azure Application Gateway pour fournir une instance de SCEPman ne nécessitant pas d'en-tête Host.

Les instructions suivantes décrivent les étapes nécessaires pour créer un Azure Application Gateway pour SCEPman :

1) Créer un nouveau Application Gateway

2) Fournir les informations de base nécessaires

3) Créer une nouvelle adresse IP publique statique

4) Créer un nouveau Backend Pool et le pointer vers votre App Service SCEPman

Dans le scénario géo-redondant, vous devez ajouter les deux App Services SCEPman au pool de backend.

5) Ajouter une règle de routage pour HTTP

5b) Ajouter un nouveau paramètre HTTP avec en-tête Host (votre FQDN public SCEPman)

Vers le début du mois de juin, Microsoft a introduit un bug dans Azure Application Gateway qui empêche l'ajout d'un en-tête Host aux requêtes sans en-tête Host lorsque "Pick host name from backend target" est sélectionné. Nous recommandions "Pick host name from backend target" dans une version précédente de cette documentation, mais cela ne fonctionne plus. Comme solution de contournement, choisissez "Override with specific domain name" comme illustré ci-dessous et insérez le nom de votre App Service SCEPman, par ex. contoso-scepman.azurewebsites.net.

6) Optionnel : Ajouter une règle de routage pour HTTPS

Cette étape nécessite un certificat de serveur Web HTTPS.

L'utilisation de HTTP sans TLS n'est pas une vulnérabilité de sécurité ; les ressources basées sur la PKI sont couramment publiées via HTTP sans TLS, car la poignée de main TLS peut nécessiter l'accès à ces ressources. L'utilisation de TLS créerait un problème du genre poule et œuf où la poignée de main TLS nécessite l'accès aux ressources PKI et l'accès aux ressources PKI nécessite une poignée de main TLS. Par conséquent, ces ressources PKI, y compris les protocoles SCEP et OCSP, emploient leur propre chiffrement et/ou signatures lorsque cela est nécessaire.

6b) Ajouter un nouveau paramètre HTTPS avec en-tête Host (votre FQDN public SCEPman)

7) Confirmer les règles de routage

8) Finaliser la configuration de l'Application Gateway

9) Configurer le nom DNS pour l'IP

Ensuite, ajoutez un nom DNS pour la passerelle :

1. Ouvrir la ressource Adresse IP

2. Ajouter un nom de votre choix comme étiquette de nom DNS

Optionnel : Vous pouvez ajouter une entrée CNAME pour le nom DNS dans votre propre serveur DNS.

Dans le scénario géo-redondant, vous pouvez toujours utiliser l'URL de domaine personnalisé SCEPman (qui pointe vers le traffic manager) et l'URL de l'Application Gateway dans Cisco ISE en tant que répondeur OCSP.

L'URL du répondeur OCSP serait : http://<Application-Gateway-URL>/ocsp

Remarque : L'URL du répondeur OCSP doit être HTTP et non HTTPS, voir ici

Configuration Intune/JAMF

Vous pouvez toujours utiliser l'URL de l'App Service au lieu de celle de l'Azure Application Gateway dans la configuration Intune. Si vous faites cela, les clients communiquent directement avec l'App Service. Vous devez configurer l'URL de l'Azure Application Gateway dans Cisco ISE, car seule cette URL prend en charge les requêtes HTTP 1.0.