En ce qui concerne la conception de l'infrastructure destinée à fournir les informations de blocage, c'est-à-dire les points de distribution des listes de révocation (CRL Distribution Point, CSP) et les répondeurs en ligne (Online Certificate Status Protocol, OCSP), la question se pose de savoir s'il convient de les „ sécuriser “ via Secure Sockets Layer (SSL) ou Transport Layer Security (TLS).
Il est parfois nécessaire qu'un certificat délivré par une autorité de certification soit retiré avant sa date d'expiration. Pour ce faire, une autorité de certification tient à jour une liste de révocation. Il s'agit d'un fichier signé avec une date d'expiration relativement courte, qui est utilisé en combinaison avec le certificat pour vérifier sa validité.
Le Online Responder (Online Certificate Status Protocol, OCSP) est une autre manière de fournir des informations sur le statut de révocation des certificats. Grâce à l'OCSP, les entités qui souhaitent vérifier le statut de révocation d'un certificat ne doivent pas télécharger la liste complète de tous les certificats révoqués, mais peuvent adresser une demande ciblée au répondeur en ligne pour le certificat concerné. Pour une description plus détaillée, voir l'article "Principes de base du répondeur en ligne (Online Certificate Status Protocol, OCSP)„ .
Souvent, les entreprises sont également tenues, en raison de directives de conformité, de reproduire toutes les connexions basées sur HTTP via SSL/TLS. La question se pose donc de savoir si et comment cela doit être mis en œuvre pour les CDP ou les OCSP, car ces deux méthodes reposent sur le HTTP non crypté et donc prétendument non sécurisé.
Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.
Pour répondre à cette question, jetons d'abord un coup d'œil aux RFC pertinents sur ce sujet. Pour les points de distribution de listes de blocage, il s'agirait du RFC 5280:
Lorsque les certificats incluent une extension cRLDistributionPoints avec un https URI ou un schéma similaire, des dépendances circulaires peuvent être introduites. La partie requérante est obligée de procéder à une validation supplémentaire du chemin afin d'obtenir la CRL nécessaire pour compléter la validation initiale du chemin ! Des conditions circulaires peuvent également être créées avec un https URI (ou un schéma similaire) dans les extensions authorityInfoAccess ou subjectInfoAccess. Dans le pire des cas, cette situation peut créer des dépendances impossibles à résoudre. Les AC NE DOIVENT PAS inclure des URI qui spécifient https, ldaps, ou des schémas similaires dans les extensions. Les AC qui incluent un URI https dans l'une de ces extensions DOIVENT s'assurer que le certificat du serveur peut être validé sans utiliser les informations pointées par l'URI. Les parties qui choisissent de valider le certificat du serveur en obtenant des informations pointées par un URI https dans les extensions cRLDistributionPoints, authorityInfoAccess, ou subjectInfoAccess DOIVENT être préparées à l'éventualité que cela se traduise par un retour en arrière non sollicité.
RFC 5280 : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Pour le Online Certificate Status Protocol, nous trouvons le passage correspondant dans le RFC 6960:
Lorsque la confidentialité est une exigence, les transactions OCSP échangées au moyen de HTTP MAY doivent être protégées au moyen soit de Transport Layer Security/Secure Socket Layer (TLS/SSL), soit d'un autre protocole de niveau inférieur.
RFC 6960 : X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
Conclusion
Les deux RFC n'interdisent pas l'utilisation de SSL/TLS. Toutefois, le RFC 5280 met explicitement en garde contre cela. La raison est la suivante
Si l'on utilise SSL/TLS pour les informations de verrouillage, on a besoin d'un certificat correspondant. Celui-ci contiendra à son tour des informations de verrouillage qui devront être vérifiées pour que le certificat soit reconnu comme valable.
On crée ainsi une dépendance insoluble (si l'on souhaite utiliser SSL/TLS de manière continue). La seule possibilité de la résoudre est de représenter le dernier point de distribution de la liste de blocage de la chaîne sans HTTPS.
Ainsi, les avantages supposés du HTTPS ne s'appliquent pas dans ce cas.
Toutefois, étant donné que les informations de blocage sont de toute façon signées par l'autorité de certification ou le répondeur en ligne et donc protégées contre les manipulations, aussi bien lors de l'utilisation de listes de blocage que d'OCSP, il n'y a aucune raison d'utiliser HTTPS dans ce cas, même en dehors du problème des dépendances insolubles.
Liens complémentaires :
Sources externes
- RFC 5280 : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (Internet Engineering Task Force)
- RFC 6960 : X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP (Internet Engineering Task Force)
Français 
Deutsch 
English
Les commentaires sont fermés.