Quando falamos em segurança com o Cisco ISE (Identity Services Engine), estamos falando sobre confiança. E em um ambiente digital, a confiança é estabelecida por certificados digitais, que validam identidades e garantem comunicações criptografadas.
Neste artigo, vamos explorar por que os certificados são essenciais no Cisco ISE, quais tipos existem, como configurá-los corretamente e como evitar os erros mais comuns.
Por que o Cisco ISE depende de certificados?
O Cisco ISE é uma plataforma central de controle de acesso à rede, onde múltiplos elementos se comunicam: endpoints, switches, controladoras wireless, servidores, navegadores, AD, MDM, etc.
Para que todas essas comunicações ocorram com segurança e confiança, é necessário:
- Provar a identidade das partes envolvidas (ex: o servidor ISE precisa provar que é legítimo)
- Garantir que a comunicação seja confidencial (criptografia de dados)
- Assegurar a integridade das mensagens (nada foi alterado no caminho)
Essas três propriedades são garantidas por certificados digitais baseados em criptografia de chave pública (PKI).
Principais tipos de certificados no Cisco ISE
1. Certificado do Servidor ISE (EAP/HTTPS)
Esse é o certificado mais crítico do ISE. Ele é apresentado:
- Durante a autenticação 802.1X com EAP-TLS, PEAP ou EAP-FAST
- Na interface de administração web (https://ise.company.com)
- Em portais como Guest, BYOD e Self-Service
Impactos práticos:
- Se o certificado estiver expirado, o processo de autenticação falha
- Se o nome no certificado não corresponder ao FQDN do servidor, o navegador exibirá erros
- Se o certificado for autoassinado e não confiável, os endpoints rejeitarão a conexão (a não ser que confiem na raiz manualmente)
Dica prática: Use um certificado de CA interna para EAP, e um certificado de CA pública para portais.
A figura abaixo descreve o processo de criptografia quando há comunicação com o portal de Admin.
Já a figura abaixo, apresenta o processo de criptografia para cada possível processo EAP.
- PEAP
- EAP-TLS
- EAP-TTLS
- EAP-FAST
- TEAP
Com métodos EAP tunelados, como PEAP e FAST, o protocolo TLS (Transport Layer Security) é usado para proteger a troca de credenciais. Assim como ao acessar 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 túnel TLS é formado. As credenciais do cliente não são enviadas ao servidor até que esse túnel seja estabelecido, garantindo assim uma troca segura. Em uma implantação de Acesso Seguro, o cliente é um solicitante e o servidor é um nó do ISE Policy Services.
2. Certificados para Portais Web (Guest, BYOD)
Os portais web hospedados pelo ISE (como guest.company.com) exigem certificados válidos e confiáveis para HTTPS.
Recomendado:
- Usar certificados wildcard públicos (
*.company.com) - Configurar um nome DNS válido e resolvível para o portal
- Garantir que o navegador do usuário confie na CA emissora
Evite o uso de certificados autoassinados para portais, pois geram alertas nos navegadores e criam desconfiança no usuário final.
3. Certificados internos para comunicação entre nós ISE
O Cisco ISE pode ser composto por vários nós com funções distintas:
- Admin Node
- Policy Service Node (PSN)
- Monitoring Node
- pxGrid Node
A comunicação entre esses nós é autenticada via certificados. Esses certificados também são usados em:
- Sincronização de dados
- Replicação de logs
- pxGrid (publish/subscribe)
Boas práticas:
- Use certificados válidos com FQDN correto
- Use uma CA corporativa e renove antes da expiração
- Certifique-se de que a cadeia de certificados está completa (raiz + intermediária)
4. Quais valores de certificado devem ser usados em uma implantação do ISE?
Aqui vamos abordar os três modelos recomendados para uso de certificados em um ambiente ISE distribuído.
Modelo 1: Um certificado por nó (multiuso)
- Descrição: Cada nó do ISE (PAN, PSN, MnT) usa um único certificado para múltiplos serviços — administração, EAP, portal e pxGrid.
- Requisitos do certificado:
- CN (Common Name): deve ser o FQDN do nó (ex:
psn1.company.com). - SAN (Subject Alternative Name): incluindo:
- FQDN do próprio nó
- FQDN dos portais (guest, sponsor, mydevices) servidos por esse nó
- Deve incluir extensões EKU (Extended Key Usage) para:
- Server Authentication (todos os nodes)
- Client Authentication (fundamental para uso em pxGrid)
- CN (Common Name): deve ser o FQDN do nó (ex:
- Vantagens: simplifica o gerenciamento, pois utiliza apenas um certificado multiuso por nó.
Modelo 2: Certificados separados por serviço, por nó
- Descrição: Cada serviço (Admin, EAP, Portal, pxGrid) em um nó tem seu próprio certificado.
- Requisitos do certificado:
- Admin: CN = FQDN do nó.
- EAP: CN pode ser o nome do nó ou um nome genérico, como
eap.company.com. - Portal (Sponsor / MyDevices / Guest): CN = nome específico do portal (
sponsor.company.com). - pxGrid: deve ter EKUs para Server e Client Authentication.
- Vantagens: oferece maior isolamento entre serviços, útil para cenários que exigem segregação de funções ou políticas distintas.
Modelo 3: Certificado Único em Todos os PSNs
- Este método utiliza o mesmo par de chaves pública e privada em todos os nós ISE. Geralmente, é usado em ambientes com muitos dispositivos do tipo BYOD. O principal motivo para seguir este modelo é garantir que o mesmo certificado seja usado em todas as PSNs; assim, os dispositivos BYOD já confiarão em qualquer servidor EAP no qual precisem se autenticar.
- Para realizar este método, gere uma solicitação de assinatura de certificado (CSR) em um único nó ISE. Após vincular o certificado assinado à chave privada, exporte o par de chaves resultante e importe-o em todos os outros nós. Configure o certificado único para:
- O CN do Certificado conterá um único FQDN, como
ise.company.com - O Subject Alternate Name do Certificado conterá:
- O Subject CN, como
ise.company.com - FQDN real de cada nó ISE como entradas SAN
- Nome amigável para o Sponsor Portal
- Nome amigável para o Mydevices Portal
- O Subject CN, como
- O CN do Certificado conterá um único FQDN, como
Comparativo entre os modelos
| Modelo | Simplicidade | Escalabilidade | Complexidade de gestão |
|---|---|---|---|
| Certificado multiuso por nó | Alta | Boa | Média |
| Certificados por serviço | Baixa | Alta | Alta |
| Certificado Único em Todos os PSNs | Muito alta | Alta | Baixa |
Autoridades Certificadoras: CA Pública x CA Interna
O certificado do ISE deve ser confiável pelo cliente — isso exige que a CA que o emitiu esteja no repositório de confiança do sistema cliente (Windows, macOS, Android, etc.).
Comparativo:
| Critério | CA Pública | CA Interna |
|---|---|---|
| Reconhecida por padrão | ✅ Sim | ❌ Não (precisa importar a raiz) |
| Ideal para portais web | ✅ Sim | ⚠️ Pode gerar alerta no navegador |
| Ideal para EAP-TLS | ✅ Sim (mas caro) | ✅ Sim (usado via GPO ou MDM) |
| Custo | $ (certificados pagos) | Grátis, mas requer gerenciamento |
O que é um certificado wildcard?
Um certificado wildcard é um tipo de certificado digital SSL/TLS que utiliza um caractere curinga (*) no campo Common Name (CN) ou no Subject Alternative Name (SAN). Ele é utilizado para proteger múltiplos subdomínios dentro de um mesmo domínio principal.
🔹 Exemplo prático:
- CN:
*.empresa.com - Este certificado é válido para:
guest.empresa.comsponsor.empresa.commydevices.empresa.comise1.empresa.comvpn.empresa.com
Mas não é válido para:
sub.guest.empresa.com(nível adicional de subdomínio)empresa.net(domínio diferente)
Uso de certificados wildcard no Cisco ISE
No Cisco ISE, os certificados wildcard são comumente usados para proteger portais web, como:
- Guest Portal
- BYOD Portal
- Self-Service/MyDevices Portal
- Portais de Sponsor
Isso porque esses portais geralmente operam em subdomínios como guest.empresa.com, sponsor.empresa.com, etc.
Vantagens:
- Simplifica o gerenciamento: apenas um certificado cobre todos os portais
- Reduz custos: ao invés de emitir múltiplos certificados por subdomínio
- Flexibilidade: ao adicionar novos portais ou PSNs, o mesmo certificado pode ser reaproveitado
Limitações e recomendações:
- EAP-TLS e certificados wildcard:
Alguns clientes (como Windows e certos supplicants) podem não aceitar certificados wildcard durante a negociação EAP, especialmente em ambientes mais restritivos ou quando o nome do servidor precisa ser validado contra o CN exato. - Uso em pxGrid:
pxGrid exige que o certificado tenha o nome exato do host (FQDN) no CN ou no SAN. Certificados wildcard não são recomendados para pxGrid. - Associação correta no ISE:
O certificado deve ser associado ao serviço de portal web, não ao EAP ou pxGrid.
Resumo — Quando usar certificado wildcard no ISE?
| Caso de uso | Wildcard é recomendado? |
|---|---|
| Portais Web (Guest, BYOD) | ✅ Sim |
| Interface de Admin (HTTPS) | ⚠️ Sim, mas com atenção |
| EAP (PEAP, EAP-TLS) | ⚠️ Depende do supplicant |
| pxGrid | ❌ Não recomendado |
Gerenciamento de Certificados no ISE
Onde gerenciar:
Administration > System > Certificates
Você pode:
- Gerar CSR para envio à CA
- Importar certificados assinados (usando o CSR anterior)
- Importar cadeias completas (Root + Intermediate)
- Associar certificados a serviços específicos, como EAP Authentication, Admin Portal, pxGrid, etc.
- Monitorar a expiração automática com alertas de renovação
Boas práticas:
- Tenha um plano de renovação periódica (scriptado ou manual)
- Use nomes FQDN corretos nos certificados
- Certifique-se de que o campo SAN contenha o nome DNS correto
- Evite reusar o mesmo certificado para múltiplos serviços (a não ser que seja wildcard)
Conclusão
O Cisco ISE é uma solução poderosa e flexível de controle de acesso à rede — mas sua segurança e funcionalidade dependem fortemente de uma infraestrutura de certificados digitais bem planejada.
Ao longo deste artigo, vimos que os certificados não são apenas um requisito técnico, mas um pilar fundamental para garantir identidade, confiança e comunicação segura entre o ISE, os dispositivos de rede, os usuários e os sistemas externos.
Seja na autenticação EAP-TLS, no acesso aos portais Guest/BYOD, na integração via pxGrid, ou na administração web — tudo passa pela confiança em certificados válidos, corretamente emitidos, distribuídos e associados.
A escolha entre um certificado por nó, por serviço ou compartilhado deve ser guiada pelo equilíbrio entre simplicidade operacional, escalabilidade e segurança. O uso de certificados wildcard pode facilitar o gerenciamento de portais web, mas deve ser feito com cuidado em cenários que envolvam autenticação EAP ou integração com pxGrid.
Caso queira entender mais a fundo sobre os certificados no ISE, recomendo a leitura do seguinte material:
Layer 3 Tecno 