Limitação de Header Host do Cisco ISE

Tanto o Cisco ISE quanto o Aruba ClearPass (apenas até e incluindo ClearPass 6.9.5) não suportam HTTP 1.1 ao consultar OCSP e não enviam um cabeçalho Host em sua requisição OCSP. Isso provavelmente ocorre porque o OpenSSL até a versão 1.0.2, que parece ser usado no backend, exigia um parâmetro extra para enviar o cabeçalho Host em requisições OCSP, enquanto o OpenSSL 1.1.0 lançado em agosto de 2016 faz isso automaticamente. Portanto, eles não conseguem se conectar a uma instância genérica do SCEPman executando no Azure App Services. A mensagem de erro pode ser semelhante a esta:

A Cisco está atualmente investigando aprimoramentos futuros, mas por enquanto você pode usar um Azure Application Gateway para fornecer uma instância do SCEPman que não exija um cabeçalho Host.

As instruções a seguir descrevem os passos necessários para criar um Azure Application Gateway para o SCEPman:

1) Crie um novo Application Gateway

2) Forneça as informações básicas necessárias

3) Crie um novo endereço IP público estático

4) Crie um novo Backend Pool e aponte-o para o seu App Service do SCEPman

No cenário Geo-Redundant, você deve adicionar ambos os serviços de aplicativo SCEPman ao backend pool.

5) Adicione uma regra de roteamento para HTTP

5b) Adicione uma nova Configuração de HTTP com Host Header (seu FQDN público do SCEPman)

Por volta do início de junho, a Microsoft introduziu um bug no Azure Application Gateway que impede a adição de um cabeçalho Host a requisições sem host header quando "Pick host name from backend target" está selecionado. Recomendamos "Pick host name from backend target" em uma versão anterior desta documentação, mas isso não funciona mais. Como solução alternativa, escolha "Override with specific domain name" conforme ilustrado abaixo e insira o nome do seu App Service do SCEPman, por exemplo contoso-scepman.azurewebsites.net.

6) Opcional: Adicione uma regra de roteamento para HTTPS

Esta etapa requer um certificado de servidor web HTTPS.

O uso de HTTP sem TLS não é uma vulnerabilidade de segurança; recursos baseados em PKI costumam ser publicados via HTTP sem TLS, pois o handshake TLS pode exigir acesso a esses recursos. Usar TLS criaria um problema de galinha e ovo em que o handshake TLS requer acesso aos recursos de PKI e o acesso aos recursos de PKI requer um handshake TLS. Portanto, esses recursos de PKI, incluindo os protocolos SCEP e OCSP, empregam sua própria criptografia e/ou assinaturas quando necessário.

6b) Adicione uma nova Configuração HTTPS com Host Header (seu FQDN público do SCEPman)

7) Confirme as Regras de Roteamento

8) Finalize a configuração do Application Gateway

9) Configure o nome DNS para o IP

Em seguida, adicione um nome DNS para o Gateway:

1. Abra o recurso de Endereço IP

2. Adicione um nome de sua escolha como rótulo do nome DNS

Opcional: Você pode adicionar uma entrada CNAME para o nome DNS no seu próprio servidor DNS.

No cenário Geo-Redundant, você ainda pode usar a URL de domínio personalizado do SCEPman (que aponta para o traffic manager) e a URL do Application Gateway no Cisco ISE como um respondedor OCSP.

A URL do respondedor OCSP seria: http://<Application-Gateway-URL>/ocsp

Observação: A URL do respondedor OCSP deve ser HTTP e não HTTPS, veja aqui

Configuração Intune/JAMF

Você ainda pode usar a URL do App Service em vez da do Azure Application Gateway na configuração do Intune. Se fizer isso, os clientes se comunicam diretamente com o App Service. Você deve configurar a URL do Azure Application Gateway no Cisco ISE, pois apenas essa URL suporta requisições HTTP 1.0.