Qu'est-ce qu'un certificat X.509 ? Comprendre cette protection vitale

Un certificat X.509 est une protection vitale contre les usurpateurs de réseaux malveillants. Sans l'authentification du serveur X.509, des attaques de type "man-in-the-middle" peuvent être lancées par des points d'accès malveillants, des routeurs compromis, etc.

X.509 est le plus utilisé pour les connexions SSL/TLS connexions pour garantir que le client (par exemple, un navigateur web) n'est pas trompé par un usurpateur malveillant se faisant passer pour un site web connu et digne de confiance.

Cependant, les certificats X.509 sécurisent les communications réseau de toutes sortes :

• Sécuriser les communications Internet
• Sécuriser les communications sur l'intranet
• Sécuriser les communications par courrier électronique
• Sécuriser les communications des appareils

Cet article n'a pas pour but d'offrir une vue d'ensemble de la norme ou du cadre X.509. Il vise plutôt à simplifier la compréhension des certificats numériques X.509 et comment ils sont utilisés pour établir des connexions sécurisées entre un client et un serveur lors de communications internet.

SSL/TLS Poignée de main 

Lors des connexions SSL/TLS , le serveur s'authentifie conformément aux protocoles d'échange et d'enregistrement. Lorsqu'il lance le protocole d'échange, le serveur présente au client un certificat X.509 signé. Dans la plupart des sessions de navigation sécurisée, seul le serveur doit être validé. L'authentification du client est moins courante, mais elle nécessite que le serveur vérifie également le certificat du client.

La signature du certificat X.509 doit être vérifiée par le client avant d'établir une connexion HTTPS. Le format requis et les informations contenues dans un certificat X.509 permettent au client d'authentifier et de vérifier en toute confiance l'intégrité de l'identité certifiée.

Magasins fiduciaires 

Les navigateurs et les applications clients s'appuient fortement sur la confiance qu'ils accordent aux autorités de certification (AC) pour la validation correcte des certificats X.509. Chaque application client et système d'exploitation (OS) maintient une liste de certificats d'autorité de certification racine de confiance, cette liste est appelée "Trust Store". Par exemple, au moment où nous écrivons ces lignes, la liste de confiance de Firefox contient 150 certificats racine qui sont automatiquement approuvés par le navigateur web.

En revanche, Google Chrome utilise le magasin de confiance du système d'exploitation sous-jacent pour déterminer si un certificat est fiable, à quelques exceptions près. Google tient à jour une liste codée en dur de certificats racine "EV-Qualified", ainsi qu'un identifiant unique qui doit figurer sur les certificats émis par cette racine. Remarque : depuis 2015, Chrome exige que tous les certificats EV utilisent la transparence des certificats.

Chaînes de confiance hiérarchiques 

Dans le cadre du processus de vérification X.509, chaque certificat doit être signé par la même autorité de certification émettrice que celle mentionnée dans le certificat. Le client doit être en mesure de suivre un chemin hiérarchique de certification qui renvoie de manière récursive à au moins une autorité de certification racine répertoriée dans la liste de confiance du client.

Toutefois, la structure du chemin de certification peut être hiérarchique (comme un arbre avec une seule autorité de certification racine) ou non hiérarchique (comme une forêt avec de nombreuses autorités de certification racine ayant fait l'objet d'une certification croisée). Il est plus facile de comprendre la certification croisée en imaginant des appels téléphoniques internationaux. Si chaque code de pays est représenté par une autorité de certification racine, les accords de certification croisée entre les autorités de certification permettent d'étendre la portée des appels. Lorsque deux autorités de certification racines signent leurs certificats respectifs, elles font intrinsèquement confiance à tous les autres certificats dans leurs chemins respectifs.

L'émetteur et l'objet d'un certificat doivent fournir des informations spécifiques pour que la certification soit valide. La norme X.509 définit ces exigences.

Champs du certificat X.509 : 

• version: Le numéro de version du certificat x.509. (en cas d'omission, la version 1 est prise en compte)
• Numéro de série: Numéro de série unique créé pour chaque certificat créé par une autorité de certification.
• signature : L'algorithme utilisé pour générer la signature. Il doit correspondre à l'algorithme de signature.
• issuer : Le nom distinctif (DN) de l'autorité de certification émettrice.
• validité : Deux dates de temps - de notBefore (date de délivrance) à notAfter (date d'expiration).
• sujet : Nom distinctif de l'entité validée à laquelle le certificat est délivré.
• subjectPublicKeyInfo : L'algorithme et la valeur de la clé publique (RSA, DSA ou Diffie-Hellman).

Champs d'extension de la version 3 de X.509 : 

• extnId : Cet élément est utilisé pour identifier cette extension.
• critique : Il s'agit d'une valeur booléenne utilisée pour indiquer si l'extension est vitale ou non.
• extnValue : Contient une chaîne d'octets pouvant être interprétée librement par une communauté utilisant une extension facultative.

Note : De nombreuses extensions permises par X.509 version 3 sont essentielles pour les relations commerciales à l'intérieur et entre les PKI domaines.

La norme X.509 ne définit pas la manière dont le contenu des certificats doit être encodé pour être stocké dans des fichiers. Cependant, deux schémas de codage sont couramment utilisés pour stocker les certificats X.509 dans des fichiers : DER et PEM.

DER (Distinguished Encoding Rules) est un schéma d'encodage d'objets de données qui peut être utilisé pour encoder des objets de certificats. DER est le format de fichier le plus répandu pour stocker les certificats X.509. Les certificats encodés en DER sont des fichiers binaires et ne peuvent pas être lus par des éditeurs de texte, mais ils peuvent être traités par les navigateurs web et certaines applications sans aucun problème.

PEM (Privacy Enhanced Mail) est un schéma de codage de courrier électronique crypté qui peut être utilisé pour convertir des certificats codés en DER en fichiers texte.

En 1988, la version 1 de la norme X.509 a été publiée. L'organisation hiérarchique des noms distinctifs suit les règles de la norme X.500. Ces règles s'inspiraient des systèmes utilisés pour attribuer les numéros de téléphone au niveau mondial.

En 1993, la version 2 de X509 a ajouté deux nouveaux champs : Issuer Unique Identifier (identifiant unique de l'émetteur) et Subject Unique Identifier (identifiant unique du sujet). Ces champs sont aujourd'hui considérés comme obsolètes par l'IETF et ne doivent pas être utilisés dans vos certificats. L'utilisation généralisée d'Internet a inspiré le développement du système de dénomination hiérarchique.

Depuis 1996, la version 3 de la norme X.509 permet d'ajouter de nombreuses extensions à un certificat. Ces extensions fournissent des informations supplémentaires sur l'utilisation des clés, les politiques et contraintes liées aux certificats, les formes de noms alternatives, etc.

Comme le mentionne Gartner, les certificats X.509 sont essentiels pour établir la confiance numérique dans le monde numérique. Sans une gestion adéquate des certificats X.509, les équipes dese, les équipes de sécurité exposent leur entreprise à des pannes, à des violations et à des échecs d'audit.

Faites Faites l'inventaire de votre système actuel de gestion des certificats X.509 de gestion des certificats certificats et évaluer si une nouvelle solution est nécessaire pour répondre l'évolution l'augmentation l'augmentation de vos certificats numériques.