Infrastructure à Clé Publique (PKI) de Base en Cryptographie

LinuxBeginner
Pratiquer maintenant

Introduction

Dans ce laboratoire, vous explorerez les fondamentaux de l'Infrastructure à Clé Publique (PKI - Public Key Infrastructure), le système qui soutient une grande partie de la sécurité sur Internet, y compris HTTPS. La PKI est un ensemble de rôles, de politiques, de matériel, de logiciels et de procédures nécessaires pour créer, gérer, distribuer, utiliser, stocker et révoquer des certificats numériques, ainsi que pour gérer le chiffrement à clé publique.

Vous acquerrez une expérience pratique avec l'outil en ligne de commande openssl pour effectuer les fonctions principales d'une PKI. Vous agirez en tant que votre propre Autorité de Certification (CA), émettrez un certificat pour un serveur web, vérifierez la chaîne de confiance du certificat, et enfin, révoquerez le certificat. Toutes les opérations seront effectuées dans le répertoire ~/project.

Comprendre les Bases de la PKI

Dans cette étape, nous allons aborder les concepts fondamentaux de la PKI. Aucune commande n'est à exécuter dans cette étape ; l'objectif est de construire une base théorique solide avant de commencer la pratique.

Infrastructure à Clé Publique (PKI)

La PKI est un cadre conçu pour améliorer la sécurité dans les communications électroniques. Elle utilise la cryptographie à clé publique pour lier les clés publiques aux identités d'utilisateurs respectives au moyen d'une Autorité de Certification (CA - Certificate Authority). Cette liaison est établie par un processus d'enregistrement et d'émission.

Autorité de Certification (CA)

Une Autorité de Certification est une entité de confiance qui délivre des certificats numériques. La CA agit comme une tierce partie de confiance, reconnue comme telle à la fois par le sujet (propriétaire) du certificat et par la partie qui se fie à ce certificat. Le rôle principal de la CA est de signer numériquement et de publier la clé publique liée à un utilisateur donné.

Certificat Numérique

Un certificat numérique est un document électronique (suivant souvent la norme X.509) qui contient :

  • La clé publique du propriétaire.
  • Les informations d'identification du propriétaire (comme un nom ou un nom d'hôte).
  • Les informations de l'émetteur (la CA) et sa signature numérique.
  • Une période de validité (date de début et de fin).
  • Un numéro de série unique.

La signature de la CA sur le certificat atteste que la clé publique contenue dans le certificat appartient à l'entité nommée dans le certificat.

Chaîne de Confiance

Une chaîne de confiance (ou chaîne de certificats) est une séquence de certificats, commençant par un certificat d'entité finale (par exemple, pour example.com) et se terminant par un certificat de CA Racine (Root CA).

  1. Certificat de CA Racine (Root CA) : Il s'agit d'un certificat auto-signé de l'autorité ultime, la CA Racine. Ces certificats sont préinstallés dans le "magasin de confiance" (trust store) de votre navigateur ou de votre système d'exploitation.
  2. Certificat(s) de CA Intermédiaire(s) : Les grandes CA utilisent souvent des CA intermédiaires pour délivrer des certificats aux utilisateurs finaux, protégeant ainsi la clé racine. Un certificat intermédiaire est signé par la CA Racine.
  3. Certificat d'Entité Finale : C'est le certificat délivré à un serveur ou un utilisateur spécifique. Il est signé par une CA intermédiaire (ou directement par la CA Racine dans des configurations plus simples).

Lorsque votre navigateur reçoit le certificat d'un serveur, il vérifie la signature en examinant le certificat de l'émetteur. Il suit cette chaîne jusqu'à atteindre une CA Racine qui est déjà présente dans son magasin de confiance. Si la chaîne est valide et que toutes les signatures correspondent, le serveur est considéré comme digne de confiance.

Dans l'étape suivante, vous créerez votre propre CA Racine.

Créer une Autorité de Certification

Dans cette étape, vous agirez en tant qu'Autorité de Certification (CA) et créerez ses composants fondamentaux : une clé privée et un certificat racine auto-signé. Toutes les commandes seront exécutées dans le terminal, et tous les fichiers seront créés dans votre répertoire courant, ~/project.

Premièrement, générez la clé privée de la CA. Cette clé est le secret le plus critique de la PKI ; elle est utilisée pour signer tous les certificats émis par la CA.

openssl genpkey -algorithm RSA -out ca.key

Ensuite, vous allez créer un certificat racine auto-signé. Un certificat racine est auto-signé car il est l'ancre ultime de confiance ; il n'y a pas d'autorité supérieure pour le signer.

Exécutez la commande suivante pour générer le certificat. Nous utilisons l'argument -subj pour fournir les informations du sujet du certificat de manière non interactive.

openssl req -x509 -new -nodes -key ca.key -sha256 -days 365 -out ca.pem -subj "/C=US/ST=California/L=MountainView/O=MyLab/CN=MyLabRootCA"

Décortiquons cette commande :

  • req: Utilitaire pour la Demande de Signature de Certificat (CSR - Certificate Signing Request) et la génération de certificats.
  • -x509: Produit un certificat auto-signé au lieu d'une CSR.
  • -new: Crée un nouveau certificat.
  • -nodes: "No DES", ce qui signifie que la clé privée ne sera pas chiffrée avec une phrase de passe (passphrase). Ceci est fait pour simplifier dans notre laboratoire.
  • -key ca.key: Spécifie la clé privée à utiliser pour la signature.
  • -sha256: Utilise l'algorithme de hachage SHA-256 pour la signature.
  • -days 365: Définit la période de validité du certificat à 365 jours.
  • -out ca.pem: Spécifie le fichier de sortie pour le nouveau certificat.
  • -subj "/C=.../CN=...": Fournit les détails du sujet. CN (Common Name - Nom Commun) est l'identité principale, qui, pour une CA, est son nom.

Vous disposez maintenant d'une clé privée de CA (ca.key) et d'un certificat racine (ca.pem). Vous pouvez inspecter le contenu de votre nouveau certificat de CA :

openssl x509 -in ca.pem -text -noout

Faites défiler la sortie et remarquez que les champs Issuer (Émetteur) et Subject (Sujet) sont identiques, confirmant qu'il est auto-signé.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            ...
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, ST = California, L = MountainView, O = MyLab, CN = MyLabRootCA
        Validity
            Not Before: ...
            Not After : ...
        Subject: C = US, ST = California, L = MountainView, O = MyLab, CN = MyLabRootCA
        Subject Public Key Info:
            ...

Délivrer un Certificat Serveur

Dans cette étape, vous simulerez un propriétaire de serveur demandant un certificat. Vous allez générer une clé privée et une Demande de Signature de Certificat (CSR - Certificate Signing Request) pour le serveur, puis utiliser votre CA de l'étape précédente pour signer la CSR et émettre un certificat valide.

Premièrement, générez une clé privée pour le serveur. Cette clé doit rester secrète sur le serveur lui-même.

openssl genpkey -algorithm RSA -out server.key

Ensuite, créez une Demande de Signature de Certificat (CSR). Une CSR est un bloc de texte encodé contenant la clé publique et d'autres informations qui seront incluses dans le certificat, telles que le nom de l'organisation et le nom de domaine. La CSR est envoyée à la CA pour signature.

openssl req -new -key server.key -out server.csr -subj "/C=US/ST=California/L=MountainView/O=MyWebServer/CN=example.com"

Notez que pour un certificat de serveur, le CN (Common Name - Nom Commun) doit correspondre au nom de domaine du serveur, dans ce cas, example.com.

Maintenant, en agissant en tant que CA, vous allez signer la CSR du serveur (server.csr) avec la clé privée de votre CA (ca.key). Cette action crée le certificat serveur final (server.crt).

openssl x509 -req -in server.csr -CA ca.pem -CAkey ca.key -CAcreateserial -out server.crt -days 300 -sha256

Examinons les nouvelles options :

  • x509 -req: Indique à OpenSSL de traiter une CSR.
  • -in server.csr: Le fichier CSR d'entrée.
  • -CA ca.pem: Le certificat de la CA à utiliser comme émetteur.
  • -CAkey ca.key: La clé privée de la CA pour la signature.
  • -CAcreateserial: Ceci crée et gère un fichier de numéro de série (ca.srl), ce qui est requis pour garantir que chaque certificat émis par la CA possède un numéro de série unique.
  • -days 300: La validité pour le certificat serveur. Celle-ci devrait être plus courte que la validité du certificat de la CA.

Enfin, inspectez le certificat serveur nouvellement créé.

openssl x509 -in server.crt -text -noout

Dans la sortie, observez les champs Issuer (Émetteur) et Subject (Sujet). L'Issuer devrait être votre CA (MyLabRootCA), et le Subject devrait être votre serveur (example.com). Ceci confirme que le certificat a été correctement émis par votre CA.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: ...
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, ST = California, L = MountainView, O = MyLab, CN = MyLabRootCA
        Validity
            Not Before: ...
            Not After : ...
        Subject: C = US, ST = California, L = MountainView, O = MyWebServer, CN = example.com
        ...
    Signature Algorithm: sha256WithRSAEncryption
         ...

Vérifier la Chaîne de Certificats

Dans cette étape, vous apprendrez comment vérifier une chaîne de certificats. C'est le processus qu'un client (comme un navigateur web) effectue pour déterminer si le certificat d'un serveur est digne de confiance. Le client vérifie si le certificat a été signé par une CA en laquelle il a confiance.

Vous pouvez utiliser la commande openssl verify pour effectuer cette vérification. Vous devez indiquer à OpenSSL quelles CA vous faites confiance en fournissant le certificat racine.

Exécutez la commande suivante pour vérifier server.crt par rapport à votre certificat racine ca.pem :

openssl verify -CAfile ca.pem server.crt

Le résultat attendu est :

server.crt: OK

Ce statut OK confirme que :

  1. Le certificat server.crt a bien été signé par la clé privée correspondant à la clé publique dans ca.pem.
  2. Le certificat n'a pas expiré.

Voyons maintenant ce qui se passe si le vérificateur n'a pas notre CA dans sa liste de CA de confiance. Vous pouvez simuler cela en exécutant la commande verify sans l'option -CAfile.

openssl verify server.crt

Cette fois, la commande échouera avec une erreur similaire à celle-ci :

C = US, ST = California, L = MountainView, O = MyWebServer, CN = example.com
error 20 at 0 depth lookup: unable to get local issuer certificate
error server.crt: verification failed

L'erreur "unable to get local issuer certificate" (impossible d'obtenir le certificat de l'émetteur local) signifie que le système n'a pas pu trouver le certificat de l'émetteur (MyLabRootCA) dans son magasin de confiance par défaut. Cela démontre pourquoi il est essentiel que les clients possèdent le certificat de la CA racine pour établir une chaîne de confiance.

Simuler la Révocation de Certificat

Dans cette étape, vous apprendrez comment révoquer un certificat. La révocation est un processus critique lorsqu'une clé privée de certificat est compromise, ou lorsque le certificat n'est plus nécessaire avant son expiration naturelle. Ceci est géré à l'aide d'une Liste de Révocation de Certificats (CRL - Certificate Revocation List).

Une CRL est une liste signée numériquement, émise par une CA, qui contient les numéros de série de tous les certificats qu'elle a révoqués. Les clients peuvent télécharger la CRL pour vérifier si un certificat qu'ils ont reçu est toujours valide.

Pour gérer la révocation, openssl a besoin d'un petit fichier de configuration pour savoir où trouver les fichiers de base de données de la CA (index.txt et serial). Le script de configuration pour ce laboratoire a déjà créé le répertoire nécessaire (my-ca) et les fichiers. Créez maintenant le fichier de configuration.

Utilisez la commande cat pour créer my-ca.conf :

cat << EOF > my-ca.conf
[ ca ]
default_ca = CA_default

[ CA_default ]
dir = ./my-ca
database = \$dir/index.txt
serial = \$dir/serial
private_key = ca.key
certificate = ca.pem
default_md = sha256
policy = policy_anything
crl_extensions = crl_ext
default_crl_days = 30

[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

[ crl_ext ]
authorityKeyIdentifier=keyid:always
EOF

Ce fichier de configuration indique à OpenSSL comment fonctionner en tant qu'Autorité de Certification. Voici ce que fait chaque section :

  • default_ca = CA_default: Pointeur vers la section de configuration principale de la CA.
  • dir = ./my-ca: Répertoire de travail de la CA pour les fichiers de base de données
  • database = $dir/index.txt: Base de données des certificats (suit les certificats émis/révoqués)
  • serial = $dir/serial: Fichier de numéro de série pour les identifiants uniques de certificat
  • private_key = ca.key: Clé privée de la CA pour la signature des certificats
  • certificate = ca.pem: Le certificat propre à la CA
  • default_md = sha256: Algorithme de hachage pour les signatures (SHA-256)
  • policy = policy_anything: Règles de validation des certificats
  • crl_extensions = crl_ext: Options de formatage de la CRL
  • default_crl_days = 30: Période de validité de la CRL (30 jours)
  • countryName = optional: Code pays
  • stateOrProvinceName = optional: État/province
  • localityName = optional: Ville/localisation
  • organizationName = optional: Nom de l'organisation
  • organizationalUnitName = optional: Département
  • commonName = supplied: Nom de domaine/serveur (requis)
  • emailAddress = optional: Adresse e-mail
  • authorityKeyIdentifier=keyid:always: Inclut l'identifiant de la CA dans les CRL pour la vérification

Ce fichier de configuration est le "manuel d'exploitation" de votre CA. Il indique à OpenSSL où trouver les clés, comment stocker les certificats et quelles règles suivre pour l'émission et la révocation des certificats.

Maintenant, révoquez le certificat serveur (server.crt). Cette commande recherchera le numéro de série du certificat et le marquera comme révoqué dans le fichier de base de données index.txt.

openssl ca -config my-ca.conf -revoke server.crt

Vous verrez une sortie confirmant la révocation.

Après la révocation, vous devez générer et publier une CRL mise à jour.

openssl ca -config my-ca.conf -gencrl -out my-ca.crl

Ceci crée le fichier my-ca.crl, qui contient la liste des certificats révoqués.

Enfin, essayons de vérifier à nouveau le certificat serveur, mais cette fois, nous fournirons également la CRL. Un processus de vérification approprié doit vérifier la révocation.

openssl verify -CAfile ca.pem -CRLfile my-ca.crl -crl_check server.crt

La commande échoue maintenant avec un message clair :

C = US, ST = California, L = MountainView, O = MyWebServer, CN = example.com
error 23 at 0 depth lookup: certificate revoked
error server.crt: verification failed

L'erreur "certificate revoked" (certificat révoqué) confirme que notre processus de révocation a réussi. Le client, lors de la vérification de la CRL, a correctement identifié que le certificat pour example.com n'est plus digne de confiance.

Résumé

Félicitations ! Vous avez terminé avec succès ce laboratoire sur les bases de l'Infrastructure à Clé Publique (PKI). Vous avez acquis une expérience pratique des opérations fondamentales qui sécurisent les communications numériques.

Dans ce laboratoire, vous avez appris à :

  • Comprendre les concepts fondamentaux de la PKI, des Autorités de Certification (CA) et des chaînes de confiance.
  • Créer votre propre CA Racine simple en générant une clé privée et un certificat auto-signé.
  • Émettre un certificat serveur en signant une Demande de Signature de Certificat (CSR - Certificate Signing Request) avec la clé de votre CA.
  • Vérifier la chaîne de confiance d'un certificat en utilisant la commande openssl verify.
  • Révocation d'un certificat et confirmation de son statut révoqué en générant et en utilisant une Liste de Révocation de Certificats (CRL).

Ces compétences constituent les éléments de base pour gérer des systèmes sécurisés et comprendre comment la confiance est établie sur Internet.