L'une de ces exigences est spécifiée dans la clause 4.9.9 avec la marque MUST:
Les réponses OCSP (Online Certificate Status Protocol) DOIVENT être conformes aux RFC 6960 et / ou RFC 5019. Les réponses OCSP DOIVENT soit:
- Signé par l'autorité de certification qui a émis les certificats dont l'état de révocation est en cours de vérification, ou
- Avoir une signature OCSP Responder dont le certificat est signé par l'autorité de certification qui a émis les certificats, dont le statut de révocation est vérifié
Dans ce dernier cas, la signature du certificat OCSP DOIT contenir une extension de type id-pkix-ocsp-nocheck comme spécifié dans la RFC 6960.
Cette règle est violée par presque toutes les autorités de certification (CA), ce qui a des conséquences.
Voici une capture d'écran de Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (dernière version 1.7.0, 4 mai 2020, pdf ):
La norme RFC6960 dans la section 4.2.2.2 définit «OCSP Delegated Responder» par id-kp- OCSPSigning.
Le développeur Ryan Sleevi, dont la société est spécialisée dans le travail avec des certificats, a prouvé que les autorités de certification enfreignent massivement la règle 4.9.9.
Après avoir examiné les données crt.sh, Ryan Slavy a trouvé 293 certificats intermédiaires sans l'extension pkix-nocheck, dont 180 sont actuellement valides et 113 révoqués.
Le filtrage sur Census.io émet 276 certificatscorrespondant à ces conditions.
Ainsi, ces certificats enfreignent les exigences de base de CA / Browser, en outre, les exigences obligatoires .
Selon Ryan Slavy, les CA devraient examiner de plus près les règles CA / Browser. Certaines autorités de certification ne sont probablement pas familiarisées avec les exigences de la RFC 6960.
L'absence d'une extension correspondante n'est pas seulement une formalité. Il n'y a pas de problème ici en ce sens qu'une autorité de certification intermédiaire ne peut pas révoquer le certificat d'une autre autorité de certification intermédiaire de la même autorité de certification racine.
Le vrai problème est qu'en l'absence d'extension, l'AC intermédiaire peut théoriquement annuler la révocation du certificatune autre autorité de certification intermédiaire ou l'autorité de certification racine elle-même. C'est vraiment un problème. En fait, l'autorité de certification dans une telle situation n'a pas d'option fiable pour la révocation complète et irréversible des certificats. Le processus de révocation ne fonctionne pas comme prévu, ce qui ouvre la porte à des attaquants susceptibles de mener une attaque pour restaurer le certificat révoqué.
Pour résoudre ce problème, il est suggéré de supprimer définitivement toutes les copies des clés lors de la révocation d'un certificat afin que la révocation devienne également irréversible.
Pour justifier l'AC, on peut dire que même sans cet inconvénient, la procédure de révocation de certificat ne fonctionne pas comme prévu actuellement. Par exemple, les principaux navigateurs conservent leurs propres copies des listes de révocation de certificats - et ne vérifient pas toujours qu’elles sont à jour. Ces listes CRL ne contiennent que les informations de base les plus importantes, mais elles sont loin d'être complètes. Par exemple, Chrome ne prend pas la peine de vérifier si chaque certificat TLS spécifique a été révoqué, contrairement à Firefox. Autrement dit, parfois avec Chrome, vous pouvez accéder en toute sécurité à un site avec un certificat expiré, et Firefox émettra un avertissement et ne vous laissera pas y aller.
Fait intéressant, selon les règles, les certificats incorrects doivent être révoqués dans les navigateurs dans les 7 jours, mais une exception a été faite pour cette situation. Ben Wilson de Mozilla a dit qu'ils ne le feraient pasrévoquez les certificats avec l'extension id-pkix-ocsp-nocheck manquante. Bien que ces certificats ne soient pas conformes, le navigateur Firefox n'est pas affecté par cette vulnérabilité de sécurité spécifique car il n'accepte pas les réponses OCSP signées par les autorités de certification intermédiaires.
Les autorités de certification devraient en quelque sorte remplacer les certificats incorrects, mais il n'y a pas de date limite finale pour eux.
Pour plus d'informations sur les solutions PKI pour les entreprises , contactez les responsables de GlobalSign au +7 (499) 678 2210, sales-ru@globalsign.com.