Entendendo a validação de certificados digitais
Encarando o Junos OS Release 16.1R3, os dispositivos da Série MX oferecem suporte à validação de certificado digital. Durante a negociação do IKE, o daemon PKI em um dispositivo da Série MX valida os certificados X509 recebidos dos pares de VPN. A validação do certificado realizada é especificada no perfil rfc 5280, Certificado de infraestrutura de chave pública Internet X.509 e perfil da Lista de revogação de certificados (CRL). As validações básicas da cadeia de certificados e certificados incluem validação de assinatura e data, bem como verificações de revogação. Este tópico descreve validações adicionais de certificados digitais realizadas pelo daemon PKI.
Validação de políticas
Os certificados X509 podem incluir campos de validação de políticas opcionais. Se um campo de validação de políticas estiver presente, a validação de políticas é realizada para toda a cadeia de certificados, incluindo certificados de entidade final (EE) e certificados de autoridade de certificado intermediário (CA). A validação da política não é aplicável ao certificado raiz. A validação da política garante que os certificados de EE e CA intermediários tenham uma política comum. Se não houver uma política comum para validação da cadeia de certificados, a validação do certificado falhará.
Antes da validação de políticas, deve ser criada uma cadeia de certificados contendo o certificado raiz autoassinado, certificados de CA intermediários e certificado EE. A validação da política começa com o certificado de CA intermediário emitido pelo certificado raiz auto-assinado e continua por meio do certificado EE.
Os seguintes campos de certificado opcional são usados para validação de políticas:
políticas oids
exigir Políticade serviçosexplicita
skipCerts
Esses campos são descritos nas seções a seguir.
- OIDs de políticas configuradas em dispositivos da Série MX
- Sem OIDs de política configuradas em dispositivos da Série MX
OIDs de políticas configuradas em dispositivos da Série MX
Em algumas situações, pode ser desejável aceitar apenas certificados com identificadores de objetos de política (OIDs) conhecidos de pares. Essa configuração opcional permite que a validação do certificado só tenha sucesso se a cadeia de certificados recebida do peer conter pelo menos uma OID de política configurada no dispositivo da Série MX.
No dispositivo da Série MX, as OIDs de políticas estão configuradas em uma política de IKE com a policy-oids declaração de configuração no nível [edit security ike policy policy-name certificate] de hierarquia. Você pode configurar até cinco OIDs de política. Para que o certificado de um peer seja validado com sucesso, a cadeia de certificados do peer deve conter pelo menos uma das OIDs de política configuradas no dispositivo da Série MX. Observe que o campo de políticas oids em um certificado é opcional. Se você configurar OIDs de política no dispositivo da Série MX, mas a cadeia de certificados do peer não conter nenhuma OIDs de política, a validação do certificado falha.
Sem OIDs de política configuradas em dispositivos da Série MX
Se nenhuma OID de política estiver configurada no dispositivo da Série MX, a validação de políticas começa sempre que o campo de políticaexplicit é encontrado na cadeia de certificados. Um certificado pode conter uma ou mais OIDs de política de certificado. Para que a validação de políticas tenha sucesso, deve haver uma OID de política comum na cadeia de certificados.
A Figura 1 mostra uma cadeia de certificados que consiste em certificados para um CA raiz, três CAs intermediários e um EE. O certificado ca para Int-CA-2 contém o campo De políticas de serviço obrigatório ; portanto, a validação de políticas começa com o Int-CA-2 e continua por meio do EE-1. O certificado para Int-CA-2 contém políticas OIDs P1, P2 e P3. O certificado para Int-CA-3 contém políticas OIDs P2, P3 e P4. O certificado para EE-1 contém políticas OIDs P2 e P5. Como a política OID P2 é comum que os certificados sejam validados, a validação de políticas é bem-sucedida.
O campo skipCerts opcional em um certificado de CA intermediário indica o número de certificados, incluindo o certificado CA atual, que devem ser excluídos da validação da política. Se o skipCerts for 0, a validação da política começa a partir do certificado atual. Se o skipCerts for 1, o certificado atual será excluído da validação da política. O valor do campo skipCerts é verificado em todos os certificados de CA intermediários. Se um valor skipCerts for encontrado que seja menor do que o número atual de certificados que estão sendo excluídos, o valor mais baixo do skipCerts é usado.
A Figura 2 mostra uma cadeia de certificados que consiste em um CA raiz, quatro CAs intermediários e um EE. O valor de skipCerts no Int-CA-1 é de 12, o que ignora 12 certificados, incluindo o certificado para Int-CA-1. No entanto, o valor do skipCerts é verificado em todos os certificados de CA intermediários da cadeia. O valor de skipCerts no Int-CA-2 é de 2, que é inferior a 12, então agora 2 certificados são indispiratórios. O valor de skipCerts no Int-CA-4 é 5, que é maior que 2, de modo que o valor do Int-CA-4 skipCerts é ignorado.
Quando as OIDs de políticas são configuradas no dispositivo da Série MX, os campos de certificados exigem A política de serviços e o skipCerts são ignorados .
Validação do comprimento do caminho
A validação do certificado pode envolver uma cadeia de certificados que inclui um CA raiz, um ou mais CAs intermediários opcionais e um certificado EE. O número de CAs intermediários pode crescer dependendo do cenário de implantação. A validação do comprimento do caminho fornece um mecanismo para limitar o número de certificados intermediários envolvidos na validação do certificado. o comprimento do caminho é um campo opcional em um certificado X509. O valor do comprimento do caminho indica o número de certificados de CA intermediários não autografados permitidos para validação de certificados. O último certificado, que geralmente é o certificado EE, não está incluído no limite do caminho. Se o certificado raiz contiver um valor de comprimento de caminho de 0, nenhum certificado de CA intermediário será permitido. Se o valor do comprimento do caminho for 1, pode haver 0 ou 1 certificados de CA intermediários.
o comprimento do caminho pode estar presente em vários certificados de CA na cadeia de certificados. A validação do comprimento do caminho sempre começa com o certificado raiz auto-assinado. O limite de caminho é decrementeado em 1 em cada certificado intermediário da cadeia. Se um certificado intermediário contém um valor de comprimento de caminho menor do que o limite de caminho atual, o novo limite é aplicado. Por outro lado, se o valor do comprimento do caminho for maior do que o limite de caminho atual, ele é ignorado.
A Figura 3 mostra uma cadeia de certificados que consiste em um CA raiz, quatro CAs intermediários e um EE. O valor de comprimento de caminho no Root-CA é de 10, portanto, o limite inicial de caminho de certificados de CA intermediários não autografados permitidos para validação de certificados é de 10. Na Int-CA-1, o limite de caminho é de 10-1 ou 9. O valor de comprimento do caminho em Int-CA-1 é 4, que é menor do que o limite de caminho de 9, de modo que o novo limite de caminho se torna 4. Na Int-CA-2, o limite de caminho é de 4-1 ou 3. O valor de comprimento do caminho em Int-CA-2 é 5, que é maior do que o limite de caminho de 3, por isso é ignorado. Na Int-CA-3, o limite de caminho é de 3-1 ou 2. O valor de comprimento do caminho em Int-CA-3 é de 20, que é maior do que o limite de caminho de 2, por isso também é ignorado.
do comprimento do caminho
Uso de chave
O campo de uso chave em um certificado de EE ou CA define a finalidade da chave contida no certificado.
Certificados EE
Para certificados EE, se o campo de uso chave estiver presente, mas o certificado não conter bandeiras digitais de assinatura ou não de observação , o certificado é rejeitado. Se o campo de uso da chave não estiver presente, a utilização da chave não será verificada.
Certificados de CA
A chave pode ser usada para validação de certificados ou assinaturas de CRL. Como o daemon PKI é responsável pela validação do certificado X509 e pelos downloads de CRL, o uso da chave deve ser verificado antes de validar o certificado ou o CRL.
Validação de assinatura de certificado
A bandeira chavecertSign indica que um certificado CA pode ser usado para validação de assinatura de certificados. Se essa bandeira não estiver definida, a validação do certificado será rescindida.
Validação de assinatura crl
Nas negociações da Fase 1, os participantes verificam a lista de revogação de certificados (CRL) para ver se os certificados recebidos durante uma troca de IKE ainda são válidos. O CRL é baixado periodicamente para perfis de CA configurados com CRL conforme a verificação de revogação do certificado. Os arquivos CRL baixados devem ser verificados antes de serem baixados no dispositivo. Uma das etapas de verificação é validar a assinatura de CRL usando um certificado CA. O CRL baixado é assinado com a chave privada do certificado CA e deve ser verificado com a chave pública do certificado ca armazenada no dispositivo. O campo de uso chave no certificado CA deve conter a bandeira CRLSign para verificar o CRL baixado. Se essa bandeira não estiver presente, o CRL será descartado.
Validação de nomes distintos do emissor e do assunto
A validação da assinatura é realizada para certificados recebidos de um peer, bem como para o arquivo CRL baixado de um servidor CA. A validação da assinatura envolve procurar o certificado ca em um banco de dados de CA com base no nome distinto (DN) do emissor no certificado ou no CRL que está sendo verificado.
A Figura 4 mostra a busca por certificados de CA com base no DN do emissor. No certificado EE, o DN emissor é o CA-1, que é o DN sujeito do certificado de CA intermediário na cadeia. No certificado de CA intermediário, o emissor DN é CA-Root, que é o assunto DN do certificado Root-CA auto-assinado na cadeia. No CRL, o emissor DN é CA-Root, que é o assunto DN do certificado Root-CA auto-assinado.
do emissor e do sujeito DN
A busca pelo emissor ou DN do assunto deve seguir essas regras para obter valores de atributos:
Os valores de atributo codificados em diferentes tipos de ASN.1 (por exemplo, PrintableString e BMPString) são considerados como diferentes strings.
Os valores de atributo codificados em tipos de PrintableString não são sensíveis ao caso. Esses valores de atributos são comparados após a remoção de espaços brancos líderes e trailing e a conversão de subdireções internas de um ou mais espaços brancos consecutivos em um único espaço.
Os valores de atributo codificados em tipos diferentes do PrintableString são sensíveis ao caso.
Tabela de histórico de mudanças
O suporte de recursos é determinado pela plataforma e versão que você está usando. Use o Feature Explorer para determinar se um recurso é suportado em sua plataforma.