Este documento descreve como solicitar, instalar, confiar e renovar determinados tipos de certificados no software Cisco ASA gerenciado com o ASDM.
As informações neste documento são baseadas nestas versões de software e hardware:
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Os tipos de certificados que este documento aborda são:
O protocolo SSL (Secure Socket Layer), o protocolo TLS (Transport Layer Security) e o protocolo IKEv2 rfc7296 para autenticação EAP exigem que o servidor SSL/TLS/IKEv2 forneça ao cliente um certificado de servidor para que ele execute a autenticação do servidor. Para essa finalidade, é recomendável usar CAs de terceiros confiáveis para emitir certificados SSL para o ASA.
A Cisco não recomenda o uso de um certificado autoassinado, devido à possibilidade de um usuário configurar inadvertidamente um navegador para confiar em um certificado de um servidor invasor. Os usuários podem encontrar avisos de segurança ao se conectarem ao gateway seguro, o que pode interromper seu fluxo de trabalho.
Quando um certificado CA confiável é instalado, ele pode ser usado para autenticar diferentes tipos de conexões VPN usando a autenticação de certificado. Ele é controlado com o comando validation-usage trustpoint (Configuração > Gerenciamento de dispositivo > Gerenciamento de certificado >Certificados da CA >Adicionar -> Mais opções.. > Avançado > selecione as opções de Uso de validação).
Os tipos de uso de validação são:
ipsec-client: Valida conexões de cliente IPsec.ssl-client: Valida conexões de cliente SSL.ssl-server: Valida certificados de servidor SSL.
Navigate to:
Configuration > Device Management > Certificate Management > CA Certificates.
a) Select a wanted trustpoint and click Edit.
b) Navigate to Advanced and uncheck all Validation Usage options.
trustpoint public-root-ca no validation-usage

Por padrão, um certificado CA confiável pode ser usado para autenticar o par IPSEC VPN ou o usuário de VPN de acesso remoto que se conecta a qualquer grupo de túneis. É necessário conceber uma autorização adequada.
Use mapas de grupos de túneis e certificados para garantir que somente os certificados autorizados sejam usados para grupos de túneis específicos. Defina uma regra de mapa de grupo de túneis padrão que aponte para um grupo de túneis sem acesso para restringir o acesso não autorizado.
A autenticação de certificado só é permitida para:
Os usuários com outros certificados são atribuídos a no_access tunnel-group por padrão, graças ao comando tunnel-group-map default-group no_access. As regras de mapa de certificados têm prioridade sobre group-url graças ao comando tunnel-group-map enable rules. Conhecer group-url não ajuda a ignorar as Regras de Mapa de Certificados.
Navigate to:
Configuration > Remote Access VPN > Network (Client) Access > Group Policies > Add > General > More Options
a) Uncheck Inherit next to Simultaneous Logins and set the value 0.
b) Uncheck Inherit next to Banner and set a wanted massage, for example NO ACCESS GROUP POLICY.
group-policy no_access_gp internal
group-policy no_access_gp attributes
banner value NO ACCESS GROUP POLICY
vpn-simultaneous-logins 0
Logins simultâneos definidos como 0
2. Configure grupos de túneis para usuários e grupo de túneis impedindo o acesso à VPN.
Navigate to:
Configuration > Remote Access VPN > Network (Client) Access > Secure Client Connection Profiles. Click Add and configure:
a) Authentication method as Certificate.
b) Group Policy - for the no_access tunnel group use no_access_gp where simultaneous logins is set to 0.
tunnel-group mgmt-tunnel type remote-access tunnel-group mgmt-tunnel general-attributes address-pool vpn_pool default-group-policy mgmt-tunnel tunnel-group mgmt-tunnel webvpn-attributes authentication certificate ! tunnel-group users_access type remote-access tunnel-group users_access general-attributes default-group-policy user_access_gp address-pool vpn_pool tunnel-group users_access webvpn-attributes authentication certificate ! tunnel-group no_access type remote-access tunnel-group no_access general-attributes default-group-policy no_access_gp address-pool vpn_pool tunnel-group no_access webvpn-attributes authentication certificate
Nenhum grupo de túnel de acesso
3. Crie mapas de certificado para usuários e use os mapas de certificado para mapeamento de grupo de túneis:
Navigate to: Configuration > Remote Access VPN > Advanced > Certificate to Secure Client and Clientless SSL VPN Connection Profile Maps.
a) Click Add to configure Certificate to Connection Profile Maps.
b) Select New and configure a certificate group map name, for example mgmt_tunnel_map or users_access_map.
c) Select a corresponding connection profile/tunnel group from the drop-down menu at Mapped to Connection Profile.
d) Click Add to configure Mapping Criteria.
e) Select: Field: Subject, Component: Organizational Unit (OU), Operator: Equals, Value: machines or users.
d) Select: Field: Issuer, Component: Common Name (CN), Operator: Equals, Value: example.com.
crypto ca certificate map mgmt_tunnel_map 10
issuer-name attr cn eq example.com
subject-name attr ou eq machines
crypto ca certificate map users_access_map 10
issuer-name attr cn eq example.com
subject-name attr ou eq users
!
webvpn
(...)
certificate-group-map mgmt_tunnel_map 10 mgmt-tunnel
certificate-group-map users_access_map 10 users_access
Certificado para Mapas de Perfil de Conexão de Cliente Seguro
4. Habilite os mapas tunnel-group e configure um grupo de túneis padrão para negar o acesso se um certificado do usuário não corresponder a nenhum outro mapa de certificado.
Navigate to: Configuration > Remote Access VPN > Network (Client) Access > Advanced > IPsec > Certificate to Connection Profile Maps > Policy.
a) Check Use the configure rules to match a certificate to a Connection Profile.
b) Check Default to Connection Profile and select from the drop-down menu the no-access connection profile/tunnel group.
tunnel-group-map enable rules tunnel-group-map default-group no_access
Habilitar Mapas de Certificados e Perfil de Conexão PadrãoPara obter instruções de configuração mais detalhadas, consulte a documentação da Cisco:
Um certificado pode ser solicitado de uma Autoridade de Certificação (CA) e instalado em um ASA de duas maneiras:
Um CSR é criado no dispositivo que precisa de um certificado de identidade, use um par de chaves criado no dispositivo.
Um CSR contém:
O CSR é passado para a Autoridade de Certificação (CA) para assinatura no formulário PKCS#10.
O certificado assinado é retornado da CA em um formulário PEM.








| Atributo | Descrição |
|---|---|
| CN | O nome pelo qual o firewall pode ser acessado (geralmente o nome de domínio totalmente qualificado, por exemplo, vpn.example.com). |
| OU | O nome do seu departamento na organização. |
| O | O nome legalmente registrado da sua organização/empresa. |
| C | Código do país (código de 2 letras sem pontuação). |
| ST | O estado no qual sua organização está localizada. |
| I | A cidade em que sua organização está localizada. |
| EA | Endereço de e-mail |





As etapas de instalação pressupõem que a CA assinou o CSR e forneceu um certificado de identidade codificado PEM (.pem,.cer, .crt) e um pacote de certificado CA.






O ASA deve ser configurado para usar o novo Certificado de Identidade para sessões WebVPN que terminam na interface especificada.


Agora o novo Certificado de Identidade está em uso.
O arquivo PKCS12 (formato .p12 ou .pfx) contém certificado de identidade, par de chaves e certificado(s) de autoridade de certificação. Ele é criado pela CA, no caso de um certificado curinga, ou exportado de um dispositivo diferente. É um arquivo binário e não pode ser exibido com um editor de texto.




O ASA deve ser configurado para usar o novo Certificado de Identidade para sessões WebVPN que terminam na interface especificada.


A renovação do certificado CSR registrado requer que você crie e registre um novo ponto de confiança. Ele deve ter um nome diferente (por exemplo, um nome antigo com o sufixo do ano de inscrição). Ele pode usar os mesmos parâmetros e Par de chaves que o certificado antigo, ou pode usar diferentes.







| Atributo |
Descrição |
|---|---|
| CN |
O nome pelo qual o firewall pode ser acessado (geralmente o nome de domínio totalmente qualificado, por exemplo, vpn.example.com). |
| OU |
O nome do seu departamento na organização. |
| O |
O nome legalmente registrado da sua organização/empresa. |
| C |
Código do país (código de 2 letras sem pontuação) |
| ST |
O estado no qual sua organização está localizada. |
| I |
A cidade em que sua organização está localizada. |
| EA |
Endereço de e-mail |





As etapas de instalação pressupõem que a CA assinou o CSR e forneceu um novo certificado de identidade e um pacote de certificado de CA codificados em PEM (.pem, .cer, .crt).
O certificado CA que assinou o Certificado de Identidade pode ser instalado no Ponto de Confiança criado para o Certificado de Identidade. Se o Certificado de Identidade for assinado por uma autoridade de certificação intermediária, esse certificado de autoridade de certificação poderá ser instalado no Ponto de Confiança do Certificado de Identidade. Todos os certificados de autoridade de certificação upstream na hierarquia e podem ser instalados em pontos confiáveis de autoridade de certificação separados.



Neste exemplo, o novo certificado é assinado com o mesmo certificado CA que o antigo. O mesmo certificado CA está associado a dois pontos confiáveis.




O ASA deve ser configurado para usar o novo Certificado de Identidade para sessões WebVPN que terminam na interface especificada.


A renovação de certificado registrado no PKCS12 requer que você crie e registre um novo ponto confiável. Ele deve ter um nome diferente (por exemplo, um nome antigo com o sufixo do ano de inscrição).
O arquivo PKCS12 (formato .p12 ou .pfx) contém certificado de identidade, par de chaves e certificado(s) de autoridade de certificação. Ele é criado pela CA, por exemplo, no caso de um certificado curinga, ou exportado de um dispositivo diferente. É um arquivo binário e não pode ser exibido com o editor de texto.
O Certificado de identidade, o(s) certificado(s) de CA e o par de chaves devem ser agrupados em um único arquivo PKCS12.




O ASA deve ser configurado para usar o novo Certificado de Identidade para sessões WebVPN que termina na interface especificada.


Siga estas etapas para verificar a instalação bem-sucedida do(s) Certificado(s) de fornecedor de terceiros e o uso para conexões VPN SSL.

Se uma instalação de certificado SSL falhar, este comando de depuração é coletado na CLI para coletar informações de diagnóstico.
P. O que é um PKCS12?
R. Na criptografia, o PKCS12 define um formato de arquivo criado para armazenar muitos objetos de criptografia como um único arquivo. É comumente usado para agrupar uma chave privada com seu certificado X.509 ou para agrupar todos os membros de uma cadeia de confiança.
P. O que é CSR?
R. Nos sistemas de infraestrutura de chave pública (PKI), um pedido de assinatura de certificado (também CSR ou pedido de certificação) é uma mensagem enviada de um requerente a uma autoridade de registro da infraestrutura de chave pública para solicitar um certificado de identidade digital. Ele geralmente contém a chave pública para a qual o certificado pode ser emitido, informações que são usadas para identificar o certificado assinado (como um nome de domínio no Assunto) e proteção de integridade (por exemplo, uma assinatura digital).
P. Onde está a senha do PKCS12?
R. Quando certificados e pares de chaves são exportados para um arquivo PKCS12, a senha é fornecida no comando export. Para importar um arquivo PKCS12, a senha deve ser fornecida pelo proprietário do servidor de CA ou por uma pessoa que exportou o PKCS12 de outro dispositivo.
P. Qual é a diferença entre a raiz e a identidade?
R. Na criptografia e na segurança do computador, um certificado raiz é um certificado de chave pública que identifica uma autoridade de certificação raiz (CA). Os certificados raiz são autoassinados (e é possível que um certificado tenha vários caminhos confiáveis, por exemplo, se o certificado foi emitido por uma raiz que foi assinada entre si) e formam a base de uma infraestrutura de chave pública (PKI) baseada em X.509. Um certificado de chave pública, também conhecido como certificado digital ou certificado de identidade, é um documento eletrônico usado para provar a propriedade de uma chave pública. O certificado inclui informações sobre a chave, informações sobre a identidade do seu proprietário (denominada entidade) e a assinatura digital de uma entidade que verificou o conteúdo dos certificados (denominada emitente). Se a assinatura for válida e o software que examina o certificado confiar no emissor, ele poderá usar essa chave para se comunicar com segurança com o requerente dos certificados.
P. Instalei o certificado, por que ele não funciona?
R. Isso pode ser devido a muitas razões, por exemplo:
1. O certificado e o ponto confiável estão configurados, no entanto, eles não foram associados ao processo que o utiliza. Por exemplo, o ponto confiável usado não está vinculado à interface externa que termina as conexões de clientes Cisco Secure Access AnyConnect VPN.
2. Um arquivo PKCS12 está instalado, mas apresenta erros devido à ausência do certificado intermediário CA no arquivo PKCS12. Os clientes que têm o certificado intermediário de autoridade de certificação como confiável, mas não têm o certificado raiz de autoridade de certificação como confiável, e não podem verificar toda a cadeia de certificados e relatar o certificado de identidade do servidor como não confiável.
3. Um certificado preenchido com atributos incorretos pode causar falha na instalação ou erros no lado do cliente. Por exemplo, determinados atributos são codificados com o formato incorreto. Outro motivo é que o Certificado de Identidade não tem o SAN (Nome Alternativo da Entidade) ou o nome de domínio usado para acessar o servidor não está presente como uma SAN.
P. A instalação de um novo certificado requer uma janela de manutenção ou causa tempo de inatividade?
R. A instalação de um novo certificado (identidade ou CA) não é intrusiva e não causa tempo de inatividade ou requer uma janela de manutenção. Permitir que um novo certificado seja usado para um serviço que existe é uma alteração e requer uma janela de solicitação/manutenção de alteração.
P. É possível adicionar ou alterar um certificado para desconectar os usuários conectados?
R. Não, os usuários conectados no momento permanecem conectados. O certificado é usado no estabelecimento da conexão. Quando os usuários se reconectarem, o novo certificado será usado.
P. Como posso criar um CSR com um curinga? Ou um nome alternativo para o assunto (SAN)?
R. Atualmente, o ASA/FTD não pode criar um CSR com um curinga; no entanto, esse processo pode ser feito com o OpenSSL. Para gerar a chave CSR e ID, você pode executar os comandos:
openssl genrsa -out id.key 2048
openssl req -out id.csr -key id.key -new
Quando um ponto confiável é configurado com um atributo Fully Qualified Domain Name (FQDN), o CSR criado pelo ASA/FTD contém a SAN com esse valor. Mais atributos de SAN podem ser adicionados pela CA quando ela assina o CSR, ou o CSR pode ser criado com o OpenSSL
P. A substituição de um certificado entra em vigor imediatamente?
R. O novo certificado de identidade do servidor é usado somente para novas conexões. Um novo certificado está pronto para ser usado imediatamente após a alteração, mas é usado com novas conexões.
P. Como posso verificar se a instalação funcionou?
R. O comando CLI para verificar: show crypto ca cert <nome_do_ponto_de_confiança>
P. Como faço para gerar PKCS12 a partir do Certificado de Identidade, certificado CA e chave privada?
A. O PKCS12 pode ser criado com o OpenSSL, com o comando:
openssl pkcs12 -export -out p12.pfx -inkey id.key -in id.crt -certfile ca.crt
P. Como exportar um certificado para instalá-lo em um novo ASA?
A.
Com CLI: use o comando: crypto ca export <nome_do_ponto_de_confiança> pkcs12 <senha>
Com ASDM:


P. Se as chaves ECDSA forem usadas, o processo de geração de certificado SSL será diferente?
R. A única diferença na configuração é a etapa de geração do par de chaves, em que um par de chaves ECDSA pode ser gerado em vez de um par de chaves RSA. O restante do endereço permanece o mesmo.
P. É sempre necessário gerar um novo par de chaves?
R.As etapas de geração do par de chaves são opcionais. O par de chaves existente pode ser usado ou se o par de chaves PKCS12 for importado com o certificado. Consulte a seção Selecionar o Nome do Par de Chaves para o respectivo tipo de inscrição/reinscrição.
P. É seguro gerar um novo par de chaves para um novo certificado de identidade?
R. Este processo é seguro desde que um novo nome de par de chaves seja usado. Nesse caso, os antigos Pares de Chave não são alterados.
P. É necessário gerar a chave novamente quando um firewall é substituído (como RMA)?
R. O novo firewall por design não tem Pares de chaves presentes no firewall antigo.
O backup da configuração atual não contém os Pares de Chaves. O backup completo feito com o ASDM pode conter os Pares de Chaves.
Os Certificados de Identidade podem ser exportados de um ASA com ASDM ou CLI, antes de falhar. No caso do par de failover, os certificados e os Pares de Chaves são sincronizados com uma unidade de standby com um comando write standby. Se um nó do par de failover for substituído, será suficiente configurar o failover básico e enviar a configuração para o novo dispositivo.
Se um par de chaves for perdido com o dispositivo e não houver backup, um novo certificado deverá ser assinado com um par de chaves presente no novo dispositivo.
| Revisão | Data de publicação | Comentários |
|---|---|---|
5.0 |
29-May-2026
|
Espaçamento atualizado, cabeçalhos e reescreveu algumas frases devido à estrutura/gramática. |
4.0 |
15-Nov-2024
|
Tradução Automática e Formatação Atualizadas. |
3.0 |
25-Jul-2024
|
Texto Alt atualizado, questões de estilo, expressões e pontuação/capitalização. |
2.0 |
22-Apr-2023
|
Lista de colaboradores atualizada. |
1.0 |
19-Apr-2023
|
Versão inicial |