Certificat racine SSL en option?
J'ai peut-être eu une mauvaise impression sur la façon dont les serveurs doivent être configurés et quels certificats sont réellement envoyés pendant le message de certificat de bonjour du serveur. Je suis tombé sur cela aujourd'hui de Symantec/VeriSign:
Racine installée sur le serveur. Pour les meilleures pratiques, supprimez la racine auto-signée du serveur. L'ensemble de certificats ne doit inclure que la clé publique du certificat et la clé publique de toute autorité de certification intermédiaire. Les navigateurs ne feront confiance qu'aux certificats qui se résolvent en racines qui sont déjà dans leur magasin de confiance, ils ignoreront un certificat racine envoyé dans le paquet de certificats (sinon, n'importe qui pourrait envoyer n'importe quelle racine).
Si cela est vrai et que le certificat racine n'a pas besoin d'être installé sur le serveur, eh bien, voici ce que je pensais savoir sur la configuration correcte du serveur et comment la chaîne est validée à la racine. Là encore, quand je repense à cette question , sous la section Certificats et authentification de réponse de Thomas Pornin il dit:
Le client est donc censé faire ce qui suit:
- Obtenez une chaîne de certificats se terminant par le certificat du serveur. Le message de certificat du serveur est censé contenir précisément une telle chaîne.
Cela indique à peu près le contraire du message Symantec/VeriSign ci-dessus, à moins que je ne comprenne quelque chose. Donc:
Un serveur a-t-il besoin d'installer la chaîne complète, y compris la racine? Si ce n'est pas le cas, à quoi un navigateur se compare-t-il pour la validation puisque le serveur ne fournira pas son certificat racine pendant la prise de contact? Regarde-t-il simplement le certificat d'identité et l'obtient-il de là? (Comme ouvrir un certificat d'identité sur votre machine locale et voir la chaîne complète dans le chemin de certification?)
Encore une fois, si cela est vrai, qu'en est-il des applications client autonomes qui utilisent des bibliothèques SSL? Cela dépendra-t-il de l'application, car elle peut avoir différentes méthodes de création de chemin vers une racine de confiance par rapport à un navigateur?
Le serveur envoie toujours une chaîne. Selon la norme TLS , la chaîne peut ou non inclure le certificat racine lui-même; le client n'a pas besoin de cette racine car il l'a déjà. Et, en effet, si le client n'a pas déjà la racine, alors la recevoir du serveur ne serait d'aucune utilité car une racine ne peut être approuvée qu'en raison d'être déjà là .
Ce que Symantec dit, c'est qu'ils recommandent de ne pas envoyer la racine, seulement le reste de la chaîne. Cela a du sens: puisque la racine est inutile à des fins de validation, vous pouvez également éviter de l'envoyer et enregistrer environ 1 ko de bande passante de données par connexion.
En tous cas:
Le certificat du serveur, avec sa chaîne, n'est pas pour le serveur. Le serveur n'a aucune utilité pour son propre certificat. Les certificats sont toujours pour d'autres personnes (ici, le client). Ce qui est utilisé par le serveur est sa clé privée (qui correspond à la clé publique dans son certificat). En particulier, le serveur n'a pas besoin d'approuver son propre certificat ou toute autorité de certification qui l'a émis.
Dans TLS, le serveur est censé envoyer une chaîne; et le client est censé en quelque sorte utiliser la clé publique du serveur pour la prise de contact. Le client est libre de "connaître" cette clé publique de la manière qu'il souhaite, bien que l'on s'attende bien sûr à ce que le client obtienne la clé publique du serveur à partir de la chaîne de certificats que le serveur vient d'envoyer. Les navigateurs essaieront principalement d'utiliser la chaîne envoyée par le serveur (en essayant de la lier en dessous d'une des racines déjà approuvées par le navigateur); en cas d'échec, ils essaieront de construire d'autres chaînes basées sur des certificats CA intermédiaires qu'ils connaissent déjà ou peuvent télécharger à la volée.
Dans les applications autonomes, les rédacteurs d'applications sont libres de configurer ou de contourner cette étape de manière arbitraire, ce qui peut être utile si la clé publique du serveur peut être codée en dur dans le code de l'application (auquel cas la chaîne envoyée par le serveur est simplement complètement ignorée ). Malheureusement, la liberté d'implémenter une étape de validation de certificat personnalisé est également la liberté de bloquer la sécurité, de la poignarder à mort puis de jeter son cadavre dans un fossé. Cela arrive trop souvent.
à quoi un navigateur peut-il se comparer pour la validation puisque le serveur ne fournira pas son certificat racine pendant la poignée de main
L'idée générale de la vérification des certificats est que les clients ont des certificats racine en lesquels ils ont confiance (livrés avec le navigateur ou le système d'exploitation) et qu'ils valident le certificat que le navigateur envoie par rapport à cette ancre de confiance locale.
Cela signifie que le serveur n'a pas besoin (et ne devrait pas) envoyer le certificat racine au client, car ce certificat racine est censé être déjà à la fin du client. S'il envoie toujours le certificat racine, le client le rejettera simplement, c'est-à-dire qu'il ne fera confiance à aucun certificat racine envoyé par le serveur.
Encore une fois, si cela est vrai, qu'en est-il des applications client autonomes qui utilisent des bibliothèques SSL? Cela dépendra-t-il de l'application, car elle peut avoir différentes méthodes de création de chemin vers une racine de confiance par rapport à un navigateur?
Le processus de vérification de base entre les navigateurs et les bibliothèques SSL est le même. Il existe quelques différences dans la création de chemin dans les cas Edge entre openssl et les navigateurs (voir http://rt.openssl.org/Ticket/Display.html?id=2732&user=guest&pass=guest ) et la vérification du nom d'hôte de la cible par rapport au (x) nom (s) dans le certificat des serveurs est souvent bogué ou même inexistant en dehors des navigateurs courants.
J'envoie la racine quand cela convient.
Si le client fait confiance à la racine, cela ne fait aucune différence que vous l'envoyiez ou non.
Lorsque le client ne reconnaît pas la racine, d'après mon expérience, le client MS Windows produit des messages de diagnostic beaucoup moins déroutants si la racine non approuvée a été fournie dans la chaîne.
Quant à savoir comment il sait quelle racine utiliser si aucune n'est fournie, la prochaine racine (qui doit être dans la chaîne fournie) contient les informations d'identification de la racine, que le client utilise pour rechercher la racine dans le magasin du client.
Tenez compte du fait qu'il existe un logiciel serveur (comme IBM HTTP Server) qui ne démarre pas du tout si l'autorité de certification racine n'est pas incluse dans le fichier de clés.