La norme de sécurité internet SSL/TLS est basée sur un modèle de relation de confiance, également appelé "chaîne de confiance des certificats".
Les certificats numériques x.509 valident l'identité d'un site web, d'une organisation ou d'un serveur et fournissent une plateforme de confiance permettant à l'utilisateur de se connecter et de partager des informations en toute sécurité.
SSL/TLS L'infrastructure à clé publique basée sur l'internet (PKI ) permet aux utilisateurs d'échanger des données à l'aide de paires de clés publiques et privées, obtenues et échangées par une autorité de certification (AC) de confiance. Cette entité de confiance est responsable de l'émission, de la conservation et de la révocation des certificats de clé publique sur les réseaux non sécurisés.
Lorsque vous visitez un site web via une connexion sécurisée, le site envoie un certificat numérique à votre navigateur. Votre navigateur internet compare l'émetteur avec une liste d'autorités de certification de confiance(Root CA). Si aucune correspondance n'est trouvée, le navigateur client vérifie si une autorité de certification racine de confiance signe le certificat de l'autorité de certification émettrice. Le moteur de chaînage du navigateur continue à vérifier l'émetteur de chaque certificat jusqu'à ce qu'il trouve une autorité de certification racine de confiance ou qu'il atteigne la fin de la chaîne de confiance.
La certification de la chaîne de confiance vise à prouver qu'un certificat particulier provient d'une source fiable.
Si le certificat est légitime et renvoie à une autorité de certification racine dans le Truststore du navigateur du client, l'utilisateur saura que le site web est sûr sur la base des indicateurs de confiance de l'interface, comme indiqué ci-dessous.
Indicateurs de confiance du navigateur web
Toutefois, supposons que la vérification de la chaîne de confiance échoue. Dans ce cas, un certificat ne peut pas prouver sa validité à lui seul et le navigateur avertit l'utilisateur d'un risque de sécurité potentiel, comme indiqué ci-dessous.
Avertissement concernant un site web non sécurisé
Toutefois, les certificats privés PKI ne sont pas reconnus globalement par les principaux systèmes d'exploitation, navigateurs web ou applications. Bien qu'ils puissent émettre des certificats X.509 en interne, seuls les certificats d'une autorité de certification reconnue publiquement peuvent empêcher le navigateur d'envoyer des messages d'avertissement.
3 entités de base = chaîne de confiance
Il existe trois types d'entités de base qui constituent une chaîne de confiance valide : L'entité racine, l'entité intermédiaire et l'entité finale. Nous allons examiner de plus près chacun de ces types d'entités dans la section suivante.
Certificat racine : L'ancre de confiance
Un certificat racine est un certificat auto-signé qui suit les normes du certificat X.509. Une chaîne de confiance hiérarchique à plusieurs niveaux permet aux clients et aux applications web de vérifier qu'une source de confiance a validé l'identité de l'entité finale.
Si la clé privée de l'ancre de confiance est compromise, tous les certificats signés sous cette clé privée seront compromis et tous les certificats émis par cette AC seront affectés. L'autorité de certification devra donc réémettre de nouveaux certificats à chaque autorité de certification intermédiaire et à chaque entité finale de la chaîne de certificats.
Par conséquent, l'autorité de certification racine doit surveiller de près sa clé privée et signer rarement des certificats d'entités finales directement. Au lieu de cela, l'autorité racine créera et signera une ou plusieurs autorités de certification intermédiaires pour émettre des certificats et les relier à l'autorité de certification racine.
Certificat intermédiaire : L'autorité de certification émettrice
Au moins un certificat intermédiaire sera presque toujours présent dans une chaîne de certificatsSSL . Ils constituent un lien vital qui permet à l'autorité de certification racine d'étendre sa réputation de confiance à des entités finales qui ne le sont pas.
L'autorité de certification émettrice sert d'intermédiaire entre le certificat racine sécurisé et le certificat du serveur. Cela permet à l'autorité de certification racine de rester stockée hors ligne en toute sécurité, ce qui offre un niveau de sécurité supplémentaire.
La confiance dans l'autorité de certification racine est toujours explicite. Chaque système d'exploitation, les navigateurs web tiers et les applications personnalisées sont livrés avec plus de 100 certificats d'autorité de certification racine de confiance préinstallés. En revanche, les certificats non racine sont implicitement approuvés et ne doivent pas être livrés avec un système d'exploitation, un navigateur web ou une application compatible avec les certificats.
Certificat de serveur : L'entité finale
Les certificats de serveur assurent la sécurité, l'évolutivité et la conformité aux normes de l'autorité de certification. Cependant, les certificats ne garantissent pas que le sujet est digne de confiance, qu'il a une bonne réputation dans ses relations d'affaires, qu'il est en conformité avec la loi ou qu'il est sûr de faire des affaires avec lui.
L'entité finale fournit des informations critiques à l'AC émettrice via un formulaire de demande de signature de certificat. Le certificat est ensuite signé et délivré par une autorité de certification de confiance, attestant que les informations fournies étaient correctes au moment de la délivrance. La connexion SSL à un serveur échouera si le certificat n'a pas été vérifié et signé.
Les abonnés au certificat de serveur ne sont pas toujours la partie au certificat ; l'utilisation des cas varie en fonction des exigences de l'environnement du certificat. Le certificat délivré à une organisation pour ses employés vérifie uniquement que l'autorité de certification a authentifié les informations demandées à un représentant de cette organisation, et non à chaque employé.
Par exemple, une AC racine peut émettre des certificats qui identifient un rôle spécifique que l'abonné occupe au lieu d'une personne particulière (par exemple, le "directeur de l'information" est une personne unique, alors que le "membre du personnel informatique" ne l'est pas). Ce type de certificat basé sur le rôle est utilisé lorsque la non-répudiation est souhaitée.
L'autorité de certification racine peut également émettre un certificat de groupe lorsque plusieurs abonnés partagent un certificat de clé privée.
Si plusieurs entités agissent en une seule capacité, l'AC doit tenir à jour une liste des abonnés qui ont accès à la clé privée et rendre compte de la période pendant laquelle chaque abonné a le contrôle de la clé.
Utilisation de la clé du certificat CA
Les autorités de certification peuvent remplir des fonctions liées aux services privés PKI et aux opérations de clé publique, y compris la réception des demandes de certificats applicables, la délivrance, la révocation et le renouvellement des certificats numériques.
Vous avez peut-être remarqué que les AC intermédiaires sont fonctionnellement similaires à l'AC racine. Cependant, elles ont souvent moins de fonctions d'utilisation des clés activées. Un certificat X.509 valide provenant d'un émetteur de confiance n'est valable que pour l'utilisation spécifiée dans les politiques de certification. Les certificats conformes à ces règles de politique de chaîne peuvent encore être invalides pour d'autres utilisations avec des fonctions telles que Security / MIME (SMIME), Authenticode ou Secure Sockets Layer (SSL). Un traitement supplémentaire peut être nécessaire pour déterminer si le certificat est valide pour une politique spécifique.
Le certificat intermédiaire contient des extensions d'utilisation de la clé qui définissent les utilisations possibles du certificat.
L'objet du certificat peut être l'un des quatre paramètres d'utilisation des clés et champs d'utilisation des clés étendus identifiés dans le certificat :
- Cryptage : Les clés cryptographiques pour le cryptage et le décryptage seront incluses dans un certificat à cette fin.
- Signature : Le certificat utilisé à cette fin contiendra des clés cryptographiques pour la signature des données uniquement.
- Signature et cryptage: Un certificat à cette fin doit couvrir toutes les utilisations primaires de la clé cryptographique du certificat, y compris le cryptage et le décryptage des données, la connexion initiale ou la signature numérique.
- Signature logon et smartcard logon : Le certificat prévu à cet effet permet la connexion initiale de la carte à puce et la signature numérique des données ; il ne peut pas être utilisé pour le cryptage des données.
Trois types de modèles de confiance
Modèle de confiance hiérarchique
Il y aura une autorité de certification racine et une ou plusieurs autorités de certification subordonnées. Les AC subordonnées assurent la redondance et l'équilibrage de la charge, tandis que l'AC racine est généralement hors ligne. Dans ce cas, même si l'autorité de certification subordonnée est compromise, l'autorité de certification racine peut révoquer l'autorité de certification subordonnée, assurant ainsi la redondance.
La toile de confiance
Il s'agit également d'un modèle de certification croisée. Les autorités de certification établissent ici une relation d'égal à égal. Ce modèle est difficile à gérer lorsque le nombre d'autorités de certification augmente. Ce type de relation de confiance peut se produire lorsque différentes divisions de l'entreprise disposent de différentes autorités de certification et qu'elles doivent travailler ensemble.
Architecture CA Bridge
L'AC relais permet de surmonter la complexité du modèle du Web of Trust. Dans ce cas, l'AC relais joue le rôle de point central de coordination. Toutes les autres AC (appelées "Principaux") ne doivent faire confiance qu'à l'AC relais.
Construction de la chaîne de confiance des certificats
Le certificat de l'autorité de certification racine est localisé en reconstruisant le chemin de certification. Lorsqu'un ordinateur trouve plusieurs chemins de certification fiables au cours du processus de validation des certificats, le moteur de chaîne de certification recherche le meilleur chemin de certification en calculant le score de chaque chaîne. La note est calculée en fonction de la qualité et de la quantité d'informations que le chemin d'accès au certificat peut fournir. Si les scores de plusieurs chemins de certification sont identiques, la chaîne la plus courte sera sélectionnée.
Le système d'exploitation Windows permet d'utiliser les quatre méthodes suivantes pour récupérer des certificats à partir de chaînes de certificats :
- Par l'intermédiaire du magasin de certificats local ;
- Utilisez un conteneur PKCS#7 avec une chaîne complète ou partielle ;
- Utiliser l'extension de l'accès à l'information de l'autorité (AIA) ;
- Crypt32.dll et le site web de Microsoft Update.
Examinons de plus près chacune de ces méthodes.
Méthode du magasin de certificats local
CryptoAPI utilise la recherche dans le magasin de certificats local pour obtenir le certificat requis, ce qui réduit le temps nécessaire à la construction de la chaîne de certificats. Toutefois, cela ne s'applique qu'aux certificats CA qui ont déjà été installés par un fournisseur d'application (par exemple, un système d'exploitation ou un fournisseur de navigateur). Si le magasin de certificats local ne contient pas les certificats requis, d'autres méthodes de recherche de certificats seront tentées.
Méthode PKCS#7
La méthode de récupération des certificats PKCS#7 est très répandue sur Internet. Un message PKCS#7 peut stocker plusieurs certificats et faire office de conteneur de certificats. Cette méthode permet aux applications serveur de simplifier la construction d'une chaîne de certificats en fournissant un certificat de chaîne de certificats complet ou partiel. Les principaux serveurs web, Apache et Microsoft IIS, envoient tous les certificats par défaut, et aucune configuration supplémentaire n'est nécessaire pour prendre en charge PKCS#7.
Un comportement similaire peut être observé lors de l'exploration des signatures d'Authenticode. Lors de la signature d'un fichier binaire, une chaîne de certificats peut être incluse dans la signature, et ces certificats seront utilisés pour construire une chaîne en validant chaque signature. Bien que cette méthode soit bénéfique, elle n'est pas toujours disponible pour les applications. Par exemple, lors de la connexion au VPN SSTP, le serveur VPN n'envoie pas de certificats intermédiaires au client.
Crypt32.dll et Microsoft Update
Si votre ordinateur est connecté à l'internet, le moteur de la chaîne de certification vérifie le site web Microsoft Update. S'il le trouve (comme dans l'exemple ci-dessus), il le télécharge et l'installe dans le magasin de certificats. Si votre ordinateur n'est pas connecté à Internet, le moteur de la chaîne de certification extrait le contenu du certificat de la bibliothèque crypt32.dll et installe le certificat dans le conteneur Trusted Root CAs.