Comment installer et configurer une autorité de certification (CA) sur Debian 11

Introduction

Une autorité de certification (CA) est une entité chargée de délivrer des certificats numériques pour vérifier les identités sur Internet. Bien que les autorités de certification publiques soient un choix populaire pour vérifier l’identité des sites Web et d’autres services fournis au grand public, les autorités de certification privées sont généralement utilisées pour les groupes fermés et les services privés.

La création d’une autorité de certification privée vous permettra de configurer, de tester et d’exécuter des programmes qui nécessitent des connexions cryptées entre un client et un serveur. Avec une autorité de certification privée, vous pouvez émettre des certificats pour des utilisateurs, des serveurs ou des programmes et services individuels au sein de votre infrastructure.

Quelques exemples de programmes sous Linux qui utilisent leur propre autorité de certification privée sont OpenVPN et Puppet . Vous pouvez également configurer votre serveur Web pour utiliser des certificats émis par une autorité de certification privée afin de faire correspondre les environnements de développement et de staging aux serveurs de production qui utilisent TLS pour chiffrer les connexions.

Dans ce guide, vous allez configurer une autorité de certification privée sur un serveur Debian 11 et générer et signer un certificat de test à l’aide de votre nouvelle autorité de certification. Vous importerez également le certificat public du serveur CA dans le magasin de certificats de votre système d’exploitation afin de pouvoir vérifier la chaîne de confiance entre l’autorité de certification et les serveurs ou utilisateurs distants. Enfin, vous révoquerez un certificat et distribuerez une liste de révocation de certificats (CRL) pour vous assurer que seuls les utilisateurs et les systèmes autorisés peuvent utiliser les services qui dépendent de votre autorité de certification.

Étape 1 - Installation d’Easy-RSA

La première tâche de ce didacticiel consiste à installer l’utilitaire easy-rsa sur votre serveur CA. Easy-RSA est un outil de gestion d’autorité de certification que vous utiliserez pour générer une clé privée et un certificat racine public, que vous utiliserez ensuite pour signer les demandes des clients et des serveurs qui s’appuieront sur votre autorité de certification.

Connectez-vous à votre serveur CA en tant qu’utilisateur sudo non root que vous avez créé lors des étapes de configuration initiales et exécutez ce qui suit :

sudo apt update
sudo apt install easy-rsa

Vous serez invité à télécharger le package et à l’installer. Appuyez sur ++y++ pour confirmer que vous souhaitez installer le package.

À ce stade, vous avez tout ce dont vous avez besoin configuré et prêt à utiliser Easy-RSA. À l’étape suivante, vous allez créer une infrastructure à clé publique, puis commencer à créer votre autorité de certification.

Étape 2 - Préparation d’un répertoire d’infrastructure à clé publique

Maintenant que vous avez installé easy-rsa, il est temps de créer un squelette d’infrastructure à clé publique (PKI) sur le serveur CA. Assurez-vous que vous êtes toujours connecté en tant qu’utilisateur non root et créez un répertoire easy-rsa. Assurez-vous de ne pas utiliser sudo pour exécuter l’une des commandes suivantes, car votre utilisateur normal doit gérer et interagir avec l’autorité de certification sans privilèges élevés.

mkdir ~/easy-rsa

Cela créera un nouveau répertoire appelé easy-rsa dans votre dossier personnel. Nous utiliserons ce répertoire pour créer des liens symboliques pointant vers les fichiers du package easy-rsa que nous avons installés à l’étape précédente. Ces fichiers se trouvent dans le dossier /usr/share/easy-rsa sur le serveur CA.

Créez les liens symboliques avec la commande ln :

ln -s /usr/share/easy-rsa/* ~/easy-rsa/

Remarque : Alors que d’autres guides peuvent vous demander de copier les fichiers du package easy-rsa dans votre répertoire PKI, ce didacticiel adopte une approche de lien symbolique. Par conséquent, toute mise à jour du package easy-rsa sera automatiquement reflétée dans les scripts de votre PKI.

Pour restreindre l’accès à votre nouveau répertoire PKI, assurez-vous que seul le propriétaire peut y accéder à l’aide de la commande chmod :

chmod 700 /home/sammy/easy-rsa

Enfin, initialisez la PKI dans le répertoire easy-rsa :

cd ~/easy-rsa
./easyrsa init-pki

init-pki complete; you may now create a CA or requests.
Your newly created PKI dir is: /home/sammy/easy-rsa/pki

Après avoir terminé cette section, vous disposez d’un répertoire contenant tous les fichiers nécessaires à la création d’une autorité de certification. Dans la section suivante, vous allez créer la clé privée et le certificat public pour votre autorité de certification.

Étape 3 - Création d’une autorité de certification

Avant de pouvoir créer la clé privée et le certificat de votre autorité de certification, vous devez créer et remplir un fichier appelé vars avec certaines valeurs par défaut. Vous allez d’abord cd dans le répertoire easy-rsa, puis vous allez créer et modifier le fichier vars avec nano ou votre éditeur de texte préféré :

cd ~/easy-rsa
nano vars

Une fois le fichier ouvert, collez les lignes suivantes et modifiez chaque valeur en surbrillance pour refléter les informations de votre propre organisation. L’important ici est de s’assurer que vous ne laissez aucune des valeurs vides :

~/easy-rsa/vars
set_var EASYRSA_REQ_COUNTRY    "US"
set_var EASYRSA_REQ_PROVINCE   "NewYork"
set_var EASYRSA_REQ_CITY       "New York City"
set_var EASYRSA_REQ_ORG        "DigitalOcean"
set_var EASYRSA_REQ_EMAIL      "admin@example.com"
set_var EASYRSA_REQ_OU         "Community"
set_var EASYRSA_ALGO           "ec"
set_var EASYRSA_DIGEST         "sha512" 

Lorsque vous avez terminé, enregistrez et fermez le fichier. Si vous utilisez nano, vous pouvez le faire en appuyant sur CTRL+X, puis Y et ENTER pour confirmer. Vous êtes maintenant prêt à créer votre CA.

Pour créer la paire de clés publique et privée racine pour votre autorité de certification, exécutez à nouveau la commande ./easy-rsa, cette fois avec l’option build-ca :

./easyrsa build-ca

Dans la sortie, vous verrez quelques lignes sur la version d’OpenSSL et vous serez invité à entrer une phrase secrète pour votre paire de clés. Assurez-vous de choisir une phrase de passe forte et notez-la dans un endroit sûr. Vous devrez saisir la phrase secrète chaque fois que vous aurez besoin d’interagir avec votre autorité de certification, par exemple pour signer ou révoquer un certificat.

Il vous sera également demandé de confirmer le nom commun (CN) de votre autorité de certification. Le CN est le nom utilisé pour désigner cette machine dans le contexte de l’autorité de certification. Vous pouvez entrer n’importe quelle chaîne de caractères pour le nom commun de l’autorité de certification, mais pour des raisons de simplicité, appuyez sur ENTRÉE pour accepter le nom par défaut.

Output
. . .
Enter New CA Key Passphrase:
Re-Enter New CA Key Passphrase:
. . .
Common Name (eg: your user, host, or server name) [Easy-RSA CA]:

CA creation complete and you may now import and sign cert requests.
Your new CA certificate file for publishing is at:
/home/sammy/easy-rsa/pki/ca.crt

Remarque : Si vous ne souhaitez pas être invité à saisir un mot de passe à chaque fois que vous interagissez avec votre autorité de certification, vous pouvez exécuter la commande build-ca avec l’option nopass, comme ceci :

./easyrsa build-ca nopass

Vous avez maintenant deux fichiers importants — ~/easy-rsa/pki/ca.crt et ~/easy-rsa/pki/private/ca.key — qui constituent les composants public et privé d’une autorité de certification.

• ca.crt est le fichier de certificat public de l’autorité de certification. Les utilisateurs, les serveurs et les clients utiliseront ce certificat pour vérifier qu’ils font partie du même réseau de confiance. Chaque utilisateur et serveur qui utilise votre autorité de certification devra avoir une copie de ce fichier. Toutes les parties s’appuieront sur le certificat public pour s’assurer que quelqu’un ne se fait pas passer pour un système et n’exécute pas une attaque Man-in-the-middle.

• ca.key est la clé privée que l’autorité de certification utilise pour signer les certificats des serveurs et des clients. Si un attaquant parvient à accéder à votre CA et, à son tour, à votre fichier ca.key, vous devrez détruire votre CA. C’est pourquoi votre fichier ca.key ne devrait se trouver que sur votre machine CA et pourquoi, idéalement, votre machine CA devrait être maintenue hors ligne lorsqu’elle ne signe pas de demandes de certificat comme mesure de sécurité supplémentaire.

Avec cela, votre autorité de certification est en place et prête à être utilisée pour signer des demandes de certificat et révoquer des certificats.

Étape 4 - Distribution du certificat public de votre autorité de certification

Votre autorité de certification est maintenant configurée et prête à agir en tant que racine de confiance pour tous les systèmes que vous souhaitez configurer pour l’utiliser. Vous pouvez ajouter le certificat de l’autorité de certification à vos serveurs OpenVPN, serveurs Web, serveurs de messagerie, etc. Tout utilisateur ou serveur qui doit vérifier l’identité d’un autre utilisateur ou serveur de votre réseau doit avoir une copie du fichier ca.crt importé dans le magasin de certificats de son système d’exploitation.

Pour importer le certificat public de l’AC dans un second système Linux comme un autre serveur ou un ordinateur local, obtenez d’abord une copie du fichier ca.crt de votre serveur CA. Vous pouvez utiliser la commande cat pour le sortir dans un terminal, puis le copier et le coller dans un fichier sur le deuxième ordinateur qui importe le certificat. Vous pouvez également utiliser un outil comme scp ou rsync pour transférer le fichier entre les systèmes. Nous utiliserons le copier-coller avec nano dans cette étape car cela fonctionnera sur tous les systèmes.

En tant qu’utilisateur non root sur le serveur CA, exécutez la commande suivante :

cat ~/easy-rsa/pki/ca.crt

Output
-----BEGIN CERTIFICATE-----
MIIDSzCCAjOgAwIBAgIUcR9Crsv3FBEujrPZnZnU4nSb5TMwDQYJKoZIhvcNAQEL
BQAwFjEUMBIGA1UEAwwLRWFzeS1SU0EgQ0EwHhcNMjAwMzE4MDMxNjI2WhcNMzAw
. . .
. . .
-----END CERTIFICATE-----

Copiez tout, y compris les lignes -----BEGIN CERTIFICATE----- et -----END CERTIFICATE----- et les tirets. Sur votre deuxième système Linux, utilisez nano ou votre éditeur de texte préféré pour ouvrir un fichier appelé /tmp/ca.crt :

nano /tmp/ca.crt

Collez le contenu que vous venez de copier du serveur CA dans l’éditeur. Lorsque vous avez terminé, enregistrez et fermez le fichier. Si vous utilisez nano, vous pouvez le faire en appuyant sur CTRL+X, puis Y et ENTER pour confirmer.

Maintenant que vous avez une copie du fichier ca.crt sur votre deuxième système Linux, il est temps d’importer le certificat dans son magasin de certificats du système d’exploitation.

Debian et Ubuntu like

Sur les systèmes basés sur Debian et Ubuntu, exécutez les commandes suivantes pour importer le certificat :

sudo cp /tmp/ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

Le script update-ca-certificates, situé dans /usr/sbin/update-ca-certificates sur les systèmes Debian et Ubuntu ultérieurs, peut ne pas se trouver dans le $PATH de votre utilisateur. Ajoutez /usr/sbin à votre $PATH ou exécutez simplement /usr/sbin/update-ca-certificates.

Centos, Fedora et RedHat like

Pour importer le certificat du serveur CA sur un système basé sur CentOS, Fedora ou RedHat, copiez et collez le contenu du fichier sur le système comme dans l’exemple précédent dans un fichier appelé /tmp/ca.crt. Ensuite, vous copierez le certificat dans /etc/pki/ca-trust/source/anchors/, puis exécuterez la commande update-ca-trust.

sudo cp /tmp/ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

Maintenant, votre deuxième système Linux fera confiance à tout certificat signé par le serveur CA.

Remarque : Si vous utilisez votre autorité de certification avec des serveurs Web et utilisez Firefox comme navigateur, vous devrez importer le certificat ca.crt public directement dans Firefox. Firefox n’utilise pas le magasin de certificats du système d’exploitation local. Pour plus de détails sur la façon d’ajouter le certificat de votre autorité de certification à Firefox, veuillez consulter cet article d’assistance de Mozilla sur la configuration des autorités de certification (AC) dans Firefox.

Si vous utilisez votre autorité de certification pour l’intégrer à un environnement Windows ou à des ordinateurs de bureau, veuillez consulter la documentation sur l’utilisation de certutil.exe pour installer un certificat d’autorité de certification.

Si vous utilisez ce didacticiel comme condition préalable à un autre didacticiel ou si vous savez comment signer et révoquer des certificats, vous pouvez vous arrêter ici. Si vous souhaitez en savoir plus sur la façon de signer et de révoquer des certificats, la section facultative suivante expliquera chaque processus en détail.

Étape 5 - Création de demandes de signature de certificat et révocation de certificats (facultatif)

Les sections suivantes du didacticiel sont facultatives. Si vous avez terminé toutes les étapes précédentes, vous disposez d’une autorité de certification entièrement configurée et fonctionnelle que vous pouvez utiliser comme prérequis pour d’autres didacticiels. Vous pouvez importer le fichier ca.crt de votre autorité de certification et vérifier les certificats de votre réseau qui ont été signés par votre autorité de certification.

Si vous souhaitez vous entraîner et en savoir plus sur la façon de signer des demandes de certificat et sur la façon de révoquer des certificats, ces sections facultatives expliqueront le fonctionnement des deux processus.

Étape 6 - Création et signature d’une demande de certificat de pratique (facultatif)

Maintenant que vous disposez d’une autorité de certification prête à l’emploi, vous pouvez vous entraîner à générer une clé privée et une demande de certificat pour vous familiariser avec le processus de signature et de distribution.

Une demande de signature de certificat (CSR) se compose de trois parties : une clé publique, des informations d’identification sur le système demandeur, et une signature de la demande elle-même, qui est créée à l’aide de la clé privée du demandeur. La clé privée sera gardée secrète et sera utilisée pour chiffrer des informations que toute personne disposant du certificat public signé pourra ensuite déchiffrer.

Les étapes suivantes seront exécutées sur votre deuxième système Linux exécutant Debian, Ubuntu ou une distribution dérivée de l’un ou l’autre. Il peut s’agir d’un autre serveur distant ou d’une machine Linux locale comme un ordinateur portable ou un ordinateur de bureau. Comme easy-rsa n’est pas disponible par défaut sur tous les systèmes, nous utiliserons l’outil openssl pour créer une clé privée et un certificat d’entraînement.

openssl est généralement installé par défaut sur la plupart des distributions Linux, mais juste pour être certain, exécutez ce qui suit sur votre système :

sudo apt update
sudo apt install openssl

Lorsque vous êtes invité à installer openssl, appuyez sur y pour poursuivre les étapes d’installation. Cela peut mettre à niveau vos bibliothèques OpenSSL et vous pouvez être invité à redémarrer certains services qui utilisent l’ancienne bibliothèque OpenSSL. Sélectionnez OK pour redémarrer ces services si vous le souhaitez.

Vous êtes maintenant prêt à créer un certificat CSR nommé practice avec openssl.

La première étape que vous devez effectuer pour créer un CSR est de générer une clé privée. Pour créer une clé privée à l’aide d’openssl, créez un répertoire practice-csr, puis générez une clé à l’intérieur. Nous ferons cette demande pour un serveur fictif appelé sammy-server, par opposition à la création d’un certificat utilisé pour identifier un utilisateur ou une autre autorité de certification.

mkdir ~/practice-csr
cd ~/practice-csr
openssl genrsa -out sammy-server.key

Output
Generating RSA private key, 2048 bit long modulus (2 primes)
. . .
. . .
e is 65537 (0x010001)

Maintenant que vous disposez d’une clé privée, vous pouvez créer un CSR correspondant, toujours à l’aide de l’utilitaire openssl. Vous serez invité à remplir un certain nombre de champs tels que Pays, État et Ville. Vous pouvez saisir un . si vous souhaitez laisser un champ vide, mais sachez que s’il s’agissait d’un vrai CSR, il est préférable d’utiliser les valeurs correctes pour votre emplacement et votre organisation. Cependant, ne laissez pas le nom commun (CN) vide, car ce champ est obligatoire et votre autorité de certification ne pourra pas signer le certificat sans lui :

openssl req -new -key sammy-server.key -out sammy-server.req

Output
. . .
-----
Country Name (2 letter code) [XX]:US
State or Province Name (full name) []:New York
Locality Name (eg, city) [Default City]:New York City
Organization Name (eg, company) [Default Company Ltd]:DigitalOcean
Organizational Unit Name (eg, section) []:Community
Common Name (eg, your name or your server's hostname) []:sammy-server
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Si vous souhaitez ajouter automatiquement ces valeurs dans le cadre de l’invocation d’openssl plutôt que via l’invite interactive, vous pouvez transmettre l’argument -subj à OpenSSL. Assurez-vous de modifier les valeurs en surbrillance pour qu’elles correspondent à l’emplacement de votre cabinet, à votre organisation et au nom du serveur :

openssl req -new -key sammy-server.key -out server.req -subj \
/C=US/ST=New\ York/L=New\ York\ City/O=DigitalOcean/OU=Community/CN=sammy-server

Pour vérifier le contenu d’un CSR, vous pouvez lire dans un fichier de requête avec openssl et examiner les champs à l’intérieur :

openssl req -in sammy-server.req -noout -subject

Output
subject=C = US, ST = New York, L = New York City, O = DigitalOcean, OU = Community, CN = sammy-server

Au cours de cette étape, vous avez généré une demande de signature de certificat pour un serveur fictif appelé sammy-server. Dans un scénario réel, la demande peut provenir de quelque chose comme un serveur Web intermédiaire ou de développement qui a besoin d’un certificat TLS pour les tests ; ou il peut provenir d’un serveur OpenVPN qui demande un certificat afin que les utilisateurs puissent se connecter à un VPN. Dans l’étape suivante, nous procéderons à la signature de la demande de signature de certificat à l’aide de la clé privée du serveur CA.

Étape 7 - Signature d’un CSR (facultatif)

À l’étape précédente, vous avez créé une demande de certificat d’exercice et une clé pour un serveur fictif. Vous l’avez copié dans le répertoire /tmp de votre serveur CA, en émulant le processus que vous utiliseriez si vous aviez de vrais clients ou serveurs vous envoyant des demandes CSR qui doivent être signées.

En continuant avec le scénario fictif, le serveur CA doit maintenant importer le certificat de pratique et le signer. Une fois qu’une demande de certificat est validée par l’autorité de certification et relayée vers un serveur, les clients qui font confiance à l’autorité de certification pourront également faire confiance au certificat nouvellement émis.

Étant donné que nous opérerons à l’intérieur de l’ICP de l’autorité de certification où l’utilitaire easy-rsa est disponible, les étapes de signature utiliseront l’utilitaire easy-rsa pour faciliter les choses, par opposition à l’utilisation directe de l’openssl comme nous l’avons fait dans l’exemple précédent.

La première étape pour signer le CSR fictif consiste à importer la demande de certificat à l’aide du script easy-rsa :

cd ~/easy-rsa
./easyrsa import-req /tmp/sammy-server.req sammy-server

Output
. . .
The request has been successfully imported with a short name of: sammy-server
You may now use this name to perform signing operations on this request.

Vous pouvez maintenant signer la demande en exécutant le script easyrsa avec l’option sign-req, suivi du type de demande et du nom commun inclus dans le CSR. Le type de requête peut être client, serveur ou ca. Puisque nous nous entraînons avec un certificat pour un serveur fictif, assurez-vous d’utiliser le type de demande de serveur :

./easyrsa sign-req server sammy-server

Dans la sortie, il vous sera demandé de vérifier que la demande provient d’une source fiable. Tapez yes puis appuyez sur ENTER pour confirmer ceci :

Output
You are about to sign the following certificate.
Please check over the details shown below for accuracy. Note that this request
has not been cryptographically verified. Please be sure it came from a trusted
source or that you have verified the request checksum with the sender.

Request subject, to be signed as a server certificate for 3650 days:

subject=
    commonName                = sammy-server


Type the word 'yes' to continue, or any other input to abort.
  Confirm request details: yes
. . .
Certificate created at: /home/sammy/easy-rsa/pki/issued/sammy-server.crt

If you encrypted your CA key, you’ll be prompted for your password at this point.

With those steps complete, you have signed the sammy-server.req CSR using the CA Server’s private key in /home/sammy/easy-rsa/pki/private/ca.key. The resulting sammy-server.crt file contains the practice server’s public encryption key, as well as a new signature from the CA Server. The point of the signature is to tell anyone who trusts the CA that they can also trust the sammy-server certificate.

If this request was for a real server like a web server or VPN server, the last step on the CA Server would be to distribute the new sammy-server.crt and ca.crt files from the CA Server to the remote server that made the CSR request:

scp pki/issued/sammy-server.crt sammy@your_server_ip:/tmp
scp pki/ca.crt sammy@your_server_ip:/tmp

À ce stade, vous pourrez utiliser le certificat émis avec quelque chose comme un serveur Web, un VPN, un outil de gestion de configuration, un système de base de données ou à des fins d’authentification client.

Étape 8 - Révocation d’un certificat (facultatif)

Parfois, vous devrez peut-être révoquer un certificat pour empêcher un utilisateur ou un serveur de l’utiliser. Peut-être que l’ordinateur portable de quelqu’un a été volé, qu’un serveur Web a été compromis ou qu’un employé ou un sous-traitant a quitté votre organisation.

Pour révoquer un certificat, le processus général suit ces étapes :

1. Révoquez le certificat avec la commande ./easyrsa revoke client_name.
2. Générez une nouvelle CRL avec la commande ./easyrsa gen-crl.
3. Transférez le fichier crl.pem mis à jour sur le ou les serveurs qui dépendent de votre autorité de certification et, sur ces systèmes, copiez-le dans le ou les répertoires requis pour les programmes qui s’y réfèrent.
4. Redémarrez tous les services qui utilisent votre autorité de certification et le fichier CRL.

Vous pouvez utiliser ce processus pour révoquer à tout moment tout certificat que vous avez précédemment émis. Nous passerons en revue chaque étape en détail dans les sections suivantes, en commençant par la commande de révocation.

Révoquer un certificat

Pour révoquer un certificat, accédez au répertoire easy-rsa sur votre serveur CA :

cd ~/easy-rsa

Ensuite, exécutez le script easyrsa avec l’option de révocation, suivi du nom du client que vous souhaitez révoquer. En suivant l’exemple pratique ci-dessus, le nom commun du certificat est sammy-server :

./easyrsa revoke sammy-server

Celui-ci vous demandera de confirmer la révocation en saisissant ‘yes’ :

Output
Please confirm you wish to revoke the certificate with the following subject:

subject=
    commonName                = sammy-server


Type the word 'yes' to continue, or any other input to abort.
  Continue with revocation: yes
. . .
Revoking Certificate 8348B3F146A765581946040D5C4D590A
. . .

Notez la valeur en surbrillance sur la ligne Révoquer le certificat. Cette valeur est le numéro de série unique du certificat qui est révoqué. Si vous souhaitez examiner la liste de révocation à la dernière étape de cette section pour vérifier que le certificat s’y trouve, vous aurez besoin de cette valeur.

Après confirmation de l’action, l’autorité de certification révoquera le certificat. Cependant, les systèmes distants qui s’appuient sur l’autorité de certification n’ont aucun moyen de vérifier si des certificats ont été révoqués. Les utilisateurs et les serveurs pourront toujours utiliser le certificat jusqu’à ce que la liste de révocation de certificats (CRL) de l’autorité de certification soit distribuée à tous les systèmes qui dépendent de l’autorité de certification.

À l’étape suivante, vous allez générer une CRL ou mettre à jour un fichier crl.pem existant.

Génération d’une liste de révocation de certificats

Maintenant que vous avez révoqué un certificat, il est important de mettre à jour la liste des certificats révoqués sur votre serveur CA. Une fois que vous avez une liste de révocation mise à jour, vous serez en mesure de dire quels utilisateurs et systèmes ont des certificats valides dans votre autorité de certification.

Pour générer une CRL, exécutez la commande easy-rsa avec l’option gen-crl tout en restant dans le répertoire ~/easy-rsa : Si vous avez utilisé une phrase de passe lors de la création de votre fichier ca.key, vous serez invité à la saisir. La commande gen-crl générera un fichier appelé crl.pem contenant la liste mise à jour des certificats révoqués pour cette autorité de certification.

Ensuite, vous devrez transférer le fichier crl.pem mis à jour vers tous les serveurs et clients qui dépendent de cette autorité de certification chaque fois que vous exécutez la commande gen-crl. Sinon, les clients et les systèmes pourront toujours accéder aux services et aux systèmes qui utilisent votre autorité de certification, car ces services doivent connaître l’état de révocation du certificat.

Transfert d’une liste de révocation de certificats

Maintenant que vous avez généré une CRL sur votre serveur CA, vous devez la transférer vers des systèmes distants qui dépendent de votre CA. Pour transférer ce fichier sur vos serveurs, vous pouvez utiliser la commande scp.

Remarque : Ce didacticiel explique comment générer et distribuer une CRL manuellement. Bien qu’il existe des méthodes plus robustes et automatisées pour distribuer et vérifier les listes de révocation comme OCSP-Stapling, la configuration de ces méthodes dépasse le cadre de cet article.

Assurez-vous que vous êtes connecté à votre serveur CA en tant qu’utilisateur non root et exécutez ce qui suit, en remplaçant l’adresse IP ou le nom DNS de votre propre serveur à la place de your_server_ip :

scp ~/easy-rsa/pki/crl.pem sammy@your_server_ip:/tmp

Maintenant que le fichier se trouve sur le système distant, la dernière étape consiste à mettre à jour tous les services avec la nouvelle copie de la liste de révocation.

Mise à jour des services prenant en charge une CRL

La liste des étapes que vous devez suivre pour mettre à jour les services qui utilisent le fichier crl.pem dépasse le cadre de ce didacticiel. En général, vous devrez copier le fichier crl.pem à l’emplacement attendu par le service, puis le redémarrer à l’aide de systemctl.

Une fois que vous avez mis à jour vos services avec le nouveau fichier crl.pem, vos services pourront rejeter les connexions des clients ou des serveurs qui utilisent un certificat révoqué.

Examen et vérification du contenu d’une CRL Si vous souhaitez examiner un fichier CRL, par exemple pour confirmer une liste de certificats révoqués, utilisez la commande openssl suivante depuis votre répertoire easy-rsa sur votre serveur CA :

cd ~/easy-rsa
openssl crl -in pki/crl.pem -noout -text

Vous pouvez également exécuter cette commande sur n’importe quel serveur ou système sur lequel l’outil openssl est installé avec une copie du fichier crl.pem. Par exemple, si vous avez transféré le fichier crl.pem sur votre deuxième système et que vous souhaitez vérifier que le certificat sammy-server est révoqué, vous pouvez utiliser une commande openssl comme celle-ci, en remplaçant le numéro de série que vous avez noté précédemment lorsque vous avez révoqué le certificat à la place de celui surligné ici :

openssl crl -in /tmp/crl.pem -noout -text |grep -A 1 8348B3F146A765581946040D5C4D590A

Output
    Serial Number: 8348B3F146A765581946040D5C4D590A
        Revocation Date: Apr  1 20:48:02 2020 GMT

Remarquez comment la commande grep est utilisée pour vérifier le numéro de série unique que vous avez noté à l’étape de révocation. Vous pouvez désormais vérifier le contenu de votre liste de révocation de certificats sur tout système qui en dépend pour restreindre l’accès aux utilisateurs et aux services.

Conclusion

Dans ce didacticiel, vous avez créé une autorité de certification privée à l’aide du package Easy-RSA sur un serveur Debian 11 autonome. Vous avez appris comment le modèle de confiance fonctionne entre les parties qui s’appuient sur l’autorité de certification. Vous avez également créé et signé une demande de signature de certificat (CSR) pour un serveur d’exercice, puis révoqué un certificat. Enfin, vous avez généré et distribué une liste de révocation de certificats (CRL) pour tout système qui s’appuie sur votre autorité de certification afin de garantir que les utilisateurs ou les serveurs qui ne doivent pas accéder aux services ne le peuvent pas.

Vous pouvez désormais émettre des certificats pour les utilisateurs et les utiliser avec des services comme OpenVPN. Vous pouvez également utiliser votre autorité de certification pour configurer des serveurs Web de développement et de transfert avec des certificats pour sécuriser vos environnements de non-production. L’utilisation d’une autorité de certification avec des certificats TLS pendant le développement peut aider à garantir que votre code et vos environnements correspondent le plus possible à votre environnement de production.

Si vous souhaitez en savoir plus sur l’utilisation d’OpenSSL, notre didacticiel OpenSSL Essentials: Working with SSL Certificates, Private Keys and CSRs contient de nombreuses informations supplémentaires pour vous aider à vous familiariser avec les principes fondamentaux d’OpenSSL.