Revogação de certificados
Os certificados digitais têm uma data de validade, no entanto, antes do término, um certificado pode não ser mais válido devido a muitos motivos. Você pode gerenciar revogações e validações de certificados localmente e fazendo referência a uma lista de revogação de certificados (CRL) da Autoridade de Certificados (CA).
Entendendo listas de revogação de certificados e protocolo de status de certificado on-line
O OCSP é usado para verificar o status de revogação dos certificados X509. O OCSP fornece status de revogação em certificados em tempo real e é útil em situações sensíveis ao tempo, como transações bancárias e negociações de ações.
O status de revogação de um certificado é verificado enviando uma solicitação a um servidor OCSP que reside fora de um firewall da Série SRX. Com base na resposta do servidor, a conexão VPN é permitida ou negada. As respostas do OCSP não são armazenadas em cache em firewalls da Série SRX.
O servidor OCSP pode ser a autoridade de certificado (CA) que emite um certificado ou um respondente autorizado designado. A localização do servidor OCSP pode ser configurada manualmente ou extraída do certificado que está sendo verificado. As solicitações são enviadas primeiro aos locais de servidor OCSP que são configurados manualmente em perfis de CA com a ocsp url
declaração no nível [edit security pki ca-profile profile-name revocation-check
] de hierarquia; até dois locais podem ser configurados para cada perfil de CA. Se o primeiro servidor OCSP configurado não for acessível, a solicitação será enviada ao segundo servidor OCSP. Se o segundo servidor OCSP não for acessível, a solicitação será enviada ao local no campo de extensão AuthorityInfoAccess do certificado. A opção use-ocsp
também deve ser configurada, pois a lista de revogação de certificados (CRL) é o método de verificação padrão.
Os firewalls da Série SRX aceitam apenas respostas OCSP assinadas do CA ou do respondente autorizado. A resposta recebida é validada usando certificados confiáveis. A resposta é validada da seguinte forma:
-
O certificado ca inscrito para o perfil ca configurado é usado para validar a resposta.
-
A resposta do OCSP pode conter um certificado para validar a resposta do OCSP. O certificado recebido deve ser assinado por um certificado de CA inscrito no firewall da Série SRX. Após o certificado recebido ser validado pelo certificado ca, ele é usado para validar a resposta do OCSP.
A resposta do servidor OCSP pode ser assinada por diferentes CAs. Os cenários a seguir são suportados:
-
O servidor ca que emite o certificado de entidade final para um dispositivo também assina a resposta de status de revogação do OCSP. O firewall da Série SRX verifica a assinatura de resposta ao OCSP usando o certificado CA inscrito no firewall da Série SRX. Após a validação da resposta ao OCSP, o status de revogação do certificado é verificado.
-
Um respondente autorizado assina a resposta ao status de revogação do OCSP. O certificado para o respondente autorizado e o certificado de entidade final que está sendo verificado devem ser emitidos pela mesma CA. O respondente autorizado é verificado pela primeira vez usando o certificado CA inscrito no firewall da Série SRX. A resposta do OCSP é validada usando o certificado ca do respondente. Em seguida, o firewall da Série SRX usa a resposta do OCSP para verificar o status de revogação do certificado de entidade final.
-
Existem diferentes sinalizadores de CA para que o certificado da entidade final seja verificado e a resposta ao OCSP. A resposta do OCSP é assinada por um CA na cadeia de certificados para que o certificado da entidade final seja verificado. (Todos os pares participantes de uma negociação de IKE precisam ter pelo menos uma CA de confiança comum em suas respectivas cadeias de certificados.) O CA do respondente do OCSP é verificado usando um CA na cadeia de certificados. Após a validação do certificado ca respondente, a resposta do OCSP é validada usando o certificado de CA do respondente.
Para evitar ataques de repetição, uma carga nonce pode ser enviada em uma solicitação de OCSP. As cargas de nonce são enviadas por padrão a menos que sejam explicitamente desativadas. Se habilitado, o firewall da Série SRX espera que a resposta do OCSP contenha uma carga de nonce, caso contrário, a verificação de revogação falha. Se os respondentes do OCSP não forem capazes de responder com uma carga nonce, a carga de nonce deve ser desativada no firewall da Série SRX.
No curso normal da empresa, os certificados são revogados por várias razões. Você pode querer revogar um certificado se suspeitar que ele foi comprometido, por exemplo, ou quando um titular de certificado deixar a empresa.
Você pode gerenciar revogações e validações de certificados de duas maneiras:
-
Localmente— Esta é uma solução limitada.
-
Fazendo referência a uma lista de revogação de certificados (CRL) da Autoridade de Certificado (CA) — Você pode acessar automaticamente o CRL on-line em intervalos que você especifica ou no intervalo padrão definido pela CA.
Nas negociações da Fase 1, o firewall da Série SRX verifica o certificado EE recebido do peer durante uma troca de IKE e usa o CRL para garantir que o certificado EE não seja revogado por seu CA.
Se um CRL não estiver carregado no dispositivo e o emissor de certificados de peer for um CA confiável:
- O Junos OS recupera o CRL por meio dos locais LDAP ou HTTP CRL configurados (ou seja, os pontos de distribuição de CRL (CDP)), se eles forem definidos no perfil ca.
- Se os pontos de distribuição de CRL não estiverem configurados no perfil ca, o dispositivo usará a extensão do CDP em um certificado emitido pela CA (se presente). O certificado emitido pela CA pode ser um certificado inscrito pelo administrador ou recebido durante a negociação da Fase 1.
Se o certificado EE não for emitido por um CA raiz, os certificados de cada CAs intermediários passarão pela mesma verificação de verificação e revogação. O CRL do CA raiz é usado para verificar se o certificado emitido pelo CA raiz é revogado. Se o CDP não estiver configurado no perfil de CA raiz, o dispositivo usará a extensão do CDP no certificado emitido pela CA (se presente).
A extensão do ponto de distribuição CRL (.cdp) em um certificado X509 pode ser adicionada a uma URL HTTP ou a uma URL LDAP.
Se o certificado não conter uma extensão do ponto de distribuição de certificados e você não conseguir recuperar automaticamente o CRL por meio do Lightweight Directory Access Protocol (LDAP) ou do Hypertext Transfer Protocol (HTTP), você pode recuperar um CRL manualmente e carregar o que está no dispositivo.
Os certificados locais estão sendo validados em relação à lista de revogação de certificados (CRL), mesmo quando a verificação de CRL é desativada. Isso pode ser interrompido desativando a verificação de CRL pela configuração da infraestrutura de chave pública (PKI). Quando a verificação de CRL é desativada, o PKI não validará o certificado local contra a CRL.
Comparação entre o protocolo de status do certificado on-line e a lista de revogação de certificados
O Protocolo de status de certificado on-line (OCSP) e a lista de revogação de certificados (CRL) podem ser usados para verificar o status de revogação de um certificado. Há vantagens e desvantagens em cada método.
-
O OCSP oferece status de certificado em tempo real, enquanto o CRL usa dados em cache. Para aplicativos sensíveis ao tempo, o OCSP é a abordagem preferida.
-
A verificação de CRL é mais rápida porque a busca pelo status do certificado é feita em informações armazenadas em cache no dispositivo VPN. O OCSP requer tempo para obter o status de revogação de um servidor externo.
-
O CRL requer memória adicional para armazenar a lista de revogação recebida de um servidor CRL. O OCSP não requer memória adicional para salvar o status de revogação dos certificados.
-
O OCSP exige que o servidor OCSP esteja disponível o tempo todo. A CRL pode usar dados em cache para verificar o status de revogação dos certificados quando o servidor estiver inalcançável.
Nos firewalls da Série MX e da Série SRX, o CRL é o método padrão usado para verificar o status de revogação de um certificado.
Consulte também
Exemplo: Carregando manualmente um CRL no dispositivo
Este exemplo mostra como carregar um CRL manualmente no dispositivo.
Requisitos
Antes de começar:
Gere um par de chaves público e privado. Veja certificados digitais auto-assinados.
Gere uma solicitação de certificado. Veja exemplo: Gerando manualmente um CSR para o certificado local e enviando-o para o servidor CA.
Configure um perfil de autoridade de certificado (CA). Veja exemplo: Configurando um perfil de CA.
Carregue seu certificado no dispositivo. Veja exemplo: Carregamento manual de CA e certificados locais.
Visão geral
Você pode carregar um CRL manualmente ou fazer com que o dispositivo o carregue automaticamente, quando verificar a validade do certificado. Para carregar um CRL manualmente, você obtém o CRL de um CA e transfere-o para o dispositivo (por exemplo, usando FTP).
Neste exemplo, você carrega um certificado CRL chamado revoke.crl
do /var/tmp directory no dispositivo. O perfil da CA é chamado ca-profile-ipsec
. (O tamanho máximo do arquivo é de 5 MB.)
Se um CRL já estiver carregado no perfil ca, o comando clear security pki crl ca-profile ca-profile-ipsec
deve ser executado primeiro para limpar o CRL antigo.
Configuração
Procedimento
Procedimento passo a passo
Para carregar manualmente um certificado CRL:
Carregue um certificado CRL.
[edit] user@host> request security pki crl load ca-profile ca-profile-ipsec filename /var/tmp/revoke.crl
O Junos OS oferece suporte ao carregamento de certificados de CA nos formatos X509, PKCS nº 7, DER ou PEM.
Verificação
Para verificar se a configuração está funcionando corretamente, insira o comando do show security pki crl
modo operacional.
Entenda o download e verificação dinâmicos do CRL
Os certificados digitais são emitidos por um período determinado de tempo e são inválidos após a data de validade especificada. Um CA pode revogar um certificado emitido listando-o em uma lista de revogação de certificados (CRL). Durante a validação do certificado de peer, o status de revogação de um certificado peer é verificado baixando o CRL de um servidor CA para o dispositivo local.
Para facilitar a verificação de CRL para os certificados quando um perfil de CA não estiver configurado, cria-se um perfil dinâmico de CA. Um perfil ca dinâmico é criado automaticamente no dispositivo local com o formato dynamic-nnn
.
Um perfil dinâmico de CA:
- Permite que o dispositivo local baixe o CA dinâmico e o CRL dinâmico (para CA correspondente) conforme o emissor de certificação local do peer
- Verifica o status de revogação do certificado do peer
Um dispositivo VPN verifica o certificado EE de um peer para seu status de revogação. Um dispositivo VPN usa o certificado recebido de seus pares para fazer o seguinte:
- Extraia a URL para baixar dinamicamente o CRL do CA
- Verifique o status de revogação do certificado EE do peer
In Figura 1, o Host-A pode usar os certificados de Vendas-CA e EE recebidos do Host-B para baixar dinamicamente o CRL para Sales-CA e verificar o status de revogação do certificado do Host-B.
![Hierarquia multinível para autenticação baseada em certificados](../concept/../../vpn-l2/images/g039005.gif)
No caso de servidores CA de hierarquia única ou cadeia de certificados ca, o certificado EE local e o certificado EE de peer recebido são emitidos do mesmo servidor CA.
A seguir, alguns dos comportamentos do firewall da Série SRX são baseados em diferentes configurações:
- Se você tiver configurado um firewall da Série SRX com um grupo de ca confiável ou confiável, o dispositivo não valida ou confia em nenhum outro CAs.
- Se você tiver definido um perfil de CA que tenha uma cadeia de CAs onde o firewall da Série SRX confia apenas no CA raiz e o peer tem um certificado assinado por um sub-CA a esta raiz, então CA dinâmico e CRL serão adicionados ao dispositivo.
Tabela 1 fornece poucos cenários de amostra em que o CA dinâmico ou o CRL não são criados:
Cenário |
Condição |
---|---|
Cenário de amostra 1 |
No perfil ca, você definiu um CA confiável para o nome ca-profile, e você recebe uma conexão de um dispositivo que tem um certificado assinado por um CA diferente que não foi definido como um CA confiável em seu perfil de CA. |
Cenário de amostra 2 |
Você definiu um perfil de CA que tem uma cadeia de CAs onde o firewall da Série SRX confia apenas em um sub-CA, e o peer tem um certificado assinado por um nível acima deste sub-CA. |
Para ativar perfis dinâmicos de CA, você deve configurar a opção revocation-check crl
em um perfil Root-CA no nível [edit security pki ca-profile profile-name
] de hierarquia.
As propriedades de verificação de revogação de um perfil Root-CA são herdadas para perfis dinâmicos de CA. Em Figura 1, a configuração do perfil ca no Host-A para Root-CA permite perfis dinâmicos de CA conforme mostrado na saída a seguir:
admin@host-A# show security pki { ca-profile Root-CA { ca-identity Root-CA; enrollment { url “www.example.net/scep/Root/”; } revocation-check { crl; } } }
Um perfil dinâmico de CA é criado no Host-A para Vendas-CA. A verificação de revogação é herdada para o perfil de CA dinâmico Sales-CA da Root-CA.
Se a revocation-check disable
declaração estiver configurada em um perfil Root-CA, os perfis dinâmicos de CA não serão criados e o download e verificação dinâmicos de CRL não serão realizados.
Os dados de CRLs baixados de perfis dinâmicos de CA são exibidos com o comando da show security pki crl
mesma forma que os CRLs baixados por perfis de CA configurados. O CRL de um perfil ca dinâmico é atualizado periodicamente, assim como os de perfis de CA que estão configurados no dispositivo. O certificado de CA peer também é necessário para validação de assinatura de CRL baixado do servidor CA.
O certificado ca é necessário para validar o CRL recebido de um servidor ca; portanto, o certificado de CA recebido de um peer é armazenado no dispositivo local. O certificado ca recebido de peer é usado para validar o CRL e o certificado emitido por ele. Como o certificado ca recebido não é inscrito por um administrador, o resultado de uma verificação bem sucedida do certificado não é conclusivo até que toda a cadeia de certificados até o CA raiz seja verificada. O certificado da CA raiz deve ser inscrito por um administrador.
Consulte também
Exemplo: Configuração de um perfil de autoridade de certificados com locais de CRL
Este exemplo mostra como configurar um perfil de autoridade de certificado com locais de CRL.
Requisitos
Antes de começar:
Gere um par chave no dispositivo. Veja certificados digitais.
Crie um perfil ou perfis de CA que contenham informações específicas para um CA. Veja exemplo: Configurando um perfil de CA.
Obtenha um certificado pessoal da CA. Veja exemplo: Gerando manualmente um CSR para o certificado local e enviando-o para o servidor CA.
Carregue o certificado no dispositivo. Veja exemplo: Carregamento manual de CA e certificados locais.
Configure o reencamamento automático. Veja exemplo: Configuração da autenticação do usuário securID.
Se necessário, carregue o CRL do certificado no dispositivo. Veja exemplo: Carregando manualmente um CRL no dispositivo.
Visão geral
Neste exemplo, você direciona o dispositivo para verificar a validade do perfil ca chamado my_profile
e, se um CRL não acompanhou um certificado ca e não está carregado no dispositivo, para recuperar o CRL da URL http://abc/abc-crl.crl
.
Configuração
Procedimento
Procedimento passo a passo
Para configurar o certificado usando CRL:
Especifique o perfil e a URL da CA.
[edit] user@host# set security pki ca-profile my_profile revocation-check crl url http://abc/abc-crl.crl
Se você terminar de configurar o dispositivo, confirme a configuração.
[edit] user@host# commit
Verificação
Para verificar se a configuração está funcionando corretamente, insira o comando do show security pki
modo operacional.
Exemplo: Validação do certificado de verificação
Este exemplo mostra como verificar a validade de um certificado.
Requisitos
Nenhuma configuração especial além da inicialização do dispositivo é necessária antes de configurar esse recurso.
Visão geral
Neste exemplo, você verifica certificados manualmente para descobrir se um certificado foi revogado ou se o certificado ca usado para criar um certificado local não está mais presente no dispositivo.
Ao verificar certificados manualmente, o dispositivo usa o certificado ca (ca-cert
) para verificar o certificado local ( local.cert
). Se o certificado local for válido e se revocation-check
estiver habilitado no perfil ca, o dispositivo verifica se o CRL está carregado e válido. Se o CRL não estiver carregado e válido, o dispositivo baixará o novo CRL.
Para certificados emitidos por CA ou certificados de CA, uma DNS deve ser configurada na configuração do dispositivo. A DNS deve ser capaz de resolver o host no CRL de distribuição e na url da lista de cert/revogação ca na configuração de ca-profile. Além disso, você deve ter a acessibilidade da rede para o mesmo host para que as verificações recebam.
Configuração
Procedimento
Procedimento passo a passo
Para verificar manualmente a validade de um certificado:
Verifique a validade de um certificado local.
[edit] user@host> request security pki local-certificate verify certificate-id local.cert
Verifique a validade de um certificado ca.
[edit] user@host> request security pki ca-certificate verify ca-profile ca-profile-ipsec
A chave privada associada e a assinatura também são verificadas.
Verificação
Para verificar se a configuração está funcionando corretamente, insira o show security pki ca-profile
comando.
Se um erro for devolvido em vez de uma verificação positiva, a falha será registrada no pkid.
Exclusão de um CRL carregado (procedimento CLI)
Você pode optar por excluir um CRL carregado se não precisar mais usá-lo para gerenciar revogações e validações de certificados.
Use o comando a seguir para excluir uma lista de revogação de certificados carregada:
user@host>
clear security pki crl ca-profile (ca-profile all)
Especifique um perfil de CA para excluir um CRL associado ao CA identificado pelo perfil ou usar all
para excluir todos os CRLs.