# 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 procurar OCSP e não enviam um cabeçalho Host no seu pedido OCSP. Isto provavelmente ocorre porque o OpenSSL até à versão 1.0.2, que parece estar a ser usado no backend, [exigia um parâmetro adicional para enviar o cabeçalho Host para pedidos OCSP](https://github.com/openssl/openssl/issues/1986), 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 geral do SCEPman em execução no Azure App Services. A mensagem de erro poderá ser semelhante a esta:

![](https://3802289327-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-73190ac3e2e77c25974776ffa48e74b2c33f96da%2Fcisco-ocsp-error%20\(2\)%20\(4\)%20\(4\)%20\(4\)%20\(4\)%20\(4\)%20\(2\)%20\(1\).jpg?alt=media)

A Cisco está atualmente a investigar melhorias futuras, mas, por enquanto, pode usar um [Azure Application Gateway](https://azure.microsoft.com/en-us/services/application-gateway/) para disponibilizar uma instância do SCEPman que não requer 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

![](https://3802289327-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-a402724c716fac522d61e03233aff4e96a90e2f4%2Fscreen-shot-2019-10-18-at-17.12.40%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(1\).png?alt=media)

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

![](https://3802289327-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-367c46f5958d85d0c7d98e7b4691bd93add555ae%2Fscreen-shot-2019-10-18-at-17.13.55%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(1\).png?alt=media)

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

![](https://3802289327-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-9f24e6ff6ca4195383c78bbb74ca1e3afae92a2c%2Fscreen-shot-2019-10-18-at-17.14.19%20\(2\)%20\(4\)%20\(5\)%20\(5\)%20\(5\)%20\(2\)%20\(1\).png?alt=media)

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

![](https://3802289327-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-4e763c48bd1ccfd3326d7a86ec2573e68f25b3a1%2Fscreen-shot-2019-10-18-at-17.14.55%20\(2\)%20\(4\)%20\(5\)%20\(2\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(2\)%20\(6\).png?alt=media)

{% hint style="info" %}
No cenário Geo-Redundant, deve adicionar ambos os SCEPman app services ao backend pool.
{% endhint %}

## 5) Adicionar uma regra de encaminhamento para HTTP

![](https://3802289327-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-fe2deec114610507ba0c0133a4270b8d9502eeda%2Fscreen-shot-2019-10-18-at-17.15.36%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(2\)%20\(1\).png?alt=media)

![](https://3802289327-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-66becdc39468a7feb2cfbef12b2bd65ad8f34c35%2FReplace5.png?alt=media)

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

{% hint style="warning" %}
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 Host a pedidos sem host-header quando "Pick host name from backend target" está selecionado. Numa versão anterior desta documentação, recomendámos "Pick host name from backend target", mas isso já não funciona. Como solução alternativa, escolha "Override with specific domain name", como mostrado abaixo, e insira o nome do seu SCEPman App Service, por exemplo, *contoso-scepman.azurewebsites.net*.
{% endhint %}

![](https://3802289327-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-9cfce9cc03543f0741deb930dda57ee46cfc487e%2Fscreen-shot-2019-10-18-at-17.16.21%20\(1\)%20\(1\)%20\(2\)%20\(4\)%20\(3\)%20\(1\).png?alt=media)

![](https://3802289327-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-2a9b2259c01bf0b04c56de7c104bb9b841448513%2FReplace5b2.png?alt=media)

## 6) Opcional: Adicionar uma regra de encaminhamento para HTTPS

{% hint style="warning" %}
Este passo requer um certificado de servidor Web HTTPS.
{% endhint %}

{% hint style="info" %}
A utilização 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. A utilização de TLS criaria um problema de ovo e galinha, em que o handshake TLS requer acesso aos recursos PKI e o acesso aos recursos PKI requer um handshake TLS. Por isso, estes recursos PKI, incluindo os protocolos SCEP e OCSP, utilizam a sua própria encriptação e/ou assinaturas quando isso é necessário.
{% endhint %}

![](https://3802289327-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-61115b6a2a67ab4be644da31ceae6817dc9555a1%2FReplace61.png?alt=media)

![](https://3802289327-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-9535788b316a6ca84de9606e7c218a9a7d3078c0%2Fscreen-shot-2019-10-18-at-17.17.44%20\(2\)%20\(4\)%20\(3\).png?alt=media)

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

<figure><img src="https://3802289327-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2FowpbgDoNuM7dKtGKGxsO%2F2024-06-06%2016_52_56-.png?alt=media&#x26;token=ca795e9c-c7d5-445f-ad66-5f1c21f3119c" alt=""><figcaption></figcaption></figure>

![](https://3802289327-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-92a1c1e3bb6cabf50ff4385faa0262b62ba48f80%2FReplace62.png?alt=media)

## 7) Confirmar as Regras de Encaminhamento

![](https://3802289327-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-f71ff2eac67cf28c1e5a8dd4357932609821eff6%2Fscreen-shot-2019-10-18-at-17.18.56%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(2\)%20\(1\).png?alt=media)

## 8) Concluir a configuração do Application Gateway

![](https://3802289327-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-5fedc198773af98b0271c069470a71093d850b33%2Fscreen-shot-2019-10-18-at-17.19.13%20\(2\)%20\(4\)%20\(3\)%20\(1\).png?alt=media)

## 9) Configurar o nome DNS para o IP

Depois, adicione um nome DNS para o Gateway:

1. Abra o recurso de Endereço IP
2. Adicione um nome à sua escolha como etiqueta de nome DNS

![](https://3802289327-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-baaec006f5aac20c38fb1ed18a464e4849845770%2Fip-address.png?alt=media)

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

{% hint style="info" %}
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.
{% endhint %}

{% hint style="info" %}
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](https://docs.scepman.com/pt/security-faq#id-21.-can-https-only-be-enabled)
{% endhint %}

## 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. Deve configurar o URL do Azure Application Gateway no Cisco ISE, uma vez que apenas este URL suporta pedidos HTTP 1.0.
