Limitação do cabeçalho Host do Cisco ISE

Tanto o Cisco ISE como 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 de host no seu pedido OCSP. Isto é provavelmente porque o OpenSSL até à versão 1.0.2, que parece ser utilizado no backend, exigia um parâmetro adicional para enviar o cabeçalho de host para pedidos OCSP, enquanto o OpenSSL 1.1.0, lançado em agosto de 2016, faz isso automaticamente. Portanto, eles não conseguem ligar-se a uma instância genérica do SCEPman em execução no Azure App Services. A mensagem de erro pode ter este aspeto:

A Cisco está atualmente a investigar melhorias futuras, mas, por agora, pode usar um Azure Application Gateway para fornecer uma instância do SCEPman que não exija um Host Header.

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

1) Criar um novo Application Gateway

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

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

4) Criar um novo Backend Pool e apontá-lo para o seu SCEPman App Service

No cenário Geo-Redundant, tem de adicionar ambos os App Services do SCEPman ao backend pool.

5) Adicionar uma regra de encaminhamento para HTTP

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

Por volta do início de junho, a Microsoft introduziu um erro no Azure Application Gateway que impede a adição de um cabeçalho de host a pedidos sem cabeçalho de host quando "Selecionar nome de host do destino de back-end" está selecionado. Recomendámos "Selecionar nome de host do destino de back-end" numa versão anterior desta documentação, mas isso já não funciona. Como solução alternativa, escolha "Substituir por nome de domínio específico", como mostrado abaixo, e insira o nome do seu SCEPman App Service, por ex. contoso-scepman.azurewebsites.net.

6) Opcional: Adicionar uma regra de encaminhamento para HTTPS

Este passo requer um certificado de servidor Web HTTPS.

O uso de HTTP sem TLS não é uma vulnerabilidade de segurança; os recursos baseados em PKI são normalmente publicados via HTTP sem TLS, uma vez que o handshake TLS pode exigir acesso a estes 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, estes recursos de PKI, incluindo os protocolos SCEP e OCSP, utilizam a sua própria encriptação e/ou assinaturas, quando tal é necessário.

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

7) Confirmar as regras de encaminhamento

8) Finalizar a configuração do Application Gateway

9) Configurar o nome DNS para o IP

Depois, adicione um nome DNS para o Gateway:

1. Abra o recurso Endereço IP
2. Adicione um nome à sua escolha como rótulo do nome DNS

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

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

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

Nota: O URL do respondedor OCSP deve ser HTTP e não HTTPS, veja aqui

configuração do Intune/JAMF

Ainda pode usar o URL do App Service em vez do URL do Azure Application Gateway na configuração do Intune. Se fizer isso, os clientes comunicam diretamente com o App Service. Tem de configurar o URL do Azure Application Gateway no Cisco ISE, pois apenas este URL suporta pedidos HTTP 1.0.