Um desses requisitos é especificado na cláusula 4.9.9 com a marca DEVE:
As respostas do OCSP (Online Certificate Status Protocol) DEVEM estar em conformidade com o RFC 6960 e / ou RFC 5019. As respostas do OCSP DEVEM:
- Assinado pela CA que emitiu os certificados cujo status de revogação está sendo verificado, ou
- Ter um Respondente OCSP de assinatura cujo certificado é assinado pela CA que emitiu os certificados, cujo status de revogação é verificado
No último caso, o certificado de assinatura OCSP DEVE conter uma extensão do tipo id-pkix-ocsp-nocheck conforme especificado no RFC 6960.
Esta regra é violada por quase todas as autoridades de certificação (CA), o que tem algumas consequências.
Aqui está uma captura de tela dos Requisitos de base para a emissão e gerenciamento de certificados de confiança pública (versão mais recente 1.7.0, 4 de maio de 2020, pdf ):
O padrão RFC6960 na seção 4.2.2.2 define "Respondente delegado OCSP" pela presença de id-kp- OCSPSigning.
O desenvolvedor Ryan Sleevi, cuja empresa é especializada em trabalhar com certificados, provou que as CAs violam massivamente a regra 4.9.9.
Depois de examinar os dados crt.sh, Ryan Slavy encontrou 293 certificados intermediários sem a extensão pkix-nocheck, dos quais 180 são atualmente válidos e 113 revogados.
A filtragem em Census.io emite 276 certificadosatendendo a essas condições.
Assim, esses certificados violam os requisitos básicos de CA / Navegador, além disso, requisitos obrigatórios .
De acordo com Ryan Slavy, os CAs devem examinar mais de perto as regras de CA / navegador. Provavelmente, alguns CAs não estão familiarizados com os requisitos da RFC 6960. A
falta de uma extensão correspondente não é apenas uma formalidade. Não há nenhum problema aqui, no sentido de que uma CA intermediária não pode revogar o certificado de outra CA intermediária da mesma CA raiz.
O verdadeiro problema é que, na ausência de uma extensão, a CA intermediária pode, teoricamente, cancelar a revogação do certificadooutra CA intermediária ou a própria CA raiz. Este é realmente um problema. Na verdade, a autoridade de certificação em tal situação não tem opção confiável para revogação completa e irreversível de certificados. O procedimento de revogação não funciona conforme o esperado, o que abre a porta para invasores que poderiam conduzir um ataque para restaurar o certificado revogado.
Para corrigir esse problema, sugere-se que, ao revogar um certificado, exclua permanentemente todas as cópias das chaves para que a revogação também se torne irreversível.
Para justificar o CA, podemos dizer que mesmo sem esse inconveniente, o procedimento de revogação de certificado não funciona como o esperado agora. Por exemplo, os principais navegadores mantêm suas próprias cópias das CRLs - e nem sempre verificam se elas estão atualizadas. Essas CRLs contêm apenas informações básicas e mais importantes, mas estão longe de serem completas. Por exemplo, o Chrome não se preocupa em verificar se cada certificado TLS específico foi revogado, enquanto o Firefox o faz. Ou seja, às vezes com o Chrome você pode ir com segurança a um site com um certificado expirado, e o Firefox emitirá um aviso e não deixará você lá.
Curiosamente, de acordo com as regras, certificados incorretos devem ser revogados em navegadores dentro de 7 dias, mas uma exceção foi feita para esta situação. Ben Wilson, da Mozilla, disse que nãorevogar certificados com a extensão id-pkix-ocsp-nocheck ausente. Embora esses certificados não sejam compatíveis, o navegador Firefox não é afetado por esta vulnerabilidade de segurança específica porque não aceita respostas OCSP assinadas por CAs intermediários.
As CAs devem substituir de alguma forma os certificados incorretos, mas não há um prazo final para eles.
Para obter mais informações sobre soluções de PKI para empresas , entre em contato com os gerentes da GlobalSign +7 (499) 678 2210, sales-ru@globalsign.com.