Revogação de certificados

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 declaração no nível [] de hierarquia; até dois locais podem ser configurados para cada perfil de CA.ocsp urledit security pki ca-profile profile-name revocation-check 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 também deve ser configurada, pois a lista de revogação de certificados (CRL) é o método de verificação padrão.use-ocsp

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:

1. O certificado ca inscrito para o perfil ca configurado é usado para validar a resposta.

2. 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:

1. 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.
2. 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.

Este exemplo mostra como carregar um CRL manualmente no dispositivo.

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 , 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.Figura 1

Figura 1: Hierarquia multinível para autenticação baseada em certificados

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:

Para ativar perfis dinâmicos de CA, você deve configurar a opção em um perfil Root-CA no nível [] de hierarquia.revocation-check crledit security pki ca-profile profile-name

As propriedades de verificação de revogação de um perfil Root-CA são herdadas para perfis dinâmicos de CA. Em , 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:Figura 1

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 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.revocation-check disable

Os dados de CRLs baixados de perfis dinâmicos de CA são exibidos com o comando da mesma forma que os CRLs baixados por perfis de CA configurados.show security pki crl 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.

Este exemplo mostra como configurar um perfil de autoridade de certificado com locais de CRL.

Este exemplo mostra como verificar a validade de um certificado.