Como implementar Certificados Digitais no ISE

[Marcelo Morais]

This is a translation from the superb document: How to Implement Digital Certificates in ISE from @thomas.

Esta é uma tradução do extraordinário documento: How to Implement Digital Certificates in ISE de @thomas.

Para obter uma cópia off-line ou impressa deste documento, basta escolher: ⋮ > Página amigável pra impressora. Você pode então Imprimir, Imprimir em PDF ou Copiar e Colar em qualquer outro formato de documento de sua preferência.

• Uso de Certificado
• Então, o que é um Certificado?
• Determine se uma Autoridade Confiável assinou o Certificado Digital
• Onde os Certificados são usados com o ISE?
• Comunicação HTTPS usando o Certificado ISE
• Comunicação EAP
• Certificado de Confiança (Certificate Trust)
• Certificate Signer
• O Subject do Certificado
• Que valores de Certificado devem ser usados ​​com uma implantação de ISE?
• Modelo 1: Certificado único por Node. Usado para todos os Serviços
• Modelo 2: vários Certificados por Node. Um para cada Serviço
• Modelo 3: usando o mesmo Certificado em todos os PSNs
• Wildcard Certificate
• O que é um Wildcard Certificate?
• Por que usar Wildcard Certificate?
• Benefícios dos Wildcard Certificate
• Desvantagens dos Wildcard Certificate
• Compatibilidade de Wildcard Certificate
• Fazendo os Wildcard funcionarem: o método “WildSAN”
• Suporte ISE para Wildcard Certificate
• Construindo o WildSAN Certificate
• Implementando WildSAN Certificates
• Gerando o WildSAN Certificate
• Criar o Certificate Signing Request (CSR)
• Envie o CSR para a CA
• Importe os Certificados Públicos da CA para o Trusted Certification Store
• Vincule o certificado recém-assinado ao signing request
• Reutilizar o mesmo par de Certificado em outros ISE Nodes
• Artigos adicionais relacionados ao uso, geração e tipos de Certificados

Uso de Certificado

Em um mundo de dispositivos móveis, BYOD e redes sem fronteiras, os Certificados estão rapidamente se tornando uma forma comum de identificação. O uso de Certificados não pode gerar um sentimento de receio nos Administradores de Rede, uma vez que ele pode ser bastante simplificado.

O conceito mais difícil de entender para muitos é o conceito de Certificado Público versus Certificado Privado. Os Certificados são parte da criptografia de Chave Pública ou Criptografia Assimétrica. Assimétrico significa que os dois dispositivos de comunicação criptografarão e descriptografarão os dados com Chaves de criptografia diferentes. O termo “Chave” às vezes pode ser usado e trocado pelo termo “Certificado”.

Haverá duas Chaves, uma Pública e uma Privada.

1. Chave Pública: a Chave Pública está contida no Certificado Público e pode ser fornecida a qualquer pessoa no mundo com quem você se comunique. Na maioria dos casos.
2. Chave Privada: a Chave Privada raramente deve sair do sistema final. Eles representam a identidade desse sistema específico e, se forem expostos e usados por outra entidade, essa outra entidade agora está se passando por sua identidade.

Os itens criptografados com sua Chave Pública só podem ser descriptografados com sua Chave Privada. Na figura acima, se o ponto de extremidade C usa a Chave Pública do ponto de extremidade A para criptografar alguns dados, ele só pode ser descriptografado pelo ponto de extremidade A. Da mesma forma, se B usa a Chave Pública de C para criptografar dados, esses dados só podem ser descriptografados com a Chave Privada de C.

Então, o que é um Certificado?

Um Certificado é um documento assinado que representa uma identidade. Ao pensar em um Certificado, tente relacioná-lo a um passaporte, carteira de motorista ou outro cartão de identificação pessoal. Esse cartão de identificação tem como objetivo representá-lo e provar que você é quem diz ser. Esse Certificado também contém a Chave Pública dessa entidade, portanto, qualquer pessoa com o Certificado Público será capaz de criptografar dados que apenas o proprietário do Certificado pode descriptografar.

Esta seção discutirá como as autenticações baseadas em Certificado realmente funcionam. Quando apresentado com um Certificado, um Servidor de Autenticação executará as seguintes verificações (no mínimo):

1. Determinar se uma Autoridade Confiável assinou o Certificado Digital.
2. Examinar as Datas de Início e Término para determinar se o Certificado expirou.
3. Verificar se o Certificado foi revogado. (pode usar verificação OCSP ou CRL)
4. Validar se o Cliente forneceu prova de posse.

Vamos examinar os itens acima, um de cada vez.

Determine se uma Autoridade Confiável assinou o Certificado Digital

A Assinatura do Certificado tem duas partes:

A primeira parte é que o Certificado deve ter sido assinado corretamente (seguindo o formato correto, etc). Se não estiver, ele será descartado imediatamente.

A segunda parte é que o Certificado Público da Certificate Authority (CA) deve estar na lista de Certificados Confiáveis (Trusted Certificate Store) e deve ser confiável para fins de autenticação. Ao usar o Cisco ISE, uma cópia do Certificado Público da CA deve ser armazenada em Administration > System > Certificates > Certificate Store e será necessário selecionar "Trust for Client Authentication" em Usage.

Onde os Certificados são usados com o ISE?

Os Certificados são frequentemente empregados em uma rede que implementa Secure Access. Os Certificados são usados para identificar o Identity Services Engine (ISE) para um Endpoint, bem como para proteger a comunicação entre esse Endpoint e o ISE Node. O Certificado é usado para todas as comunicações HTTPS, bem como para a comunicação do Extensible Authentication Protocol (EAP).

Comunicação HTTPS usando o Certificado ISE

Cada portal da web no ISE versão 1.1.0 ou superior é protegido por HTTPS (comunicação HTTP criptografada por SSL). Os exemplos incluem, mas não estão limitados a:

• Administrative Portal
• Sponsor Portal & Guest Portal
• BYOD e Client Provisioning Portal (CPP)
• MyDevices Portal
• Mobile Device Management (MDM) Portal

Esta figura descreve o processo criptografado SSL durante a comunicação com o Admin Portal.

Comunicação EAP

Os Certificados são usados com quase todos os métodos EAP possíveis. Os principais exemplos incluem:

• EAP-TLS
• PEAP
• EAP-FAST

Um tunneled EAP, tais como PEAP e FAST, o Transport Layer Security (TLS) é usado para proteger a troca de credenciais. Muito parecido com ir a um site HTTPS, o cliente estabelece a conexão com o servidor, que apresenta seu Certificado ao cliente. Se o Cliente confiar no Certificado, o TLS tunnel será formado. As credenciais do Cliente não são enviadas ao Servidor até que este túnel seja estabelecido, garantindo assim uma troca segura. Em uma implantação do Secure Access, o Cliente é um Supplicant e o Servidor é um ISE Policy Services Node (PSN).

Conforme visto acima, independentemente de onde os Certificados estão sendo usados, a funcionalidade básica é a mesma. O Cliente deve confiar no Servidor e as Chaves dos Certificados são usadas para criptografar e descriptografar a comunicação. O conceito de confiança é muito importante. Sempre que trabalhar com autenticações baseadas em Certificados, uma pergunta fundamental que sempre se deve perguntar é: “O Cliente confia no Servidor” e “o Servidor confia no Cliente”.

Nota: Em muitos casos, o Servidor não precisa confiar no Certificado do Cliente. Os Clientes também podem ser configurados para não exigir que o Certificado do Servidor seja confiável. Todas as opções são escolhas de configuração.

Certificado de Confiança (Certificate Trust)

Os Certificados são semelhantes aos documentos assinados. Quando um Cliente se comunica com um Servidor seguro, o Servidor enviará seu Certificado Público para que o Cliente seja verificado. O Cliente examinará o Certificado para determinar se ele é confiável. O Cliente está examinando o Certificate Signer e outros atributos do Certificado, como o Subject.

Certificate Signer

Ao estabelecer uma conexão segura, o Cliente irá validar se o Certificate Signer é uma Autoridade Confiável (Trusted Authority). Se o Cliente não confiar no Certificate Signer, um aviso será exibido, como o mostrado na figura abaixo. O Cliente (navegador Firefox) está estabelecendo uma conexão segura com um Admin Portal do ISE. O Certificado usado para proteger esse portal é um Certificado Autoassinado (Self-signed Certificate) (assinado somente pelo próprio ISE e não por uma Autoridade conhecida) e, portanto, o navegador não confia nesse signer:

Um Certificato Não-Confiável (Untrusted Certificate).

O Subject do Certificado

O Certificado é criado com um Subject específico. Esse Subject define a entidade que foi criada para proteger. Por exemplo, se você examinar o Certificado usado com https://www.cisco.com, verá uma representação semelhante à exibida abaixo. O Certificado usado tem um Subject que declara que este Certificado foi emitido para proteger www.cisco.com (o valor CN do Subject do Certificado).

Certificado de https://www.cisco.com

Além de um Subject, um Certificado também pode ter um Subject Alternative Name (SAN). Essa extensão do Certificado foi projetada para permitir que um único Certificado seja usado para proteger mais de um Fully Qualify Domain Name (FQDN). Outra maneira de ver a mesma instrução é que muitos FQDNs diferentes podem apontar para o mesmo site seguro.

Usando o Certificado de www.cisco.com como exemplo, existem valores listados no campo SAN, como: www1.cisco.com, www2.cisco.com e outros.

 Subject Alternative Names

Que valores de Certificado devem ser usados ​​com uma implantação de ISE?

Com um ISE Deployment, o Administrador tem algumas opções relacionadas ao uso de um único Certificado para todas as identidades ou uma mistura de Certificado diferentes, não mais do que um para cada identidade.

Essa é uma declaração confusa. Vamos explicar um pouco mais. Cada ISE Node pode ter muitas identidades diferentes.

• Admin Identity: um ISE Node tem que se identificar aos outros ISE Node em um ISE Cube (também chamado de ISE Deployment). O Policy Administrative Node (PAN) deve ter comunicação bidirecional segura com todos os Policy Service Nodes (PSNs) e o Monitoring and Troubleshooting Node (MnT) para sincronização de política e comunicação de gerenciamento. Esta mesma identidade é usada quando um Administrador se conecta ao Administrative Portal de um ISE Node.
  A identidade que deve ser protegida para o caso de uso Admin é o FQDN do próprio ISE Node. Portanto, o Subject ou SAN deve combinar o FQDN do ISE Node.
• EAP Identity: um ISE Node tem que se identificar aos EAP Clients (dot1x) que estão se conectando à rede. Isto está protegendo a comunicação Layer-2 EAP e, portanto, o nome da identidade não precisa ser DNS resolvível e não precisa combinar o nome do próprio ISE Node.
  A identidade que deve ser protegida pode ser o FQDN do próprio ISE Node ou outro valor, como “aaa.security.demo.net” ou “psn.ise.security.demo.net”
• Sponsor Portal Identity: ao usar serviços de sponsored Guest em um ISE Deployment, um Sponsor Portal é usado. Esse Sponsor Portal deve ter um friendly name (um cabeçalho de host HTTP) que é usado para identificar exclusivamente o próprio portal, como “sponsor.security.demo.net”.
  A identidade que deve ser protegida é o friendly name. Portanto, o Certificado usado no Sponsor Portal deve ter um Subject ou SAN que corresponda ao friendly name.
• MyDevices Portal: quando o ISE é configurado para Bring Your Own Device (BYOD), há um MyDevices Portal no qual os usuários finais se conectam para gerenciar seus dispositivos registrados. Assim como o Sponsor Portal, o MyDevices Portal requer um friendly name (um cabeçalho de host HTTP) que é usado para identificar exclusivamente o próprio portal, como “mydevices.security.demo.net”.
  A identidade que deve ser protegida é o friendly name. Portanto, o Certificado usado no MyDevices Portal deve ter um Subject ou SAN que corresponda ao friendly name.
• pxGrid Identity: quando o ISE é configurado para ser um controlador do pxGrid, ele requer um Certificado de Extended Key Usages (EKU) para ambos Servidor e Clientes. O nome não precisa ser resolvido por DNS, portanto, os campos de Subject e SAN não são necessariamente importantes. No entanto, um wildcard não pode ser usado com um Certificado pxGrid (wildcards são abordados em detalhes posteriormente neste documento).
• Guest Portal Identity: pode haver um ou vários portais usados ​​para acesso Guest e Centralized Web Authentication (CWA). Como acontece com todos os portais ISE, cada um precisará se identificar e proteger a comunicação de e para o portal com um Certificado. Em muitos casos Guest, incluindo CWA, há um redirecionamento automático que está ocorrendo para o FQDN do próprio ISE PSN.
  A identidade que deve ser protegida é o(s) PSN(s) que hospedam os Guest Portal e quaisquer friendly name ​​que possam ser usados. Portanto, o Certificado usado para qualquer portal deve ter um Subject ou SAN que corresponda a todos os nomes que ele estará protegendo.

Exemplos de diferentes Certificados e quais serviços eles podem proteger

Aqui estão alguns exemplos de como os Certificados estão sendo usados ​​no diagrama acima:

• Ambos os Certificados de Administrador da PSN estão sendo usados ​​para proteger não apenas sua comunicação com o PAN, mas também o Guest Portal para CWA.
• O Sponsor Portal está sendo protegido com um Certificado com sponsor.securitydemo.net no Subject do Certificado. O mesmo Certificado está sendo usado para o Sponsor Portal no PSN1 e no PSN2.
• PSN1 e PSN2 estão usando seu próprio Certificado EAP para a segurança das comunicações EAP.
• O PAN está usando seu Certificado de Administrador para proteger a comunicação administrativa com os PSNs, bem como para proteger a GUI administrativa.

Este é apenas um exemplo para tentar e solidificar sua compreensão de onde os Certificado estão sendo usados.

A escolha do Administrador do ISE sobre como interromper essas comunicações é muito flexível. Eles podem usar um Certificado por ISE Node para proteger todas as identidades diferentes, podem usar Certificados individuais para cada serviço, podem usar um único Certificado e copiar esse Certificado para cada Node na implantação ou qualquer combinação dos anteriores. As seções a seguir detalham e ilustram três maneiras comuns de criar Certificado no ISE.

Modelo 1: Certificado único por Node. Usado para todos os Serviços

Este método usa um único Certificado por cada ISE Node (PAN, MnT, PSN). Esse Certificado será usado para as funções Admin, EAP, pxGrid, bem como para proteger todos os Portais. Para isso, cada Certificado deve ser configurado para:

• O CN do Subject do Certificado conterá o FQDN do ISE Node
• Nenhum SAN é necessário para o PAN ou MNT se eles forem Nodes dedicados
• Para os PSNs, o SAN do Certificado conterá:
  • FQDN do ISE Node
  • Friendly Name para o Sponsor Portal
  • Friendly Name para o MyDevices Portal
• Se o pxGrid for usado, os usos de Extended Key Usage (EKU) de Servidor e Cliente são necessários.

Modelo 1: cada Node tem seu próprio Certificado

Existem prós e contras de um único Certificado por Node que está sendo usado para todos os serviços.

Prós	Contras
Segue as melhores práticas de segurança de um Certificado exclusivo por Node.	Muitos Endpoints devem aceitar o Certificado para cada comunicação EAP dos PSNs
O uso de SAN é bastante fácil no ISE 1.2+	Não está usando um Certificado diferente em cada Portal.
Mantém o gerenciamento de Certificados bastante fácil	O mesmo Certificado é usado para Admin ao qual Guests e Users serão expostos.

Modelo 2: vários Certificados por Node. Um para cada Serviço

Este método usa um único Certificado por função, por Node. Para isso, cada Certificado deve ser configurado para:

Admin Certificate (todos os ISE Nodes recebem um):

• O CN do Subject do Certificado conterá o FQDN do ISE Node
• Nenhum SAN é necessário
• Pode ser assinado por CA Interna (não público)
• Pode ser autoassinado, embora não seja recomendado

pxGrid Certificate (todos os ISE Nodes obtêm um se você estiver usando pxGrid

• O CN do Subject do Certificado conterá o FQDN do ISE Node
• Nenhum SAN é necessário
• Deve ser assinado por CA Pública
• Pode ser assinado por CA Interno (não público)
• Pode ser autoassinado, embora não seja recomendado
• Deve ter EKUs de autenticação de Cliente e Servidor

EAP Certificate (todos os PSNs recebem um):

• O CN do Subject do Certificado conterá o FQDN do ISE Node
• Nenhum SAN é necessário
• Deve ser assinado por CA Pública

Portal Certificate(s) (um ou mais por PSN

• O CN do Subject do Certificado conterá o FQDN do ISE Node
• Deve ser assinado por CA Pública
• O Certificado SAN conterá:
  • FQDN do ISE Node
  • Friendly Name para cada Portal protegido pelo Certificado
  • ou seja: O FQDN para o MyDevices Portal
  • ou seja: O FQDN para o Sponsor Portal

Modelo 2: Diferentes Certificados por Função

Existem prós e contras de um Certificado separado por Node e por Serviço:

Prós	Contras
Segue as práticas recomendadas de segurança de Certificados exclusivos por Node e vai além, fornecendo Certificados exclusivos por Node e por Função.	Mais Certificados para gerenciar por ISE Node do que o Método 1
	Pode ser caro gerenciar tantos Certificados assinados
	Muitos tipos de Endpoint devem aceitar o Certificado para cada comunicação EAP do PSNs.

Modelo 3: usando o mesmo Certificado em todos os PSNs

Este método usa o mesmo par de Chaves Públicas e Privadas em todos os ISE Nodes. Isso geralmente é usado para ambientes onde há muitos dispositivos do tipo BYOD. O principal motivo para seguir esse modelo é garantir que o mesmo Certificado exato seja usado em todos os PSNs; portanto, os dispositivos BYOD já confiarão em qualquer servidor EAP no qual devem se autenticar.

Para realizar este método, gere um Certificate Signing Request (CSR) em um único ISE Node. Depois de vincular o Certificado assinado à Chave Privada, exporte o Par de Chaves resultante e importe-o em todos os outros Nodes. Configure o Certificado único para:

• O CN do Subject do Certificado conterá um único FQDN, como ise.securitydemo.net
• O SAN do Certificado conterá:
  • O CN do Subject, como ise.securitydemo.net
  • FQDN real de cada ISE Node como entrada SAN
  • Friendly Name para o Sponsor Portal
  • Friendly Name para o MyDevices Portal
• O Certificado precisa de autenticação EKUs de Cliente e Servidor

Modelo 3: mesmo Certificado em todos os Nodes

Existem prós e contras de um Certificado separado por Node e por Serviço:

Prós	Contras
Os Endpoints do tipo BYOD não terão que aceitar manualmente cada Certificado para autenticação EAP.	As práticas recomendadas de segurança de Certificados exclusivos por identidade foram violadas. Cada ISE Node parece idêntico
Fácil gestão.	Usando um único Certificado para funções de Administrador e voltadas para o usuário final
Os custos do Certificado são mantidos baixos	Se um novo PSN Node for adicionado no futuro, o Certificado em cada Node precisará ser atualizado para incluir o novo FQDN

Se não for óbvio, o Administrador do ISE não está limitado a apenas esses três modelos e está livre para misturar e combinar para se adequar a qualquer modelo que seja considerado mais apropriado para o ambiente real.

As próximas seções discutirão outro modelo completamente, o uso de Wildcard e o que estamos chamando de certificados "wildSAN".

Wildcard Certificate

O que é um Wildcard Certificate?

Um Wildcard Certificate é aquele que usa uma notação "curinga" (um asterisco e ponto antes do Domain Name) e permite que o Certificado seja compartilhado entre vários hosts em uma organização. Um exemplo de valor CN para o nome do Subject de um Wildcard Certificate seria parecido com o seguinte: *.securitydemo.net

Se você configurar um Wildcard Certificate para usar *.securitydemo.net, esse mesmo Certificado pode ser usado para proteger qualquer host cujo nome DNS termine em ".securitydemo.net", como:

• aaa.securitydemo.net
• psn.securitydemo.net
• mydevices.securitydemo.net
• sponsor.securitydemo.net

Um wildcard só é válido no campo de host do Fully Qualified Domain Name (FQDN). Em outras palavras, *.securitydemo.net não corresponderia a ise.aaa.securitydemo.net, porque o valor "curinga" não estava na parte do Host do FQDN.

Abaixo está um exemplo do uso de um Wildcard Certificate para proteger um site da Web (especificamente, a interface da Web de um ISE Node). Observe que a URL inserido na barra de endereço do navegador é "atw-lab-ise01.woland.com", mas o Common Name (CN) do Certificado é "* .woland.com".

Exemplo de Wildcard Certificate

Nota: Os Wildcard Certificate protegem as comunicações da mesma maneira que um Certificado normal e as solicitações são processadas usando os mesmos métodos de validação.

Por que usar Wildcard Certificate?

Há várias razões para implementar Wildcard Certificate com um ISE Deployment. Em última análise, aqueles que optam por usá-los, o fazem para garantir que a experiência do usuário final seja a mais perfeita possível, especialmente devido à grande diferença e variedade de terminais.

Benefícios dos Wildcard Certificate

Alguns benefícios do uso de Wildcard Certificate são:

1. Custo Baixo: Os Certificados assinados por uma CA de terceiros podem ser caros, especialmente à medida que o número de servidores aumenta. Os Wildcard Certificate podem ser usados ​​em todos os Nodes do ISE Deployment (também referido como o “ISE Cube”).
2. Eficiência Operacional. Os Wildcard Certificate permitem que todos os serviços EAP e da Web do PSN (Policy Service Node) compartilhem o mesmo Certificado. Além da economia significativa de custos, a administração de Certificados também é simplificada por meio de um modelo “crie uma vez, aplique a muitos”.
3. Erros de Autenticação Reduzidos: Os Wildcard Certificate resolvem problemas como vistos com dispositivos Apple iOS, onde o cliente armazena certificados confiáveis ​​dentro do perfil e não segue o iOS Keychain, onde a raiz de assinatura é confiável. Quando um cliente iOS se comunica pela primeira vez com um PSN, ele não confia explicitamente no Certificado do PSN, embora uma CA confiável tenha assinado o Certificado.
   Usando um Wildcard Certificate, o Certificado será o mesmo em todos os PSNs, portanto, o usuário só precisará aceitar o Certificado uma vez e as autenticações sucessivas em diferentes PSNs devem prosseguir sem erros ou solicitações.
4. Configuração simplificada do Suplicante: Por exemplo, o Suplicante do Microsoft Windows com PEAP-MSCHAPv2 e confiança de Certificado de Servidor habilitada geralmente requer a especificação de cada Certificado de Servidor para confiança, ou o usuário pode ser solicitado a confiar em cada Certificado do PSN quando o Cliente se conecta usando um PSN diferente. Com Wildcard Certificate, um único Certificado de Servidor pode ser confiável, em vez de Certificados individuais de cada PSN.

Em última análise, os Wildcard Certificate resultam em uma experiência do usuário aprimorada. Menos solicitação e conectividade mais contínua se traduzirão em usuários mais felizes e maior produtividade.

Desvantagens dos Wildcard Certificate

Pode haver uma série de benefícios usando Wildcard Certificate, mas também há uma série de considerações de segurança relacionadas a Wildcard Certificate, incluindo:

1. Perda de auditabilidade e não repúdio
2. Maior exposição da Chave Privada
3. Não tão comum ou tão bem compreendido pelos administradores

Embora seja considerado menos seguro do que atribuir um Certificado de servidor exclusivo por ISE Node, o custo e outros fatores operacionais geralmente superam o risco de segurança e exigem a necessidade de oferecer isso como uma opção aos nossos Clientes em suas ISE Deployment. Observe que outros dispositivos de segurança como o ASA também oferecem suporte a Wildcard Certificate.

Você deve sempre ter cuidado ao implantar Wildcard Certificate. Por exemplo, se você criar um Certificado com *.securitydemo.net e um invasor conseguir recuperar a Chave Privada, esse invasor pode falsificar qualquer servidor no domínio securitydemo.net. Portanto, é considerada uma prática recomendada particionar o espaço do domínio para evitar esse tipo de comprometimento.

Para resolver esse possível problema e limitar o escopo de uso, os Wildcard Certificate também podem ser usados ​​para proteger um subdomínio específico de sua organização. Basta adicionar um asterisco (*) na área de subdomínio do Common Name onde deseja especificar o Wildcard. Por exemplo, se você configurar um Wildcard Certificate para *.ise.securitydemo.net, esse mesmo Certificado pode ser usado para proteger qualquer host cujo DNS Name termine em “.ise.securitydemo.net”, como:

• psn.ise.securitydemo.net
• mydevices.ise.securitydemo.net
• patrocinador.ise.securitydemo.net

Compatibilidade de Wildcard Certificate

Wildcard Certificate são mais comumente construídos com o curinga listado como o Canonical Name (CNAME) do campo de Subject do próprio Certificado. O ISE versão 1.2 e mais recente oferece suporte a essa forma de construção; no entanto, nem todos os Suplicantes irão suportar o wildcard no Subject do Certificado.

Todos os suplicantes nativos da Microsoft testados (incluindo Windows Mobile) não oferecem suporte a wildcard no Subject do Certificado. O uso de outro Suplicante, como o AnyConnect Network Access Manager (NAM) da Cisco, permitirá o uso de wildcard no campo Subject. Outra opção é usar Wildcard Certificate especiais, como Wildcard Plus da DigiCert, que foi projetado para funcionar em dispositivos incompatíveis, incluindo subdomínios específicos no SAN do Certificado.

Para obter mais informações sobre o suporte da Microsoft a Wildcard Certificate, consulte aqui:

http://technet.microsoft.com/en-US/cc730460

Fazendo os Wildcard funcionarem: o método “WildSAN”

Embora a limitação com os Suplicantes da Microsoft possa parecer um impedimento para o uso de Wildcard Certificate, existem maneiras alternativas de construir o Certificado que permitem que ele funcione com todos os dispositivos testados com Secure Access, incluindo os Suplicantes Nativos da Microsoft.

Em vez de construir o Subject para incluir os valores curinga, você pode colocar esses valores curinga no campo SAN. O campo SAN mantém uma extensão projetada para a verificação do nome de domínio, dNSName. Consulte as RFCs 6125 e 2128 para obter mais detalhes e um pequeno trecho da RFC 6125. Esse método costuma ser chamado de método “WildSAN”.

 Trecho da RFC 6125

Suporte ISE para Wildcard Certificate

O ISE adicionou o suporte para Wildcard Certificate na versão 1.2. Antes da versão 1.2, o ISE executava a verificação de todos os Certificados habilitados para HTTPS para garantir que o campo CN corresponda exatamente ao Fully Qualify Domain Name (FQDN) do host. Se os campos não correspondessem, o Certificado não podia ser usado para HTTPS.

Esta restrição existia porque antes da versão 1.2, o ISE usaria esse valor CN para substituir a variável na string do url-redirect AV pair. Para todas as Centralized Web Authentication (CWA), on-boarding, Posture Redirection e muito mais, o valor CN seria usado.

A partir da versão 1.2 do ISE, o comportamento foi modificado para usar o Hostname e o Domain Name como é definido na configuração do ADE-OS do ISE, em vez de confiar no campo CN do Certificado. O seguinte exemplo de saída do CLI está mostrando o Hostname e o Domain Name de um ISE Node.

atw-tme-ise134 / admin # show run | i hostname
hostname atw-tme-ise134
atw-tme-ise134 / admin # show run | i domain
ip domain-name ip securitydemo.net

Construindo o WildSAN Certificate

Como sabemos que devemos inserir o wildcard no campo SAN do Certificado como uma solução alternativa para Suplicantes Nativos da Microsoft, ficamos com duas maneiras principais de construir o Certificado.

Opção 1	Deixe o campo de CN do Subject em branco e insira o wildcard no campo SAN. Embora pareça funcionar perfeitamente bem com a maioria das CAs Privadas, como a CA do Microsoft Active Directory, a maioria das CA Públicas não permitirá a criação de um Certificado sem o valor CN. Este é um exemplo de um Wildcard Certificate válido sem o campo CN:
Opção 2 (prática recomendada pela Cisco)	Use um nome de host genérico para o campo CN do Subject e insira o mesmo nome de host genérico e o wildcard no campo SAN. Este método teve sucesso com a maioria das CAs Públicas testadas, como comodo.com e ssl.com. Com esses CAs Públicos, o tipo de Certificado a ser solicitado é o "Multi-Domain Unified Communications Certificate" (UCC).

Nota: com ambas as opções, o Wildcard Certificate resultante precisa somente ser usado nos ISE Nodes que executam Policy Services (PSN), não é necessário ser usado nos Policy Administration Nodes (PAN) ou Monitoring and Troubleshooting (MnT) Nodes.

Implementando WildSAN Certificates

Agora que revisamos os Wildcard Certificate e seu uso com o ISE, vamos percorrer a criação de um Wildcard Certificate seguindo a melhor prática de usar um Hostname genérico para o campo CN do Subject e inserir o mesmo Hostname genérico e o wildcard no campo SAN.

Gerando o WildSAN Certificate

Existem algumas maneiras de importar um Wildcard Certificate ou Wildcard no ISE versão 1.3. Este procedimento seguirá o que esperamos ser a abordagem mais comum, que é criar o Certificate Signing Request (CSR) dentro da interface administrativa do ISE e enviar esse CSR à CA. A Chave Pública assinada resultante será vinculada ao CSR no ISE.

O par de Chaves Público e Privado final será exportado do primeiro ISE Node e importado nos outros Nodes na implantação.

Criar o Certificate Signing Request (CSR)

Do primeiro ISE Node, navegue até a seção de Certificados do GUI Administrativo. Para Policy Services Nodes (PSN), o caminho será Administration > System > Certificates > Certificate Signing Requests.

1. Clique em Generate Certificate Signing Request (CSR)
2. Em Usage, clique em “Certificate(s) will be used for” e selecione EAP Authentication.
3. Marque a caixa de seleção “Allow Wildcard Certificates”.
4. Para o Certificate Subject, substitua a variável $FQDN$ por um FQDN genérico para os PSNs.
5. Selecione pelo menos dois DNS Names na seção SAN.
   Um dos DNS Name deve corresponder ao valor CN da Etapa 4.
   O outro DNS Name deve ser o wildcard.
   
6. Clique em Generate:
   
7. Clique em Exportar, salve o arquivo .pem resultante em um local em seu sistema local onde seja recuperado facilmente.

Envie o CSR para a CA

Agora que o CSR foi exportado, ele precisa ser enviado a uma CA para assinatura.

1. Abra o CSR (arquivo .pem salvo em seu sistema local) em seu editor de texto favorito e copie todo o texto, inclusive de “----- BEGIN CERTIFICATE REQUEST -----“ até “----- END CERTIFICATE SOLICITAÇÃO-----".
   
2. Cole o conteúdo do CSR na solicitação de Certificado na CA escolhida.
   Este é um exemplo de uso do Microsoft Active Directory Certificate Services:
   Este é um exemplo usando comodo.com como a CA Pública:
   E outro exemplo usando ssl.com como CA Pública:
   
3. Clique em Next, Submit, Continue ou qualquer botão que permita prosseguir com a solicitação de assinatura.
   Uma CA Privada, como a CA do Active Directory, pode apresentar imediatamente uma página de download. CAs Públicos podem exigir muito mais tempo para validar suas permissões e, em seguida, eles enviarão um e-mail para você com um link para baixar o Certificado Assinado do seu portal, ou podem até enviar um arquivo zip contendo o Certificado Assinado e os Certificados Públicos para a CA de assinatura hierarquia.
   Seu trabalho neste ponto é baixar o Certificado Assinado e os Certificados Públicos para todas as CAs na hierarquia de confiança. Então você adicionará esses Certificados Públicos ao Trusted Certification Store ​​do ISE. Por último, você vinculará a solicitação de assinatura de Certificado ao Certificado Assinado que foi enviado a você.
   Pode haver uma opção para aceitar uma cadeia de certificação, não use uma cadeia, se possível. Com a miríade de dispositivos de Endpoint que se conectam ao ISE, é sempre melhor usar Certificados individuais com codificação Base 64 (formato PEM).
4. Baixe o Certificado Assinado resultante do portal ou do e-mail. Sempre use a codificação Base 64 (PEM)
   
   
5. Baixe os Certificados Públicos da CA. Geralmente, isso pode ser feito na página inicial da CA.
   

Importe os Certificados Públicos da CA para o Trusted Certification Store

Você agora instalará o(s) Certificado(s) Público(s) de CA no Trusted Certification Store do ISE. Este store mantém cópias do Certificado Público de qualquer dispositivo que o ISE “confie”.

1. Dentro do ISE GUI, navegue até Administration > System > Certificates.
2. No lado esquerdo, em Certificate Management: clique em Trusted Certificates.
3. Clique Import:
   
4. Browse o Certificado Público.
5. Adicione um Friendly Name ao display
6. Assegure-se de que Trust for authentication within ISE seja selecionada
7. (opcional) Se a CA é uma Public Trusted Root, selecione Trust for client authentication and syslog. Se a CA for uma Public Trusted Root, não marque a caixa de seleção de autenticação do cliente.
8. Clique Submit.
   Repita o processo de importação para cada CA.

Vincule o certificado recém-assinado ao signing request

Agora que o ISE confia na signing CA, é hora de vincular o Certificado Assinado ao CSR dentro do ISE.

Do ISE GUI:

1. Navegue até Administration > System > Certificates:
2. Clique em Certificate Signing Requests.
3. Selecione o Certificate Signing Request.
4. Clique Bind Certificate.
5. Navegue até o signed Certificate.
6. Se wildcard ou WildSAN foram usados, clique em Allow Wildcard Certificates.
7. Clique em Submit.
   O certificado agora está vinculado ao método EAP.
   Agora você vai voltar para o certificado assinado e adicionar as outras funções.
8. Navegue até Administration > System > Certificates > System Certificates.
9. Selecione o signed Certificate e clique em Edit.
10. Na seção “Usage”, selecione Admin e Portal.
    Nota: pxGrid não pode aproveitar Certificados que usam wildcards. Não selecione a função pxGrid se o Certificado usar qualquer wildcard.
    
    
11. Ao selecionar Portal, o menu Certificate Group Tag irá aparecer.
    O ISE 1.3 não permite que as Certificate Group Tag sejam reatribuídas a um novo Certificado. Portanto, selecione Add New...
12. Escolha um nome para a sua Certificate Group Tag.
13. Clique em Save.

Reutilizar o mesmo par de Certificado em outros ISE Nodes

Se você escolher fazê-lo, poderá reutilizar o mesmo Certificado nos outros ISE Nodes. Para saber mais sobre os motivos, consulte a seção intitulada “Exemplo 3: Usando o mesmo Certificado em todos os PSNs”.

Do ISE GUI:

1. Navegue até Administration > System > Certificates > System Certificates.
2. Selecione o novo certificado.
3. Clique em Export.
4. Escolha Export Certificate and Private Key.
5. Forneça uma senha que será usada posteriormente ao importar o par de chaves do certificado
6. Clique em Export.
   
7. O par de chaves é exportado como um arquivo zip, salve esse arquivo zip em um local que possa ser acessado rapidamente.

Agora que o par de chaves foi salvo, você precisará extrair o arquivo zip da Etapa 7, para que os dois arquivos de Certificado possam ser acessados ​​individualmente.

Em cada um dos ISE Node restantes:

1. Navegue até Administration > System > Certificates > System Certificates.
2. Clique Import.
   
3. Selecione o Node correto na lista suspensa “Select Node”.
4. Clique em Browser pelo arquivo de Certificado e localize o arquivo de certificado no arquivo zip com a extensão .pem (por exemplo “isesecuritydemonet.pem”)
5. Clique em Browser pelo arquivo de Chave Privada e localize o arquivo da Chave Privada no arquivo zip com a extensão .pvk (por exemplo “isesecuritydemonet.pvk”)
6. Forneça a senha que você criou ao exportar o par de Certificados.
7. Certifique-se de que a caixa de seleção “Allow Wildcard Certificates” esteja habilitada
8. Escolha o protocolo para este Certificado ser vinculado a: EAP, Admin, Portal (ou todos eles)
9. Clique em Submit.

Artigos adicionais relacionados ao uso, geração e tipos de Certificados

More strict Server Certificate handling in iOS 13 macOS 10.15

• este artigo discute recomendações com o Apple iOS 13 e MacOS 10.15 sobre como ele lida com Certificados e também menciona self-signed Certs (e como eles não são uma boa ideia)