Comment installer et configurer une autorité de certification (CA) sur Ubuntu 20.04

Comment installer et configurer une autorité de certification (CA) sur Ubuntu 20.04

Introduction

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

Certains 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 les certificats émis par une AC 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, nous apprendrons comment configurer une autorité de certification privée sur un serveur Ubuntu 20.04, 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’autorité de certification 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 apprendrez à 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 CA.

Prérequis

Pour réaliser ce tutoriel, vous devrez avoir accès à un serveur Ubuntu 20.04 pour héberger votre serveur CA. Vous devrez configurer un utilisateur non root avec des privilèges sudo avant de commencer ce guide. Vous pouvez suivre notre guide de configuration initiale du serveur Ubuntu 20.04 pour configurer un utilisateur avec les autorisations appropriées. Le tutoriel lié configurera également un pare-feu, qui est supposé être en place tout au long de ce guide.

Ce serveur sera appelé le serveur CA dans ce tutoriel.

Assurez-vous que le serveur CA est un système autonome. Il ne sera utilisé que pour importer, signer et révoquer les demandes de certificats. Il ne doit pas exécuter d’autres services et, idéalement, il sera hors ligne ou complètement éteint lorsque vous ne travaillez pas activement avec votre CA.

Note : La dernière section de ce tutoriel est facultative si vous souhaitez apprendre à signer et à révoquer des certificats. Si vous choisissez de réaliser ces étapes pratiques, vous aurez besoin d’un deuxième serveur Ubuntu 20.04 ou vous pouvez également utiliser votre propre ordinateur Linux local exécutant Ubuntu ou Debian, ou des distributions dérivées de l’un ou l’autre.

Etape 1 – Installation de 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 CA.

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 paquet et à l’installer. Appuyez sur y pour confirmer que vous voulez installer le paquet.

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

Etape 2 – Préparation d’un répertoire d’infrastructure à clé publique

Maintenant que vous avez installé easy-rsa, il est temps de créer une infrastructure à clé publique (ICP) squelette 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’AC sans privilèges élevés.

mkdir ~/easy-rsa

Ceci 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 paquet easy-rsa que nous avons installés à l’étape précédente. Ces fichiers sont situés dans le dossier /usr/share/easy-rsa sur le serveur CA.

Créer les liens symboliques avec la commande ln:

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

Note : Alors que d’autres guides pourraient vous indiquer de copier les fichiers du package easy-rsa dans votre répertoire ICP, ce tutoriel adopte une approche par liens symboliques. Par conséquent, toute mise à jour du paquet easy-rsa sera automatiquement reflétée dans les scripts de votre ICP.

Pour restreindre l’accès à votre nouveau répertoire d’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 à l’intérieur du 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 avez un répertoire qui contient tous les fichiers nécessaires pour créer une autorité de certification. Dans la section suivante, vous créerez la clé privée et le certificat public pour votre CA.

Etape 3 – Création d’une autorité de certification

Avant de pouvoir créer la clé privée et le certificat de votre CA, vous devez créer et remplir un fichier appelé vars avec certaines valeurs par défaut. Tout d’abord, vous allez cd dans le répertoire easy-rsa, puis vous allez créer et éditer 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 surlignée pour refléter vos propres informations d’organisation. La partie importante 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 "[email protected]"set_var EASYRSA_REQ_OU "Community"set_var EASYRSA_ALGO "ec"set_var EASYRSA_DIGEST "sha512"

Quand 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 à construire votre autorité de certification.

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 concernant la version d’OpenSSL et vous serez invité à entrer une phrase de passe 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 de passe à chaque fois que vous devrez interagir avec votre CA, par exemple pour signer ou révoquer un certificat.

Il vous sera également demandé de confirmer le nom commun (CN) de votre CA. Le CN est le nom utilisé pour faire référence à 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 pour des raisons de simplicité, appuyez sur la touche ENTER 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) :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

Note : Si vous ne voulez pas être invité à entrer 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’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 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 ne réalise pas une attaque Man-in-the-middle.

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

Avec cela, votre CA est en place et il est prêt à être utilisé pour signer des demandes de certificats, et pour révoquer des certificats.

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

Maintenant, votre CA est 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’autorité de certification à vos serveurs OpenVPN, serveurs web, serveurs de messagerie, etc. Tout utilisateur ou serveur qui a besoin de vérifier l’identité d’un autre utilisateur ou serveur dans votre réseau doit avoir une copie du fichier ca.crt importée 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 d’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 le copier-coller avec nano dans cette étape car il 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

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

Output
-----BEGIN CERTIFICATE-----MIIDSzCCAjOgAwIBAgIUcR9Crsv3FBEujrPZnZnU4nSb5TMwDQYJKoZIhvcNAQELBQAwFjEUMBIGA1UEAwwLRWFzeS1SU0EgQ0EwHhcNMjAwMzE4MDMxNjI2WhcNMzAw. . .. . .-----END CERTIFICATE-----

Copiez tout, y compris les lignes -----BEGIN CERTIFICATE----- et -----END CERTIFICATE----- et les tirets.

Sur votre second 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 second système Linux, il est temps d’importer le certificat dans le magasin de certificats de son système d’exploitation.

Sur les systèmes basés sur Ubuntu et Debian, exécutez les commandes suivantes en tant qu’utilisateur non root pour importer le certificat :

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

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 vous exécuterez la commande update-ca-trust.

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

Maintenant, votre second système Linux fera confiance à tout certificat qui a été signé par le serveur CA.

Note : Si vous utilisez votre CA avec des serveurs web et que vous utilisez Firefox comme navigateur, vous devrez importer le certificat public ca.crt dans Firefox directement. 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 CA à Firefox, veuillez consulter cet article d’assistance de Mozilla sur la configuration des autorités de certification (CA) dans Firefox.

Si vous utilisez votre CA pour intégrer un environnement Windows ou des ordinateurs de bureau, veuillez consulter la documentation sur la façon d’utiliser certutil.exe pour installer un certificat de CA.

Si vous utilisez ce tutoriel comme prérequis pour un autre tutoriel, ou si vous êtes familier avec la façon de signer et de 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, alors la section facultative suivante expliquera chaque processus en détail.

(Facultatif) – Création de demandes de signature de certificat et révocation de certificats

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

Si vous souhaitez pratiquer et en savoir plus sur la façon de signer les demandes de certificats, et sur la façon de révoquer les certificats, alors ces sections facultatives expliqueront comment les deux processus fonctionnent.

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

Maintenant que vous avez un CA prêt à être utilisé, vous pouvez vous exercer à 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 de la partie demanderesse. La clé privée sera gardée secrète, et sera utilisée pour chiffrer des informations que toute personne possédant le certificat public signé pourra ensuite déchiffrer.

Les étapes suivantes seront exécutées sur votre second système Ubuntu ou Debian, 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. Puisque 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 être certain, exécutez ce qui suit sur votre système :

 
sudo apt update
 
sudo apt install openssl
 

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

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

 
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 un CSR correspondant, encore une fois en utilisant l’utilitaire openssl. Vous serez invité à remplir un certain nombre de champs comme le pays, l’État et la ville. Vous pouvez entrer un . si vous souhaitez laisser un champ vide, mais sachez que si c’était un véritable CSR, il est préférable d’utiliser les valeurs correctes pour votre emplacement et votre organisation :

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

Output
. . .-----Country Name (2 letter code) :USState or Province Name (full name) :New YorkLocality Name (eg, city) :New York CityOrganization Name (eg, company) :DigitalOceanOrganizational Unit Name (eg, section) :CommunityCommon Name (eg, your name or your server's hostname) :sammy-serverEmail Address :Please enter the following 'extra' attributesto be sent with your certificate requestA 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. Veillez à modifier les valeurs mises en évidence pour qu’elles correspondent à l’emplacement de votre cabinet, à votre organisation et au nom de votre 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’une CSR, vous pouvez lire 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 du sujet de votre demande de certificat de pratique, copiez le fichier sammy-server.req sur votre serveur CA en utilisant scp:

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

Dans 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 pourrait provenir de quelque chose comme un serveur web de mise en scène ou de développement qui a besoin d’un certificat TLS pour les tests ; ou elle pourrait provenir d’un serveur OpenVPN qui demande un certificat pour que les utilisateurs puissent se connecter à un VPN. Dans l’étape suivante, nous allons procéder à la signature de la demande de certificat en utilisant la clé privée du serveur CA.

(Facultatif) – Signature d’un CSR

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

Poursuivant 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’AC et relayée à un serveur, les clients qui font confiance à l’autorité de certification pourront également faire confiance au certificat nouvellement émis.

Puisque nous opérerons à l’intérieur de la PKI de l’AC 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 openssl comme nous l’avons fait dans l’exemple précédent.

La première étape pour signer le CSR fictif 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-serverYou 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, suivie du type de demande et du nom commun qui est inclus dans le CSR. Le type de demande peut être l’un des suivants : client, server, ou ca. Puisque nous nous exerçons avec un certificat pour un serveur fictif, assurez-vous d’utiliser le type de requête server :

./easyrsa sign-req server sammy-server

Dans la sortie, il vous sera demandé de vérifier que la requête provient d’une source de confiance. 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 requesthas not been cryptographically verified. Please be sure it came from a trustedsource 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-serverType 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é CA, on vous demandera votre mot de passe à ce stade.

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

Si cette demande concernait un serveur réel comme un serveur web ou un serveur VPN, la dernière étape sur le serveur CA serait de distribuer les nouveaux fichiers sammy-server.crt et ca.crt du serveur CA au serveur distant qui a fait la demande de CSR :

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

À ce stade, vous seriez en mesure d’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 du client.

(Facultatif) – Révoquer un certificat

Occasionnellement, vous pouvez avoir besoin de révoquer un certificat pour empêcher un utilisateur ou un serveur de l’utiliser. Peut-être que l’ordinateur portable d’une personne a été volé, qu’un serveur Web a été compromis ou qu’un employé ou un contractant a quitté votre organisation.

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

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 vers le ou les serveurs qui dépendent de votre CA, et sur ces systèmes, copiez-le dans le ou les répertoires requis pour les programmes qui y font référence.
4. Redémarrez tous les services qui utilisent votre CA et le fichier CRL.

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

Révoquer un certificat

Pour révoquer un certificat, naviguez jusqu’au répertoire easy-rsa sur votre serveur d’AC:

cd ~/easy-rsa

Puis, exécutez le script easyrsa avec l’option revoke, suivie 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 

Ce script 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-serverType 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 révoqué. 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 révoquera le certificat. Cependant, les systèmes distants qui s’appuient sur 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 de révocation de certificat (CRL) 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 CRL 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 d’AC. Une fois que vous avez une liste de révocation mise à jour, vous serez en mesure de dire quels utilisateurs et quels systèmes ont des certificats valides dans votre CA.

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:

./easyrsa gen-crl

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 AC.

Puis vous devrez transférer le fichier crl.pem mis à jour à tous les serveurs et clients qui dépendent de cette AC 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 CA, puisque ces services doivent connaître l’état révoqué du certificat.

Transfert d’une liste de révocation de certificat

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

Note : Ce tutoriel explique comment générer et distribuer une LCR manuellement. Bien qu’il existe des méthodes plus robustes et automatisées pour distribuer et vérifier les listes de révocation, comme l’agrafage OCSP, 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 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 CRL

La liste des étapes que vous devez utiliser 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 dans l’emplacement attendu par le service, puis le redémarrer en utilisant systemctl.

Une fois que vous aurez mis à jour vos services avec le nouveau fichier crl.pem, vos services seront en mesure de 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 à partir de 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 tout 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 voulez vérifier que le certificat sammy-server est révoqué, vous pouvez utiliser une commande openssl comme la suivante, en substituant le numéro de série que vous avez noté précédemment lorsque vous avez révoqué le certificat à la place de celui 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

Notez 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 certificats 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 paquet Easy-RSA sur un serveur autonome Ubuntu 20.04. 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’entraînement, puis appris à révoquer un certificat. Enfin, vous avez appris à générer et à distribuer une liste de révocation de certificats (CRL) pour tout système qui s’appuie sur votre CA afin de garantir que les utilisateurs ou les serveurs qui ne devraient pas accéder aux services en soient empêchés.

Vous pouvez maintenant émettre 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 mise en scène 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 aider à garantir que votre code et vos environnements correspondent le plus possible à votre environnement de production.

Si vous souhaitez en savoir plus sur la façon d’utiliser OpenSSL, notre document OpenSSL Essentials : Working with SSL Certificates, Private Keys and CSRs tutorial a beaucoup d’informations supplémentaires pour vous aider à vous familiariser avec les fondamentaux d’OpenSSL.