- Introdução
- O que são os certificados?
- Como os Certificados são usados no ISE
- Comunicação HTTPS
- Comunicação EAP
- System Certificates (Certificados de Sistema)
- Como implementar os certificados no Cisco ISE?
- Modelo 1 – Certificado Único por Node, Usado para todos os serviços.
- Modelo 2 – Múltiplos certificados por node, e um para cada Serviço.
- Modelo 3 – Único certificado para todos os nodes e funções
- Certificados Wildcard e WildSAN
- Instalação dos Certificados no Cisco ISE
- Instalação do Certificado Admin
- Assinar o Certificado na CA
- Importando o Certificado Root da CA Pública para o Trusted Certificates
- Binding do Certificado Assinado
- Implementando Certificados WildSAN
- Binding do Certificado WildSAN Assinado
- Reutilizando o mesmo Certificado para outros Nodes do ISE
- Conclusão
Introdução
Este artigo tem como objetivo mostrar a importância, os tipos, e a instalação de certificados que existem no Cisco ISE.
Parte deste artigo, é uma tradução e adaptação do artigo How To Implement Digital Certificates in ISE, criado por @Thomas. Thanks Thomas!
O que são os certificados?
Da mesma forma, as pessoas possuem um documento de identificação pessoal, carteira de habilitação para dirigir, passaporte, para provar quem são quando viajam, os elementos de uma rede não são diferentes, devem também ter o certificado para se identificarem e provarem quem são.
Um certificado é um documento eletrônico que identifica um indivíduo, um servidor, um computador, um elemento de rede, uma empresa ou qualquer outra entidade.
Um dos conceitos atrelados aos certificados são as chaves públicas e privadas. As chaves públicas, são aquelas que qualquer pessoa, dispositivo de rede, podem ter acesso. Já a chave privada, deve ser mantida pelo seu proprietário, e não ser compartilhada com ninguém, e é a chave utilizada para descriptografar ou criptografar uma mensagem/tráfego.
Um exemplo prático de chave pública versus chave privada, é quando um usuário tenta estabelecer uma comunicação HTTPS para qualquer site na Internet. Vamos utilizar como exemplo www.cisco.com. Abaixo os passos
- O cliente tenta estabelecer uma conexão com o servidor web;
- O servidor onde está hospedado o site enviará um certificado que será recebido pelo navegador/usuário web. Podemos dizer que este certificado é o certificado (“chave”) público, acessível por qualquer usuário/dispositivo que tentar acessar este site;
- Ao receber o certificado, o navegador/usuário verificará se este certificado é válido e ususe foi assinado por uma Autoridade Certificadora (Certificate Authoriry – CA) confiável;
- Sendo assim, para estabelecer a comunicação o usuário/navegador utilizará a chave pública do servidor para criptografar o tráfego, e reenviará a mensagem de volta;
- Este tráfego só poderá ser descriptografado com a chave privada do servidor, ou vice-versa, o que é criptografado pelo servidor com a chave pública do usuário, só pode ser descriptografado com a chave privada do usuário e, dessa forma você evita que as mensagens sejam interceptadas e/ou modificadas;
Após o servidor descriptografar a mensagem com a chave privada, a conexão SSL será estabelecida, uma comunicação segura.
Vaja na imagem a seguir, o site www.cisco.com possui um certificado seguro, confiável, assinado por uma organização confiável.
Diferente do Cisco ISE, ao tentar acessar o dashboard pela primeira vez utilizando o endereço IP 192.168.20.100, aparecerá a mensagem de que o site não é confiável, pois ainda não possui um certificado assinado por uma CA, uma organização confiável. O presente certificado é o que foi gerado pelo próprio servidor durante a instalação.
Para verificar este certificado, faça login no dashboard do Cisco ISE e vá no menu esquerdo do Cisco ISE > Administration > System > Certificates > Certificate Management > System Certificates.
Como os Certificados são usados no ISE
Os certificados são utilizados para identificar os nodes do Cisco ISE para os dispositivos na rede, como também para que haja uma comunicação segura entre eles. O certificado ele é utilizado para todas as comunicações HTTPS como também para a comunicação EAP (Extensible Authentication Protocol).
Comunicação HTTPS
Para a comunicação HTTPS é para criar uma sessão HTTP encriptada com SSL, o que inclui:
- Portal Administrativo (Portal Administrative)
- Portal de Sponsor e Guest (Sponsor Portal and Guest Portal)
- BYOD (bring your own device) e Client Provisioning Portal (CPP)
- Portal MyDevices
- Portal MDM (Mobile Device Management)
O parâmetro para a comunicação HTTPS, resumidamente é o mesmo processo que explicado anteriormente.
Comunicação EAP
Para a comunicação EAP, o certificado pode ser utilizado para a autenticação de usuários e dispositivos junto ao Cisco ISE, utilizando os métodos, EAP-TLS, PEAP, TEAP, EAP-FAST, EAP-TTLS.
Com os modos de tunelamento PEAP, TEAP, EAP-TTLS, o Transport Layer Security (TLS) é usado para proteger as credenciais trocadas no momento da autenticação, entre o ISE e os usuários.
Ao primeiro momento que o dispositivo tentar se conectar na rede, haverá a troca de certificados, no mesmo modo que acontece na comunicação HTTPS, como explicado anteriormente. Se o certificado é confiável, o túnel TLS é estabelecido. Depois de o túnel TLS ser estabelecido, então as credenciais do usuário são enviadas para o servidor, estabelecendo uma comunicação segura. Neste caso, o dispositivo/usuário final é o suplicante, e o servidor a PSN (Policy Service Node) ISE, traduzindo para o português, O Servidor de Políticas de Serviço.
System Certificates (Certificados de Sistema)
Os certificados no Cisco ISE, podem ser utilizados para uma ou mais funções. Cada função desempenha um propósito diferente, explicado abaixo cada uma delas:
- Admin: é utilizada para a comunicação segura sobre a porta 443 (Admin GUI), como também para replicação, ou uso de APIs sobre a porta 443.
- Portal: este é utilizado para a comunicação HTTP segura para os portais CWA (Centralized Web Authentication), Portal Guest, Portal BYOD, Client Provisioning, e portal Native Supplicant Provisioning, ou outro portal.
- EAP: este é especificamento para a autenticação de clientes utilizando autenticação 802.1x. O certificado pode ser usado para todas os métods de autenticação EAP, como EAP-TLS, PEAP, PEAP-FAST, EAP-TTLS.
- RADIUS DTLS: como RADIUS DTLS, o certificado é usado para uma conexão DTLS (TLS sobre UDP), para encriptar o tráfego entre o Dispositivo de Rede (Network Access Device), comumente conhecido como NAD, e o Cisco ISE. Para o funcionamento dessa funcionalidade o NAD deve ser capaz de operar com criptografia DTLS.
- SAML: o certificado do servidor é usado para a comunicação segura com o SAML Identity Provider (IdP). O certificado para SAML não pode ser utilizado para outro service como Admin, Portal, ou autenticação EAP. Ele deve ser específico para SAML.
- ISE Messaging Service: é utilizado para criar o log dos dados do ISE, ao invés de utilizar o protocolo Syslog. Disponível a partir da versão 2.6.
- PxGrid: é utilizado para o serviço de PxGrid no ISE.
Como implementar os certificados no Cisco ISE?
A implementação dos certificados é uma das fases que deve ser bem planejada, visto que afetará na gestão futura, como também influenciará no custo, dependendo da quantidade de certificados, e o modelo aplicado.
Modelo 1 – Certificado Único por Node, Usado para todos os serviços.
Neste modelo é utilizado um certificado para cada node do ISE, PSN, PAN, e MnT, e este certificado será utilizado para todos os serviços, Admin, Portal, EAP, PxGrid.
Pro’s:
- Como melhor prática de segurança, um único certificado para cada node;
Con’s
- Os endpoints terão de aceitar os certificados de cada PSN para a comunicação EAP.
- Terá de fazer a renovação dos certificados individualmente. Se for um ambiente com muitos nodes de ISE, isso demandará um alto tempo.
O mesmo certificado que é usado para admin, autenticação EAP, será exposto para os portais de BYOD, Guest. Isso acaba se tornando um risco.
Modelo 2 – Múltiplos certificados por node, e um para cada Serviço.
Este método utiliza um certificado para cada função e node. Para atingir este objetivo cada certificado deve ser configurado como a seguir:
- Certificado Admin – todos os nodes do ISE precisa de um.
- O campo Subject CN do Certificado deve conter a FQDN do node.
- Não é necessário o Subject Alternative Name.
- Deve ser assinado por uma CA interna, e não pública.
- Pode ser autoassinado, porém não recomendado.
- Certificado PxGrid – todos os nodes do ISE precisa de um caso tenha o PxGrid no ambiente.
- O campo Subject CN do Certificado deve conter a FQDN do node.
- Não é necessário o Subject Alternative Name.
- Deve ser assinado por uma CA pública.
- Pode ser assinado por uma CA interna (não-pública).
- Pode ser autoassinado, embora não recomendado.
- Deve possuir EKUs de autenticação de cliente e servidor.
- Certificado EAP – Todas as PSNs precisa de um.
- O campo Subject CN do Certificado deve conter a FQDN do node.
- Não é necessário o Subject Alternative Name.
- Deve ser assinado por uma CA pública.
- Certificado de Portal – um ou mais certificados por PSN, dependendo da quantidade de portais.
- O campo Subject CN do Certificado deve conter a FQDN do node.
- Deve ser assinado por uma CA pública.
- O campo Subject Alternative Name conterá:
- A FQDN do ISE node.
- Um nome para cada portal protegido pelo certificado.
- A FQDN para o Portal MyDevices.
- A FQDN para o Portal Sponsor.
Num cálculo simples, podemos ver no exemplo da figura abaixo que foram um total de 7 certificados. Este que é apenas uma demonstração. Quanto maior a quantidade nodes, maior a quantidade de certificados.
Pro’s
- Segue as melhores práticas de segurança. Um certificado para cada node.
Con’s
- Muitos certificados para gerenciar. Em determinados casos, mais de um certificado por node.
- Pode se tornar caro na implementação, caso esteja utilizando uma certificadora externa.
- Os dispositivos da rede, terão de aceitar um certificado de cada PSN para a comunicação EAP, e isso impactará a autenticação, caso um dispositivo autentique-se em PSNs diferentes.
Modelo 3 – Único certificado para todos os nodes e funções
Este método utiliza a mesma chave pública e privada para todos os nodes do ISE. É geralmente utilizado para ambientes onde possui uma grande quantidade de devices BYOD. A principal razão de seguir este modelo é assegurar que o mesmo certificado é utilizado em todas as PSNs, então os devices BYOD já terá uma relação de confiança com qualquer servidor EAP em que deva se autenticar.
Para isso, é necessário gerar um Certificate Signing Request (CSR) – Solicitação de Assinatura de Certificado, em apenas um dos nodes do ISE. Depois disso, vincular/fazer o binding do certificado assinado para a chave privada, exportar o resultado da par de chaves e importar este resultado para todos os outros nodes. O certificado único pode ser configurado para:
- Subject CN do Certificado terá uma única FQDN, como exemplo da imagem ise.securitydemo.net.
- O Subject Alternative Name do certificado, conterá:
- O subject CN, como ise.securitydemo.net
- Todos as FQDNs de cada node do ISE nas entradas de SAN
- Um nome para cada portal, seja Guest, Sponsor, Mydevices.
- O certificado precisa de EKUs de autenticação de cliente e servidor.
Pro’s
- Os devices BYOD não precisará aceitar manualmente um certificado para cada autenticação EAP.
- Gerenciamento fácil
- O custo para implementação é relativamente baixo.
Con’s
- As práticas de segurança de único certificado por identidade são quebradas. Cada node do ISE parecem ser idênticos.
- Uso de único certificado para Admin e para as funções de usuários/dispositivos finais.
- Caso seja necessário adicionar um node PSN no ambiente, o certificado de todos os outros nodes deverão ser atualizados para incluir a nova FQDN.
Não necessariamente o administrador precisa escolher um único modelo. Para cada um existem vantagens e desvantagens, e eles podem ser adaptados conforme a necessidade e realidade de cada ambiente, e pode também fazer uma mistura, como por exemplo, utilizar o modelo 2 para determinadas situações e o 3 para outras.
Certificados Wildcard e WildSAN
Um certificado Wildcard, é aquele que utiliza uma notação Wildcard, um asterisco e um ponto antes do nome do domínio, e permite que o certificado seja compartilhado entre vários hosts em uma organização. Como exemplo do valor CN do certificado que será utilizado no lab, é que no Subject Name do certificado Wildcard ficará da seguinte forma: *.labise.com, e sendo assim certificado poderá assegurar qualquer dispositivo que obtenha no nome de DNS labise.com.
- ISE01.labise.com
- ISE02.labise.com
O uso do certificado Wildcard traz alguns benefícios como:
- Economia com custo, visto que criar uma estrutura de certificados com um provedor terceiro é bem custoso.
- Facilidade para operacionalizar a implantação e gerenciamento dos certificados.
- Reduz os erros de autenticação.
- Simplifica a configuração dos suplicantes. Por exemplo, o suplicante do Microsoft Windows com PEAP-MSCHAPv2 e certificado de confiança do servidor ativado, geralmente requer a especificação de cada certificado de servidor para confiar, ou o usuário pode ser solicitado a confiar no certificado individual de cada PSN quando o cliente se conectar usando em uma PSN diferente. Com certificados Wildcard, um único certificado de servidor pode ser confiável em vez de certificados individuais de cada PSN.
O uso do Wildcard traz também algumas desvantagens, como:
- Perda de auditória e não repúdio
- Maior exposição da chave privada
- Não é tão comum ou tão bem compreendido pelos administradores
Apesar das desvantagens, o fator custo operacional é bem relevante no momento de criar uma política para adoção do modelo de certificado a ser utilizado.
Há também algumas desvantagens com o certificado Wildcard que é para a autenticação de dispositivos com o sistema operacional Windows, vide que não aceitam este modelo de certificado. Sendo assim, há uma possibilidade de resolver este problema com o uso do método WildSAN.
WildSAN
O WildSAN que provém, Wild de Wildcard, e o SAN de Subject Alternative Name, é uma alternativa para permitir o uso de Wildcard para suplicantes nativos Microsoft.
Como definido na RFC 6125 e 2128, ao invés de criar um certificado com o subject Commom Name, o valor de Wildcard deve ser inserido no campo Subject Alternative Name (SAN). Veremos exemplo disso na fase do lab. No momento da autenticação o nome a ser verificado será o DNSName.
Instalação dos Certificados no Cisco ISE
Agora que foi possível entender a teoria por trás dos certificados, vamos praticar como é feita a instalação dos certificados no Cisco ISE.
Para este lab, a CA (Certificate Authority) utilizado foi o Windows Server.
Será realizado duas demonstrações.
- Instalação do certificado para o serviço Admin, utilizando o Modelo 2.
- Instalação do certificado para o serviço EAP, utilizando o WildCard/WildSAN.
Instalação do Certificado Admin
Anteriormente foi mencionado que o certificado Admin é utilizado para a comunicação segura das portas 443 (interface GUI), como também para replicação entre os nodes ou uso de API na porta 443.
Recapitulando que inicialmente na tentativa de acessar o ISE em 192.168.20.100 via browser, era emitida a mensagem de site não confiável.
Além de acessar o dashboard do ISE via endereço IP, foi criada uma entrada DNS ISE01.labise.com no servidor DNS.
Com essa configuração, é possível acessar o ISE através do nome ao invés do endereço IP, porém ocorre o mesmo erro, de certificado não confiável.
Uma das razões para a instalação do certificado Admin, será para resolver este problema.
Como primeiro passo para a instalação do certificado, deve ser gerado o Certificate Signing Request (CSR). Para isso vá no dashboard do ISE em Administration > System > Certificates > Certificate Management > Certificate Signing Requests e clique em Generate Certificate Signing Requests (CSR), e preencha as informações conforme abaixo.
- Como está sendo gerado um certificado individual para este node, veja que a opção de Wildcard não foi marcada.
- No Common Name (CN), foi adicionado a FQDN utilizada para este node, o mesmo nome sendo utilizado para DNS.
- Em Subject Alternative Name (SAN), foram incluídas mais duas informações, o DNS Name e o endereço IP deste node. Isso somente para trazer uma camada a mais de proteção.
Após essas informações preenchidas, clique no botão Generate e em seguida em Export.
Com isso, será gerada a chave privada do Node ISE01. Salve o arquivo de extensão .pem em um local seguro. Este arquivo deve ficar de posse do administrador do ambiente, e o aconselhável é não compartilhar com outras pessoas.
Assinar o Certificado na CA
Com o arquivo exportado, este é o momento de assinar/gerar o certificado na CA. Neste exemplo, é utilizado a CA do Windows Server.
Para acessar a CA do Windows Server, digite no navegador https://ip_do_server/certsrv.
- Clique em Request a Certificate;
- Advanced certificate request/
- Abra o arquivo .pem exportado anteriormente, e copie e cole toda a informação do arquivo dentro do campo Base-64, e em Certificate Template selecione a opção Web Sever.
- Logo em seguida, clique em Submit, marque a opção Base 64 encoded, e clique em Download certificate. Salve o arquivo para uso futuro.
Importando o Certificado Root da CA Pública para o Trusted Certificates
Após realizar o download do certificado assinado pela CA, antes de fazer o bind (vincular) o certificado no ISE, é necessário importar o Certificado Root.
O certificado Root, é o certificado da CA, entidade que assinou o certificado do ISE, e este precisa ser instalado no ISE em Trusted Certificates, ou seja, em Certificados Confiáveis. O objetivo de instalar este certificado é devido o certificado do ISE ter sido assinado por uma outra entidade. Então, sempre que for instalar um certificado que tenha sido assinado por uma certificadora externa, o Root deve ser instalado em Trusted Certificates.
Para realizar este passo, volte ao https://ip_do_server/certsrv, lembrando que neste lab a CA é o Windows Server.
Vá em Download a CA certificate, certificate chain, or CRL.
Selecione Base 64 e clique em Download CA Certificate.
Após o download do certificado, no dashboard do ISE vá em Administrator > System > Certificates > Certificate Management > Trusted Certificates, clique em Import, e selecione o certificado Root que você fez o download da CA, dê um nome ao certificado, selecione as opções conforme abaixo, e clique em Submit.
Após isso, qualquer certificado que seja assinado pela CA do certificado Root, pode ser importado no Cisco ISE, e o ISE passa a entender a entender a CA e os certificados assinados como confiáveis..
Nota: Todas as opções de Trust foram selecionadas, pois o certificado Root dessa CA, será utilizado também para autenticação de endpoint, como também para a integração de outros Serviços Cisco dentro do lab.
Binding do Certificado Assinado
Após o download do certificado, deve ser feito o Bind (vincular) com a chave privada gerada inicialmente.
Na mesma tela após gerar o CSR, selecione o ISE01#Admin e clique em Bind Certificate.
Selecione o arquivo previamente exportado da CA, e dê um nome para este certificado. Veja que o único uso é para a função de Admin, e em seguida clique em Submit.
Nota: se um novo node for inserido no ambiente, o mesmo processo de certificado do serviço Admin deve ser realizado.
Assim que clicar no botão Submit, acontecerá o reload do Cisco ISE, para que o certificado seja instalado.
Lembre-se que este certificado foi utilizado somente para Admin. Para as outras funcionalidades, será demonstrada a seguir.
Após o reinício do node, navegue até a aba de certificados e observe que o existe agora um certificado dedicado para Admin.
Note também que agora quando tentar acessar a GUI do Cisco ISE, o certificado é mostrado como conexão segura, como também no momento de outros elementos da rede tentar estabelecer conexão 443 com este node, não haverá problemas de certificados.
Implementando Certificados WildSAN
Neste lab a implementação do certificado WildSAN será utilizada para as funções EAP Authentication e para Portal.
O mesmo processo para gerar o CSR deverá ser seguido como no exemplo acima, porém agora com diferença no tipo de serviço.
Vá em Administration > System > Certificates > Certificate Management > Certificate Signing Requests e clique em Generate Certificate Signing Requests (CSR), preencha as informações e depois clique em Generate, e em Export.
Observe que agora como está sendo gerado um certificado WildCard/WildSAN, a opção Multi-Use deve ser selecionada, como também ser marcado a opção Allow Wildcard Certificates. Isso permitirá que o certificado seja utilizado para diferentes funções como também para diferentes nodes.
É necessário também que o nome DNS que for utilizado em CN seja adicionado como DNS Name, e depois mais um DNS Name, neste caso com o nome do domínio, seja inserido precedido de (*.). Isso é o que cria o Certificado WildCard.
Após exportar o certificado, realize o passo Assinar o Certificado na CA, e faça o download do novo certificado WildSAN.
Binding do Certificado WildSAN Assinado
O processo de vincular/binding deste certificado é similar o anterior, porém observe que existirá mais funcionalidades disponíveis para o que este certificado será utilizado.
Será selecionado EAP Authentication e Portal. A função Admin já foi realizada no Certificado anterior.
Após preencher essas informações, clique em Submit.
A mensagem acima é mostrada no momento que clicar em Submit, visto que o certificado autogerado no momento da instalação do ISE, está sendo utilizado para EAP e portal. Clique em Yes e prossiga para a importação.
Se navegar até System Certificates, observe que agora existe um novo certificado para EAP e Portal.
Reutilizando o mesmo Certificado para outros Nodes do ISE
No caso do Certificado WildSAN, ele é criado para ser utilizado em outros nodes, sem a necessidade de criar um certificado novo para cada node. Neste caso, o WildSAN só poderá ser utilizado para EAP Authentication e Portal, que foram os serviços selecionados no momento de realizar o Binding.
- Para o Reuso do mesmo certificado em outras PSNs, vá até Administration > System > Certificates > Certificate Management > System Certificates;
- Selecione o certificado que deseja exportar;
- Clique em Export;
- Selecione Export Certificate and Private Key;
- Crie uma senha para a Private Key. Essa senha será utilizada para importar o certificado no novo node.
- Clique em Export.
- O arquivo é exportado no formato .zip.
Com este arquivo .zip gerado, extraia-o do formato .zip, e o deixe salvo.
- Quando for instalado um novo node na rede, na mesma guia de System Certificates, clique em Import.
- Em Select Node, selecione um dos nós da Lista. Neste caso está aparecendo somente o node ISE01, pois há somente um node neste ISE Cube, mas caso haja um segundo node de ISE, ele será listado.
- Do .zip que foi extraído, para Certificate File escolha o arquivo .pem, e em Private Key File o arquivo .pvk.
- Digite a senha previamente criada quando exportado o arquivo.
- Dê um nome para o Certificado. Interessante utilizar o mesmo nome que já foi utilizado para o ISE01.
- Selecione as funções para uso do certificado, que é no caso EAP e Portal.
- Selecione o Portal Group Tag previamente criado, e clique em Submit.
Clique em Submit, este certificado será instalado no novo node.
Conclusão
Foi demonstrado neste lab, dois modelos de instalar certificados.
- Para a função de Admin, o modelo de um certificado por node
- Para as funções EAP Authentication e Portal, foi utilizado o modelo de WildSAN.
Como mencionado anteriormente, para ambos os modelos existem pros e cons. O que é importante avaliar no momento da instalação é o que fica mais viável para a realidade do ambiente e do cliente.
Espero que tenham aproveitado a leitura.
Jonas Resende.
