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.
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.
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.
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):
Vamos examinar os itens acima, um de cada vez.
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.
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).
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:
Esta figura descreve o processo criptografado SSL durante a comunicação com o Admin Portal.
Os Certificados são usados com quase todos os métodos EAP possíveis. Os principais exemplos incluem:
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.
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.
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 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
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.
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:
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.
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:
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. |
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):
pxGrid Certificate (todos os ISE Nodes obtêm um se você estiver usando pxGrid
EAP Certificate (todos os PSNs recebem um):
Portal Certificate(s) (um ou mais por PSN
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. |
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:
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".
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:
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.
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.
Alguns benefícios do uso de Wildcard Certificate são:
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.
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:
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:
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
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
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
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. 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.
|
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.
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.
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.
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.
Agora que o CSR foi exportado, ele precisa ser enviado a uma CA para assinatura.
Este é um exemplo usando comodo.com como a CA Pública:
E outro exemplo usando ssl.com como CA Pública:
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”.
Agora que o ISE confia na signing CA, é hora de vincular o Certificado Assinado ao CSR dentro do ISE.
Do ISE GUI:
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:
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:
More strict Server Certificate handling in iOS 13 macOS 10.15
Para adicionar um comentário aqui, tem de ser um utilizador registado. Se já se registou, inicie a sessão. Se ainda não se registou, faça-o e inicie a sessão.
Encontre respostas, faça perguntas e conecte-se com nossa comunidade de especialistas da Cisco de todo o mundo.
Estamos felizes por você estar aqui! Participe de conversas e conecte-se com sua comunidade.