ssltest: Problèmes de chaîne - Contient une ancre
J'ai exécuté ssltest sur l'application Web et il a trouvé "Problèmes de chaîne - Contient une ancre" (section "Certificats supplémentaires (si fournis)"))
Qu'est-ce que ça veut dire? Doit-il être corrigé? Peut-il être exploité?
Lorsque le serveur envoie son certificat au client, il envoie en fait une chaîne de certificats afin que le client trouve plus facile de valider le certificat du serveur (le client est pas requis pour utiliser exactement cette chaîne, mais, dans la pratique, la plupart des clients utiliseront la chaîne et aucune autre). Ceci est décrit dans le standard SSL/TLS , section 7.4.2, avec notamment cet extrait instructif:
Le certificat de l'expéditeur DOIT venir en premier dans la liste. Chaque certificat suivant DOIT certifier directement celui qui le précède. Étant donné que la validation de certificat nécessite que les clés racine soient distribuées indépendamment, le certificat auto-signé qui spécifie l'autorité de certification racine PEUT être omis de la chaîne, en supposant que l'extrémité distante doit déjà la posséder afin de la valider dans tous les cas.
Puisque c'est un cas "MAI" (la terminologie "MAI", "DOIT", "DEVRAIT" ... dans RFC a des significations très précises expliquées dans RFC 2119 ), le serveur est autorisé à inclure le certificat racine (ou "ancre de confiance") dans la chaîne, ou omettez-le. Certains serveurs l'incluent, d'autres non. Une implémentation client type, déterminée à utiliser exactement la chaîne envoyée, essaiera d'abord de trouver les certificats de chaîne dans son magasin de confiance; à défaut, il tentera de trouver un émetteur pour le "dernier" certificat de chaîne dans son magasin de clés de confiance. Donc, de toute façon, c'est conforme aux normes, et cela devrait fonctionner.
(Il existe une source de confusion mineure en ce qui concerne l'ordre des chaînes. En vrai X.509 , la chaîne est ordonnée de l'ancre de confiance au certificat d'entité finale. Le message "Certificat" SSL/TLS est codé dans l'ordre inverse, le certificat d'entité finale, qui qualifie le serveur lui-même, venant en premier. Ici, j'utilise "dernier" dans la terminologie SSL/TLS, pas X.509.)
La seule mauvaise chose que l'on puisse dire sur l'envoi de la racine dans la chaîne est qu'elle utilise inutilement un peu de bande passante réseau. Cela représente environ 1 Ko de données par connexion , ce qui comprend une poignée de main complète . Dans une session typique entre un client (navigateur Web) et un serveur, une seule connexion sera de ce type; les autres connexions du client utiliseront des "poignées de main abrégées" qui s'appuient sur la poignée de main initiale et n'utilisent pas du tout de certificats. Et chaque connexion sera maintenue en vie pour de nombreuses requêtes HTTP successives. Ainsi, la surcharge du réseau impliquée par l'envoi de racine est faible.
Cela signifie que les certificats fournis par le site incluent le certificat racine de la chaîne de certificats (la chaîne où un certificat est lié au certificat de son émetteur, la racine étant un certificat qui est son propre émetteur).
Comme un certificat n'est approuvé que si le certificat racine (ou un certificat intermédiaire) de sa chaîne est explicitement approuvé par le client, la fourniture du certificat racine n'est pas nécessaire: s'il est approuvé, le client l'a déjà. Le rapport, soit dit en passant, indique cela plus bas par la remarque "In trust store".
Je ne considérerais pas cela comme une raison pour un avertissement, peut-être seulement pour un indice. ssltest semble également heureux compte tenu de leur note de 100% pour le certificat.
Il pourrait y avoir eu des exploits dans l'autre sens: des sites malveillants fournissant des certificats racine faux que les clients bogués confondent avec des certificats fiables, ce qui fait que le client fait confiance au site. Les utilisateurs de ces clients ont néanmoins des problèmes.