Validação de certificados

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:

• policy-oids

• requireExplicitPolicy

• skipCerts

Esses campos são descritos nas seções a seguir.

• OIDs de políticas configurados em firewalls da Série SRX
• Sem OIDs de política configuradas em firewalls da Série SRX

Sem OIDs de política configuradas em firewalls da Série SRX

Se nenhuma OID de política estiver configurada no firewall da Série SRX, a validação de políticas começa sempre que o requireExplicitPolicy campo é 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.

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 de CA para Int-CA-2 contém o requireExplicitPolicy campo; portanto, a validação de políticas começa com a 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.

Figura 1: Validação de políticas com o necessárioExplicitPolicy Field

O campo opcional skipCerts 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 das políticas. Se skipCerts for 0, a validação da política começa a partir do certificado atual. Se skipCerts for 1, o certificado atual é excluído da validação da política. O valor do skipCerts campo é verificado em todos os certificados de CA intermediários. Se um skipCerts valor for encontrado que seja menor do que o número atual de certificados que estão sendo excluídos, o valor mais baixo skipCerts é usado.

Figura 2 mostra uma cadeia de certificados composta por um CA raiz, quatro CAs intermediários e um EE. O skipCerts valor em Int-CA-1 é de 12, o que ignora 12 certificados, incluindo o certificado para Int-CA-1. No entanto, o skipCerts valor é verificado em todos os certificados de CA intermediários da cadeia. O skipCerts valor em Int-CA-2 é 2, que é inferior a 12, portanto, agora 2 certificados são indispedentes. O skipCerts valor em Int-CA-4 é 5, que é maior que 2, de modo que o valor Int-CA-4 skipCerts é ignorado.

Figura 2: Validação de políticas com skipCerts Field

Quando as OIDs de políticas são configuradas no firewall da Série SRX, os campos requireExplicitPolicy de certificados são ignorados.skipCerts

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. path-length é um campo opcional em um certificado X509. O valor indica path-length 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 contém um path-length valor de 0, não serão permitidos certificados de CA intermediários. Se o path-length valor for 1, pode haver 0 ou 1 certificados de CA intermediários.

path-length 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 path-length valor menor do que o limite de caminho atual, o novo limite será aplicado. Por outro lado, se o path-length valor for maior do que o limite do caminho atual, ele é ignorado.

Figura 3 mostra uma cadeia de certificados que consiste em um CA raiz, quatro CAs intermediários e um EE. O path-length valor em 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 path-length valor 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 path-length valor 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 path-length valor em Int-CA-3 é de 20, que é maior do que o limite de caminho de 2, por isso também é ignorado.

Figura 3: Validação 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.

• Para certificados EE, se o campo de uso chave estiver presente, mas o certificado não conter digitalSignature ou nonrepudiation sinalizar, o certificado será rejeitado. Se o campo de uso da chave não estiver presente, a utilização da chave não será verificada.

• Para certificados 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.

  Na validação da assinatura do certificado, a keyCertSign bandeira indica que um certificado ca pode ser usado para validação da assinatura do certificado. Se essa bandeira não estiver definida, a validação do certificado será rescindida.

  Nas negociações da Fase 1 da validação da assinatura da CRL, 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 CRLSign bandeira 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.

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.

Figura 4: Validação de DN do emissor e do assunto

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.