Limitation de l'en-tête Host de Cisco ISE

Tant Cisco ISE qu’Aruba ClearPass (uniquement jusqu’à et y compris ClearPass 6.9.5) ne prennent pas en charge HTTP 1.1 lors de la recherche d’OCSP et n’envoient pas d’en-tête d’hôte dans leur requête OCSP. Cela est probablement dû au fait qu’OpenSSL jusqu’à la version 1.0.2, qui semble être utilisé dans le backend, nécessitait un paramètre supplémentaire pour envoyer l’en-tête d’hôte 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 de futures améliorations, mais pour le moment vous pouvez utiliser un Azure Application Gateway pour fournir une instance de SCEPman ne nécessitant pas d’en-tête d’hôte.

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

1) Créez un nouvel Application Gateway

2) Fournissez les informations de base nécessaires

3) Créez une nouvelle adresse IP publique statique

4) Créez un nouveau pool de back-end et pointez-le vers votre App Service SCEPman

Dans le scénario géoredondant, vous devez ajouter les deux App Services SCEPman au pool de back-end.

5) Ajoutez une règle de routage pour HTTP

5b) Ajoutez un nouveau paramètre HTTP avec en-tête d’hôte (le FQDN public de votre 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 d’hôte à des requêtes sans en-tête d’hôte 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 indiqué ci-dessous et insérez le nom de votre App Service SCEPman, par exemple contoso-scepman.azurewebsites.net.

6) Facultatif : ajoutez 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 faille de sécurité ; les ressources basées sur PKI sont couramment publiées via HTTP sans TLS, car le handshake TLS peut nécessiter l’accès à ces ressources. L’utilisation de TLS créerait un problème de type « l’œuf et la poule », où le handshake TLS nécessite l’accès aux ressources PKI et où l’accès aux ressources PKI nécessite un handshake TLS. Par conséquent, ces ressources PKI, y compris les protocoles SCEP et OCSP, utilisent leur propre chiffrement et/ou leurs propres signatures lorsque cela est requis.

6b) Ajoutez un nouveau paramètre HTTPS avec en-tête d’hôte (le FQDN public de votre SCEPman)

7) Confirmez les règles de routage

8) Finalisez la configuration de l’Application Gateway

9) Configurez le nom DNS pour l’adresse IP

Ensuite, ajoutez un nom DNS pour la passerelle :

1. Ouvrez la ressource d’adresse IP
2. Ajoutez un nom de votre choix comme étiquette de nom DNS

Facultatif : vous pouvez ajouter une entrée CNAME pour le nom DNS sur votre propre serveur DNS.

Dans le scénario géoredondant, vous pouvez toujours utiliser l’URL du domaine personnalisé SCEPman (qui pointe vers le gestionnaire de trafic) ainsi que l’URL de l’Application Gateway dans Cisco ISE comme répondeur OCSP.

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

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

Configuration Intune/JAMF

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