Comment mettre en place et configurer une autorité de certification (AC) sur CentOS 8

Introduction

Une autorité de certification (AC) est une entité chargée d’émettre des certificats numériques pour vérifier les identités sur l’internet. Bien que les AC publiques soient un choix populaire pour vérifier l’identité des sites web et autres services qui sont fournis au grand public, les AC 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 AC privée, vous pouvez émettre des certificats pour les utilisateurs, les serveurs ou les programmes et services individuels au sein de votre infrastructure.

Quelques exemples de programmes sur Linux qui utilisent leur propre AC privée sont OpenVPN et Puppet.  Vous pouvez également configurer votre serveur web pour utiliser des certificats émis par une AC privée afin de faire correspondre les environnements de développement et de simulation aux serveurs de production qui utilisent TLS pour crypter les connexions.

Dans ce guide, nous allons apprendre comment mettre en place une autorité de certification privée sur un serveur CentOS 8 et comment générer et signer un certificat de test en utilisant votre nouvelle AC. Vous apprendrez également comment importer le certificat public du serveur de l’AC dans le magasin de certificats de votre système d’exploitation afin de pouvoir vérifier la chaîne de confiance entre l’AC et les serveurs ou utilisateurs distants. Enfin, vous apprendrez comment révoquer des certificats et distribuer une liste de révocation de certificats pour vous assurer que seuls les utilisateurs et les systèmes autorisés peuvent utiliser les services qui reposent sur votre AC.

Conditions préalables

Pour suivre ce tutoriel, vous aurez besoin d’un serveur CentOS 8 avec un utilisateur sudo activé, non root et d’un pare-feu configuré avec firewalld. Vous pouvez suivre notre guide de configuration initiale de serveur avec CentOS 8 pour aborder ce tutoriel.

Ce serveur sera appelé Serveur AC dans ce tutoriel.

Assurez-vous que le serveur AC est un système autonome. Il ne sera utilisé que pour importer, signer et révoquer les demandes de certificats. Il ne doit pas gérer d’autres services et, dans l’idéal, il sera hors ligne ou complètement fermé lorsque vous ne travaillerez pas activement avec votre AC.

Étape 1 — Installation d’Easy-RSA

La première tâche de ce tutoriel consiste à installer l’ensemble de scripts easy-rsa sur votre serveur d’AC. 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 AC.

Le paquet easy-rsa n’est pas disponible par défaut dans CentOS 8, de sorte que vous devrez activer le référentiel Extra Packages for Enterprise Linux (EPEL) EPEL est géré par le projet Fedora et contient des paquets non standard mais populaires pour Fedora, CentOS et d’autres distributions Linux qui utilisent le format du paquet RPM. Connectez-vous à votre serveur AC en tant qu’utilisateur sudo non root que vous avez créé lors des étapes de configuration initiales et exécutez ce qui suit :

sudo dnf install epel-release

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

Installez maintenant le paquet easy-rsa, en entrant à nouveau y à l’invite :

sudo dnf install easy-rsa

À ce stade, vous disposez de tout ce dont vous avez besoin, installé et prêt pour utiliser Easy-RSA. Dans l’étape suivante, vous allez créer une infrastructure à clés publiques, puis vous commencerez à construire votre autorité de certification.

Étape 2 — Préparation d’un répertoire d’infrastructures à clés publiques

Maintenant que vous avez installé easy-rsa​​​, il est temps de créer un squelette de l’infrastructure de clés publiques (ICP) sur le serveur AC. Assurez-vous que vous êtes encore connecté en tant qu’utilisateur non root et créez un répertoire easy-rsa Assurez-vous que vous n’utilisez pas sudo pour exécuter l’une des commandes suivantes, puisque votre utilisateur normal doit gérer et interagir avec l’AC sans privilèges élevés.

mkdir ~/easy-rsa

Cela créera un nouveau répertoire appelé easy-rsa dans votre dossier de base. Nous utiliserons ce répertoire pour créer des liens symboliques pointant vers les fichiers de packages easy-rsa que nous avons installés à l’étape précédente. Ces fichiers sont situés dans le dossier /usr/share/easy-rsa/3 sur le serveur AC.

Créez les liens symboliques (symlinks) avec la commande ln :

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

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

chmod 700 /home/sammy/easy-rsa

Enfin, initialisez l’ICP dans le répertoire easy-rsa :

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

Output
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 qui contient tous les fichiers nécessaires pour créer une autorité de certification. Dans la section suivante, vous allez créer la clé privée et le certificat public pour votre AC.

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

Avant de pouvoir créer la clé et le certificat privés de votre AC, vous devez créer et alimenter un fichier appelé vars avec quelques valeurs par défaut. Tout d’abord, vous allez 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é.

L’éditeur de texte par défaut fourni avec CentOS 8 est vi. vi, un éditeur de texte extrêmement puissant, mais il peut être difficile à utiliser pour les utilisateurs qui manquent d’expérience. Vous pouvez installer un éditeur plus adapté, tel que nano, pour faciliter l’édition des fichiers de configuration sur votre serveur CentOS 8 :

sudo dnf install nano

Lorsque vous êtes invité à installer nano, entrez y pour poursuivre les étapes d’installation. Maintenant, vous êtes prêt à modifier le fichier vars :

cd ~/easy-rsa
nano vars

Une fois le fichier ouvert, collez les lignes suivantes et modifiez chaque valeur mise en évidence pour refléter les informations de votre propre organisation. L’important ici est de veiller à ne laisser aucune des valeurs en blanc :

~/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 (ENTRÉE) pour confirmer. Vous êtes maintenant prêt à construire votre AC.

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

./easyrsa build-ca

Dans la sortie, vous verrez quelques lignes sur la version OpenSSL et vous serez invité à entrer une phrase de passe pour votre paire de clés. Assurez-vous de choisir une phrase de passe solide, et notez-le dans un endroit sûr. Vous devrez saisir la phrase de passe chaque fois vous devrez interagir avec votre AC, par exemple pour signer ou révoquer un certificat.

Il vous sera également demandé de confirmer le Nom commun (CN) de votre AC. Le nom commun est le nom utilisé pour désigner cette machine dans le contexte de l’autorité de certification. Vous pouvez saisir n’importe quelle chaîne de caractères pour le nom commun de l’AC mais, par souci de simplicité, appuyez sur ENTER (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

./easyrsa build-ca nopass

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

• ca.crt est le fichier de certificats public de l’AC. 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 AC devront avoir une copie de ce fichier. Toutes les parties s’appuieront sur le certificat public pour s’assurer qu’une personne ne se fait pas passer pour un système et n’effectue pas une attaque de type Man-in-the-middle.

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

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

Étape 4 — Distribuer le certificat public de votre autorité de certification

Votre AC est maintenant configurée et prête à agir comme une racine de confiance pour tous les systèmes que vous voulez configurer pour l’utiliser. Vous pouvez ajouter le certificat de l’AC à 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 devrait 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 deuxième système Linux comme un autre serveur ou un ordinateur local, obtenez d’abord une copie du fichier ca.crt de votre serveur AC. 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 des outils comme scp, rsync pour transférer le fichier entre les systèmes. Cependant, nous utiliserons un copier-coller avec nano dans cette étape car cela fonctionne sur tous les systèmes.

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

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

Il y aura une sortie dans votre terminal qui ressemblera à ce qui suit :

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 AC 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 (ENTRÉE) pour confirmer.

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

Sur CentOS, Fedora ou d’autres systèmes Linux dérivés de RedHat, exécutez les commandes suivantes pour importer le certificat :

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

Pour importer le certificat du serveur AC sur un système basé sur Debian ou Ubuntu, copiez et collez le contenu du fichier sur le système tout comme dans l’exemple précédent dans un fichier appelé /tmp/ca.crt. Ensuite, copiez le certificat dans /usr/local/share/ca-certificates/, puis exécutez la commande update-ca-certificates.

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

Votre deuxième système Linux fera maintenant confiance à tout certificat qui a été signé par le serveur AC.

Si vous utilisez ce tutoriel comme condition préalable à un autre tutoriel, 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 vous expliquera chaque processus en détail.

(Facultatif) — Création de demandes de signature de certificats et révocation des certificats

Les sections suivantes du tutoriel sont facultatives. Si vous avez effectué toutes les étapes précédentes, vous disposez d’une autorité de certification entièrement configurée et opérationnelle que vous pouvez utiliser comme condition préalable pour d’autres tutoriels. Vous pouvez importer le fichier ca.crt de votre AC et vérifier dans votre réseau les certificats qui ont été signés par votre AC.

Si vous souhaitez vous entraîner et en savoir plus sur la manière de signer des demandes de certificat et sur la manière de révoquer des certificats, ces sections facultatives vous expliqueront comment fonctionnent les deux processus.

(Facultatif) — Création et signature d’une demande de certificat de pratique

Maintenant que vous avez une AC 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 requérant, et une signature de la requête elle-même, qui est créée en utilisant la clé privée de la partie requérante. La clé privée sera gardée secrète et sera utilisée pour chiffrer les informations que toute personne possédant le certificat public signé pourra ensuite déchiffrer.

Les étapes suivantes seront exécutées sur votre deuxième système Linux fonctionnant sous CentOS, Fedora ou une autre distribution Linux dérivée de RedHat. 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 de pratique.

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

sudo dnf install openssl

Lorsque vous êtes invité à installer openssl, entrez y pour poursuivre les étapes d’installation.  Maintenant, vous êtes prêt à créer une pratique CSR avec openssl.

La première étape que vous devez suivre pour créer une CSR est la génération d’une clé privée. Pour créer une clé privée en utilisant openssl, créez un répertoire “practice-csr” et générez ensuite une clé à l’intérieur de celui-ci. Nous allons faire cette requête pour un serveur fictif appelé sammy-server, par opposition à la création d’un certificat qui est utilisé pour identifier un utilisateur ou une autre AC.

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 avez une clé privée, vous pouvez créer une CSR correspondante, à nouveau en utilisant l’utilitaire openssl. Vous serez invité à remplir un certain nombre de champs comme Pays, État et Ville. Vous pouvez saisir un . si vous souhaitez laisser un champ vide, mais sachez que s’il s’agit d’une véritable CSR, il est préférable d’utiliser les valeurs correctes de votre localisation et votre organisation :

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 openssl plutôt que via l’invite interactive, vous pouvez passer l’argument -subj à OpenSSL. Assurez-vous de modifier les valeurs mises en évidence pour qu’elles correspondent à votre lieu d’exercice, à votre organisation et au nom de votre serveur :

openssl req -new -key sammy-server.key -out sammy-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’une 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

Une fois que vous êtes satisfait de l’objet de votre demande de certificat de pratique, copiez le fichier sammy-server.req sur votre serveur AC en utilisant scp

scp sammy-server.req sammy@your_ca_server_ip:/tmp/sammy-server.req

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 d’un serveur web de développement ou de simulation qui a besoin d’un certificat TLS pour des tests, ou d’un serveur OpenVPN qui demande un certificat pour que les utilisateurs puissent se connecter à un VPN. Au cours de l’étape suivante, nous allons passer à la signature de la demande de signature de certificat en utilisant la clé privée du serveur AC.

(Facultatif) - Signature d’une CSR

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

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

Comme nous opérerons au sein de l’ICP de l’AC où l’utilitaire easy-rsa est disponible, les étapes de signature utiliseront l’utilitaire easy-rsa pour faciliter les choses, au lieu d’utiliser directement openssl comme nous l’avons fait dans l’exemple précédent.

La première étape pour signer la CSR fictive est d’importer la demande de certificat en utilisant le 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.

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

./easyrsa sign-req server sammy-server

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

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

Si vous avez crypté votre clé AC, on vous demandera votre mot de passe à ce stade.

Une fois ces étapes terminées, vous avez signé la CSR sammy-server.req en utilisant la clé privée du serveur AC dans /home/sammy/easy-rsa/pki/private/ca.key. Le fichier sammy-server.crt qui en résulte contient la clé de chiffrement publique du serveur de pratique, ainsi qu’une nouvelle signature du serveur AC. Le but de la signature est de dire à toute personne qui fait confiance à l’AC qu’elle peut également faire confiance au certificat du serveur de pratique sammy-server.

Si cette requête concerne un vrai serveur comme un serveur web ou un serveur VPN, la dernière étape sur le serveur AC serait de distribuer les nouveaux fichiers sammy-server.crt et ca.crt du serveur AC au serveur distant qui a fait la requête CSR :

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

À ce stade, vous devriez pouvoir utiliser le certificat délivré 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 de clients.

(Facultatif) — Révocation d’un certificat

Il peut arriver que vous deviez révoquer un certificat pour empêcher un utilisateur ou un serveur de l’utiliser. Il se peut que l’ordinateur portable de quelqu’un ait été volé, qu’un serveur web ait été compromis, ou qu’un employé ou un contractant ait quitté votre organisation.

Pour révoquer un certificat, la procédure générale suit les étapes suivantes :

1. Révoquez le certificat avec la commande ./easyrsa revoke client_name
2. Générer une nouvelle LRC avec la commande ./easyrsa gen-crl
3. Transférez le fichier crl.pem mis à jour vers le ou les serveurs qui dépendent de votre AC, et sur ces systèmes, copiez le fichier 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 AC et le fichier LRC.

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

Révoquer un certificat

Pour révoquer un certificat, naviguez vers le répertoire easy-rsa sur votre serveur AC :

cd ~/easy-rsa

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

./easyrsa revoke sammy-server

Il vous sera demandé de confirmer la révocation en entrant 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 mise en évidence sur la ligne Revoking Certificate Cette valeur est le numéro de série unique du certificat qui est en cours de révocation. Si vous voulez examiner la liste de révocation à la dernière étape de cette section pour vérifier que le certificat y figure, vous aurez besoin de cette valeur.

Après avoir confirmé l’action, l’AC va révoquer le certificat. Cependant, les systèmes distants qui dépendent de l’AC 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 des certificats révoqués (LCR) de l’AC soit distribuée à tous les systèmes qui dépendent de l’AC.

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

Générer une liste de révocation de certificat

Maintenant que vous avez révoqué un certificat, il est important de mettre à jour la liste des certificats révoqués sur votre serveur AC. Une fois que vous aurez mis à jour la liste des révocations, vous serez en mesure de savoir quels utilisateurs et quels systèmes ont des certificats valides dans votre AC.

Pour générer une LRC, exécutez la commande easy-rsa avec l’option gen-crl tout en restant dans le répertoire ~/easy-rsa :

./easyrsa gen-crl

Si vous avez utilisé une phrase de passe lors de la création de votre fichier ca.key, vous serez invité à l’entrer. La commande gen-crl générera un fichier appelé crl.pem, contenant la liste actualisée des certificats révoqués pour cette AC.

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

Transférer une liste de révocation de certificat

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

Assurez-vous que vous êtes connecté à votre serveur AC en tant qu’utilisateur non racine et exécutez les opérations suivantes, en substituant l’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 est 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 qui prennent en charge une LCR

L’énumération des étapes à suivre pour mettre à jour les services qui utilisent le fichier crl.pem dépasse la portée de ce tutoriel.  En général, vous devrez copier le fichier crl.pem à l’emplacement prévu par le service, puis le redémarrer à l’aide de systemctl.

Une fois que vous aurez 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 LCR

Si vous souhaitez examiner un fichier CRL, par exemple pour confirmer une liste de certificats révoqués, utilisez la commande openssl suivante à partir de votre répertoire easy-rsa sur votre serveur AC :

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

Vous pouvez également exécuter cette commande sur tout serveur ou système qui dispose de l’outil openssl installé avec une copie du fichier crl.pem. Par exemple, si vous avez transféré le fichier crl.pem sur votre second système et que vous souhaitez vérifier que le certificat de sammy-server est révoqué, vous pouvez utiliser une commande openssl comme celle qui suit, en introduisant le numéro de série que vous avez noté précédemment lorsque vous avez révoqué le certificat à la place de numéro mis en évidence 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é dans l’étape de révocation. Vous pouvez maintenant vérifier le contenu de votre liste de révocation de certificat sur tout système qui s’appuie sur elle pour restreindre l’accès aux utilisateurs et aux services.

Conclusion

Dans ce tutoriel, vous avez créé une autorité de certification privée en utilisant le package Easy-RSA sur un serveur CentOS 8 autonome. Vous avez appris comment fonctionne le modèle de confiance 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 de pratique, puis appris à révoquer un certificat. Enfin, vous avez appris comment générer et distribuer une liste de révocation de certificats (LRC) pour tout système qui dépend de votre AC afin de s’assurer que les utilisateurs ou les serveurs qui ne devraient pas accéder aux services en soient empêchés.

Vous pouvez maintenant délivrer des certificats pour les utilisateurs et les utiliser avec des services comme OpenVPN. Vous pouvez également utiliser votre AC pour configurer des serveurs web de développement et de simulation avec des certificats afin de sécuriser vos environnements de non-production. L’utilisation d’une AC avec des certificats TLS pendant le développement peut contribuer à garantir que votre code et vos environnements correspondent autant que possible à votre environnement de production.

Si vous souhaitez en savoir plus sur l’utilisation d’OpenSSL, consultez notre page sur les principes essentiels d’OpenSSL : Travailler avec les certificats SSL, les clés privées et les CSR contient de nombreuses informations supplémentaires pour vous aider à vous familiariser avec les principes fondamentaux d’OpenSSL.