Cet article a pour ambition de vous présenter le cycle de vie d’un certificat de la demande jusqu’à la révocation. Cette démonstration mettra en lumière les mécanismes ainsi que les flux menant à l’obtention d’un certificat pour vos machines.
Les certificats sont des composants majeurs des infrastructures informatiques. Ils sont souvent utilisés pour authentifier des entités les unes par rapport aux autres et établir une communication chiffrée. Dans des systèmes massivement distribués adossés à de grandes collections de services, la gestion de leur cohérence peut s’avérer problématique. De plus, les entités étant réparties de façon fortement distribuée sous différents domaines d’administration, la question de la révocation se pose également. Cet article va vous présenter la mise en œuvre d’une infrastructure de gestion de clés « from scratch », uniquement avec OpenSSL pour bien identifier les différents mécanismes.
1. Rappels de cryptographie (appliquée)
L’objectif de la cryptographie est très simple : chiffrer une information en clair au moyen d’une clé. Seuls les possesseurs de cette clé peuvent déchiffrer l’information. On distingue deux types de cryptographie : symétrique et asymétrique. La cryptographie symétrique est assez simple. Soit deux personnes Aline (A) et Bodor (B). Ils cherchent à communiquer en chiffrant leurs messages afin de garantir la confidentialité des échanges. Ils possèdent donc la même clé pour chiffrer et déchiffrer leurs messages. La cryptographie symétrique est redoutable en termes de performance, car les algorithmes sont accélérés matériellement et les clés sont assez courtes. Le problème se situe au niveau de la scalabilité, en effet introduisons un troisième larron : Colombo (C). Si tout le monde veut communiquer de façon sécurisée, il faut une clé par paire possible : A-B, A-C et B-C. Il faut donc trois clés. Si on ajoute encore une quatrième personne, on passe à six clés, etc. Les clés sont donc plus liées à une communication pair à pair plutôt qu’à une personne. C’est pour ça que vous pouvez voir que ces clés sont parfois appelées clés de session dans la littérature.
La cryptographie asymétrique a un fonctionnement différent. Chaque personne génère une biclé : une clé publique et une clé privée. Contrairement à la cryptographie symétrique, les clés sont liées à une identité plutôt qu’à une session. La cryptographie asymétrique est donc généralement associée aux problématiques d’authentification. Cette biclé se compose d’une clé publique et une clé privée. Les règles sont :
- Ce qui est chiffré avec la clé publique de A se déchiffre avec la clé privée de A ;
- Ce qui est chiffré avec la clé privée de A se déchiffre avec la clé publique de A ;
- La clé privée reste dans la poche du propriétaire quoi qu’il arrive (ça veut dire qu’elle ne se prête pas et qu’elle ne transite pas par le réseau) ;
- La clé publique se distribue à tout le monde (par exemple, via des certificats).
L’art de gérer cette cryptographie asymétrique se nomme Infrastructure de Gestion de Clés (IGC) ou Public Key Infrastructure (PKI). Je préfère l’acronyme anglo-saxon PKI, car il met l’accent sur la difficulté de partager les clés publiques.
Mais que peut-on faire avec la cryptographie asymétrique ? Elle sert à deux choses : chiffrer et signer. Je suis A, je veux envoyer un message chiffré à B. Je récupère la clé publique de B (principe 4) et je chiffre le message avec. B pourra déchiffrer le message avec sa clé privée (principe 1). Maintenant, B veut s’assurer que je suis bien à l’origine du message. Je vais ajouter une signature à mon message. Cette signature consiste à appliquer une fonction de hachage (cf. note) sur le message en clair pour créer une empreinte (ou digest). Je chiffre ensuite cette empreinte avec ma clé privée. En récupérant ma clé publique, B peut déchiffrer la signature pour récupérer l’empreinte. B applique ensuite la fonction de hachage sur le message déchiffré pour voir si l’empreinte produite coïncide avec celle reçue (c’est-à-dire issue du déchiffrement de ma signature).
Fonctions de hachage
Une fonction de hachage associe une image de taille arbitraire en entrée, une image de taille fixe en sortie. La propriété essentielle est que cette fonction est pratiquement impossible à inverser, c'est-à-dire que si l'image d'une donnée par la fonction se calcule très efficacement, le calcul inverse d'une donnée d'entrée ayant pour image une certaine valeur se révèle impossible sur le plan pratique. Pour cette raison, on dit d'une telle fonction qu'elle est à sens unique.
2. Certificats
Cette section va effleurer les aspects cryptographiques pour se concentrer sur ce qui concerne l’administrateur système. Quelle clé sert à signer quoi ? Ou encore, qui garantit quoi ?
2.1 Un certificat, pourquoi ?
Si on réduit un certificat à sa fonction la plus basique, elle est de distribuer une clé publique. Un certificat contient donc deux informations : une clé publique à distribuer et le nom pleinement qualifié (FQDN) du service s’appuyant sur le certificat. Dans notre laboratoire de test, nous allons certifier un serveur web pour communiquer avec lui en HTTPS, c’est-à-dire en HTTP sur SSL.
SSL (Secure Socket Layer) est un protocole de chiffrement de sessions TCP. Le principe est que le client récupère la clé publique du service qui communique en SSL. Une fois cette clé en poche, il s’en sert pour chiffrer une communication avec le service en SSL (cf. principe numéro 1 de la cryptographie asymétrique). Par cette communication, ils échangent une clé symétrique pour chiffrer leurs échanges futurs. En résumé, la clé publique sert juste à chiffrer un échange pour obtenir une clé de session beaucoup plus efficace en termes de performances. Nous savons maintenant ce que contient un certificat et son cadre d’utilisation. Il reste à expliquer ce qu’on certifie exactement et comment.
Nous avons vu qu’un certificat contient un couple clé publique et FQDN. Ces deux éléments sont nécessaires pour ouvrir sur une machine un socket SSL. Il est utilisé par les services nécessitant un canal chiffré et authentifié. Ainsi, lorsqu’un client cherche à joindre un service en SSL type HTTPS, il commence par faire une requête DNS pour localiser l’adresse IP hébergeant le service à connecter. Le client se connecte ensuite au port TCP en SSL. Le service lui présente un certificat signé par une autorité de certification. La signature consiste à chiffrer l’empreinte du certificat avec la clé privée (cf. principe numéro 2 de la cryptographie asymétrique) d’une autorité de certification ou CA (Certificate Authority).
Une CA est donc un tiers de confiance dont le certificat (donc la clé publique) est distribué sur le client. Par exemple, dans les navigateurs web nous trouvons un magasin contenant tous les certificats des CA bien connues type Digicert, Sectigo, etc. En utilisant la clé publique de la CA stockée dans le magasin, un client peut donc vérifier la signature du certificat distribué par le service certifié (serveur web dans notre article). Attention, la clé privée de la CA ne doit JAMAIS sortir de la machine l’hébergeant (cf. principe numéro 3 de la cryptographie asymétrique).
Il y a deux types de CA précisant le niveau de signature du certificat présenté par le service :
- Auto-signé : lorsque l’on génère la biclé pour le service, le certificat est signé par sa clé privée associée. Le niveau de confiance dans la signature est donc très limité. Cependant, ce genre de certificat peut être tout à fait valable lorsque la seule propriété de sécurité recherchée est le chiffrement du canal de communication avec le service en SSL ;
- CA type tiers de confiance. Dans ce cas, le certificat livré est signé par un tiers de confiance.
On distingue deux types de CA tiers :
- CA racine (ou root CA) : cette CA est celle qui « amorce la pompe ». C’est-à-dire que la CA utilise sa biclé pour faire une auto-signée. Elle attend ensuite les demandes des services à certifier. Ces services émettent ce que l’on appelle une CSR (Certificate Signing Request). Cette CSR contient la clé publique du service à certifier ainsi que son FQDN. La CA y appose sa signature avec sa clé privée pour transformer cette CSR en certificat ;
- CA intermédiaire : la CA intermédiaire se situe entre la CA racine et le service à certifier. La CA intermédiaire dispose d’une clé privée et d’un certificat associé signé par la clé privée de la CA racine. Dans cette topologie, qui est celle de la plupart des infrastructures de gestion de clés, le service envoie sa CSR à certifier à la CA intermédiaire.
La concaténation du certificat racine et du ou des certificats intermédiaires constitue la chaîne de confiance (ou chain of trust). Cette chaîne est nécessaire pour configurer les services s’appuyant sur SSL.
2.2 Laboratoire de test
Nous allons illustrer l’utilisation des certificats en nous basant sur le service Apache installé sur une machine nommée www. Nous allons le faire écouter en SSL sur le port TCP 443 en utilisant tout d’abord un certificat auto-signé par le serveur lui-même. Ensuite, nous installerons une CA sur une machine à part nommée ca. Cette machine recevra la CSR du serveur web, signera cette dernière avec sa clé privée puis lui renverra le certificat (CSR signée) à www. La dernière topologie de CA est la plus compliquée. Elle consistera à ajouter une machine faisant office de CA intermédiaire nommée inter. Cette CA possède une clé privée et un certificat signé par la CA de niveau racine. Elle signera les demandes des différents services à certifier sans exposer la clé privée de la CA racine.
Enfin, nous mettrons en place un service de révocation. La révocation consiste à invalider un certificat émis par une CA. Lorsque le client va récupérer le certificat depuis le service, il va vérifier au moyen d’un protocole donné, la validité du certificat présenté. Dans notre article, nous utiliserons OCSP (Online Certificate Status Protocol) qui s’exécutera sur inter pour révoquer le certificat généré. Tous les flux de CSR et signatures sont résumés dans la figure 1.
Tout notre laboratoire de test sera mis en place avec l’outil OpenSSL. Il existe des scripts tout faits adaptés aux grandes PKI, mais ils en masquent un peu le fonctionnement.
3. Création d’un auto-signé
Dans ce cas de figure, tout se passe sur le serveur web www. Commençons par installer Apache :
Créons un répertoire ssl dans /etc/apache2/ pour travailler dedans :
Nous pouvons générer la biclé et le certificat en une seule commande :
Analysons les paramètres en séquence de la commande. La commande req indique que c’est le module émission de certificat qui est invoqué. L’argument -x509 accolé à req génère un certificat auto-signé à la place d’une CSR. L’argument -newkey génère une clé privée, ici avec l’algorithme asymétrique RSA d’une longueur de 4096 bits. L’argument -keyout indique le fichier dans lequel stocker la clé privée. L’argument -out indique le fichier dans lequel stocker le certificat, ici il s’agit de cert.pem. L’argument -days indique la durée de validité du certificat. Enfin, l’argument -nodes indique que la clé privée n’est pas chiffrée. Si on scrute les sorties, on voit bien que les trois étapes sont bien suivies.
Étape 1, génération de la clé privée :
Étape 2, établissement des attributs de la CSR :
Dans cette seconde étape, il faut renseigner les attributs du certificat de façon interactive. L’attribut auquel il faut être particulièrement attentif est le Common Name qui doit être fixé à la valeur du FQDN du service à certifier. Ici, il s’agit d’un serveur web donc nous fixons l’attribut avec la valeur www.lab.local. L’étape 3 est invisible, mais il s’agit bien de la signature automatique de la CSR générée précédemment pour obtenir le fichier cert.pem. Passons à la configuration d’Apache.
Tel que livré par les mainteneurs du paquet, Apache écoute en HTTP (clair) sur le port 80. Nous allons commencer par configurer l’emplacement des certificats. Cela se passe dans le fichier /etc/apache2/sites-available/default-ssl.conf :
Dans ce fichier, les deux directives à configurer sont SSLCertificateFile et SSLCertificateKeyFile qui contiennent respectivement le certificat auto-signé et la clé privée générés précédemment. Ensuite, on active le module SSL d’Apache :
Puis le site par défaut qui répondra en HTTPS (SSL port 443) :
On redémarre Apache :
Depuis le client, lorsque nous allons sur le serveur web depuis un navigateur en tapant l’URL https://www.lab.local, nous avons un avertissement de sécurité qui nous indique que le certificat est auto-signé et qu’à ce titre, il n’est pas fiable pour authentifier le serveur auprès du client (figure 2).
Nous pouvons tout à fait Accepter le risque et poursuivre. Une fois ce certificat auto-signé validé au niveau du navigateur, il est intéressant d’aller voir dans le magasin des certificats ce qui s’est passé. Sous Firefox, on le trouve dans la section Préférences, puis Vie privée (about:preferences#privacy). Nous voyons qu’un certificat a bien été ajouté dans la section Serveurs (figure 3) et Autorités (de certification, figure 4). Comme il est auto-signé, il fait à la fois office de certificat pour le serveur contacté (www) et d’autorité de certification pour lui-même. En conséquence, ce genre de certificat est inadapté à l’authentification du serveur auprès du client, mais il est tout à fait valide si nous cherchons juste à chiffrer la session HTTP client/serveur.
4. Ajout d’une CA
En vous baladant dans ce magasin, vous allez voir qu’un certain nombre de CA sont pré-installées dans le navigateur. Ainsi, tous les certificats signés par une de ces CA sont reconnus directement par votre navigateur et ne lèvent pas d’alertes. C’est ce service que font payer les autorités de certification type Digicert, Sectigo, etc. Nous allons donc créer la nôtre, l’utiliser pour générer un certificat pour www et l’installer dans le magasin de notre navigateur web.
4.1 Préparation de la CA
Commençons par créer la racine (au niveau système de fichiers) de notre CA. Nous allons la mettre dans /opt/ca :
Plaçons-nous dedans :
Générons la clé privée de la CA :
Ici, la directive genrsa indique que nous générons une clé privée. L’argument -ou indique l’emplacement de la clé, ici CA-key.pem d’une taille de 4096 bits.
Créons ensuite le certificat auto-signé qui amorce la pompe de l’autorité de certification. Ce certificat est amené à être distribué dans les magasins des clients qui vont se connecter au site. Voici la commande :
Pour les arguments, nous sommes en terrain connu. Nous demandons un nouveau certificat : req, -new et -x509, que nous signerons avec la clé de la CA générée juste avant -key CA-key.pem pour 1 000 jours -days. Le nouveau certificat généré sera stocké dans CA-cert.pem avec -out CA-cert.pem. Il nous redemande exactement les mêmes informations que lors de la génération de l’auto-signé de la section précédente. Évidemment, il faut changer le Common Name pour qu’il corresponde au nom de la machine ca, à savoir ca.lab.local.
Passons à la génération et signature du certificat destiné au serveur web.
4.2 Certification du serveur web
Comme précédemment, il nous faut commencer par créer une clé privée :
Ensuite, il faut créer une CSR. Cette CSR est destinée à être signée par la CA. Dedans, on retrouve la clé publique et le FQDN du service à certifier. En effet, lors de sa génération, nous devons répondre aux mêmes questions que lors de l’établissement d’un auto-signé dans les sections précédentes. Le champ critique est une nouvelle fois le Common Name :
Nous envoyons ensuite la CSR à la machine ca pour signature :
Allons sur la machine ca pour procéder à la signature de la CSR reçue :
Nous utilisons la sous-commande x509 d’OpenSSL. Elle indique que nous allons signer un certificat. L’option -req indique que ce certificat est généré à partir depuis une CSR. Ce certificat sera valide 365 jours -days. L’argument -in indique le chemin de la CSR, -CA le certificat de la CA et enfin, -CAkey est le chemin de la clé privée de la CA. L’option -CAcreateserial indique qu’on délègue à OpenSSL la gestion des numéros de série des certificats. Enfin, le -ou indique le nom du fichier contenant le certificat www-cert.pem. Nous le renvoyons au serveur web :
Nous envoyons également le certificat de la CA au serveur web :
Enfin, retournons sur le serveur web pour le configurer :
Par rapport à la configuration de l’auto-signé, nous avons ajouté une nouvelle directive SSLCertificateChainFile qui contient la chaîne de certification. Ici, la chaîne est assez courte, il n’y a que la CA. Redémarrons Apache :
Sur le client vubuntu, il faut récupérer le certificat de la CA pour l’installer dans le navigateur web :
L’installation se fait dans le magasin vu précédemment où il faut importer le certificat de la CA récupéré dans l’onglet Autorités. Lorsque nous consultons le site pour la première fois avec le certificat de la CA installé, nous n’avons plus de page d’avertissement. Passons maintenant à la configuration CA racine avec CA intermédiaire.
5. Configuration du couple CA racine / CA intermédiaire
La dernière configuration à effectuer est la configuration d’une CA racine certifiant une CA intermédiaire qui va certifier le certificat du serveur web. Dans cette configuration, on n’a aucune interaction directe entre la CA racine et les services finaux à certifier. En ce sens, cette dernière configuration nous rapproche du fonctionnement d’une autorité de certification professionnelle.
5.1 Configuration de la CA racine
Nous allons préparer le système de fichiers pour créer une racine pour notre CA racine indépendante des manipulations précédentes. Tout va se passer dans /opt/ca-w-inter.
Commençons par créer la clé privée de la CA racine :
Il y a un nouvel argument -aes256 qui donne un algorithme symétrique de chiffrement de la clé. En pratique, un mot de passe est requis pour déchiffrer la clé avant usage. Il nous est demandé de façon interactive à la création de la clé :
On fixe les droits :
Créons le certificat auto-signé racine :
Par rapport à avant, nous avons un argument -config suivi du fichier openssl.cnf et -sha256 qui force l’utilisation de cet algorithme de hachage pour la signature. Le openssl.cnf est un gros morceau. Le voici :
Nous nous réfèrerons aux sections essentielles à la compréhension au fil de l’eau. Cela commence avec l’argument -extensions qui vaut v3_ca. Nous constatons que l’on trouve une section intitulée de la sorte dans le fichier openssl.cnf. Cette section règlemente l’utilisation du certificat. Par exemple, il est dit que le certificat est un certificat de CA CA:true et que cette contrainte est critique (critical). Une contrainte critique signifie que si une application manipule ce certificat et qu’elle ne considère pas cette extension comme critique, alors elle ne peut pas utiliser le certificat. L’extension keyusage est également critique et dans cette section, elle indique que la clé peut tout signer des empreintes, des CRL et des certificats respectivement digitalSignature, cRLSign, keyCertSign.
Les CRL (Certificate Revocation List) sont des listes de certificats révoqués qui sont vérifiées par le client au moment de son utilisation. Si le certificat proposé est révoqué, alors le client refusera de l’utiliser. Nous verrons un exemple de révocation plus tard. Donc, par rapport aux précédentes générations de certificats, ici on nous demande une clé pour déchiffrer la clé privée de la CA et l’utiliser :
On notera également que les attributs du certificat sont préremplis avec les bonnes valeurs. Ceci est dû au fait que l’on trouve une section req_distinguished_name dans le openssl.cnf qui définit toutes ces valeurs :
Serrons les droits sur le certificat généré :
Affichons le certificat généré (je n’ai laissé que les sections essentielles) :
On retombe bien sur ce qui a été défini dans le fichier openssl.cnf. On notera également la présence d’une section CA_root dans ce fichier qui va renseigner l’emplacement sur le système de fichiers des différents composants de la CA racine.
5.2 Configuration de la CA intermédiaire
Allons sur la machine inter et créons la racine du système de fichiers dédié à notre CA intermédiaire :
On récupère le openssl.cnf. Certaines personnes en font un différent pour chaque CA, je préfère tout mettre dans le même fichier et le balader. C’est personnel, il n y a pas vraiment de bonne pratique à ce niveau :
Générons la clé privée de la CA intermédiaire :
Fixons les droits :
Créons la CSR de la CA intermédiaire à faire signer par la CA racine (il faudra entrer le mot de passe de la clé privée de la CA intermédiaire générée précédemment) :
Envoyons la CSR à signer à la CA racine :
Retournons sur la CA pour procéder à la signature :
Pour cette signature, nous utilisons la sous-commande ca. C’est la sous-commande utilisée par OpenSSL lorsque la signature d’un certificat implique de maintenir une base de données des certificats au sein d’une vraie PKI. D’ailleurs, on constate que cette directive est suivie de -config openssl.cnf -name CA_root qui indique d’utiliser les emplacements de fichiers dans la section CA_root. Nous chargeons ensuite les extensions v3_intermediate_ca. Si on se réfère au fichier openssl.cnf, nous voyons que la seule différence par rapport à V3_ca est pathlen:0. Cette directive signifie qu’il n y a aucune autre CA intermédiaire après celle-ci dans la chaîne de confiance. En gros, cette CA est le dernier intermédiaire avant le service final à certifier. Une fois le certificat signé, nous le renvoyons à la CA intermédiaire inter :
Une fois de retour sur la CA intermédiaire, il nous faut récupérer le certificat de la CA racine pour le concaténer pour créer la chaîne de certification :
Dans le fichier ca-chain.cert.pem, nous avons donc le certificat de la CA racine et de la CA intermédiaire l’un à la suite de l’autre.
5.3 Certification du service Apache par la CA intermédiaire
Commençons par récupérer la chaîne de certification créée ci-dessus :
Nous passons ensuite à la création de la clé privée pour le serveur web :
Génération de la CSR :
Nous l’expédions ensuite à la CA intermédiaire pour signature :
Une fois sur la CA intermédiaire, on le signe :
Dans cette commande, nous indiquons que nous allons mettre à jour les fichiers de la CA intermédiaire -config openssl.cnf -name CA_inter. Nous utilisons ensuite les extensions server_cert. Il y a des choses à dire sur cette section. Tout d’abord, notons que dans l’extension keyUsage, les attributs cRLSign et keyCertSign ont laissé place à keyEncipherment. Cet attribut précise que la clé peut être utilisée pour chiffrer d’autres clés. Rappelons que la phase asymétrique de SSL sert à échanger une clé symétrique de session. Or, il faut pouvoir chiffrer cette clé symétrique pour la transmettre. C’est confirmé par l’extension extendedKeyUsage qui contient l’attribut serverAuth nécessaire pour l’utilisation du certificat au sein du protocole SSL, précisément l’authentification du serveur auprès du client. On envoie ensuite le certificat signé sur le serveur web :
Et on modifie les directives SSL du fichier de configuration :
On notera que SSLCertificateChainFile contient maintenant la chaîne de certification créée à la fin de la section 5.2. Évidemment, un redémarrage d’Apache s’impose :
Sur le client vubuntu, même action que la dernière fois. Il faut récupérer le certificat de la CA racine. Et l’installer dans le magasin :
Une petite sous-commande d’OpenSSL qui peut vous être utile est s_client. C’est une sorte de netcat (aka nc) pour socket SSL qui va notamment se connecter pour afficher toute la chaîne de certification :
Évidemment, le navigateur ne produit aucune erreur à la connexion au site web. Dans les propriétés du certificat, nous pouvons vérifier la présence d’un serveur OCSP de révocation (figure 5).
6. La révocation
Pour être exhaustifs sur le sujet, nous allons voir le processus de révocation du certificat précédemment généré pour notre serveur web. Nous allons donc installer un serveur OCSP (Online Certificate Status Protocol) sur inter. Ce serveur va gérer une base de données des certificats révoqués. OpenSSL intègre un service OCSP. Nous allons l’utiliser. Si on examine les extensions server_cert, on y trouve authorityInfoAccess = OCSP;URI:http://ocsp-inter.lab.local:2555. Ce qui veut dire que dans le certificat délivré pour le serveur web et qu’il va présenter au client, le client retrouve l’adresse du serveur OCSP à requêter avent de faire usage du certificat. Il se trouve sur la machine ocsp-inter.lab.local (qui est un alias de inter) et qui écoute sur le port TCP 2555.
6.1 Installation du service OCSP
Commençons par générer la clé privée du service OCSP :
Puis générons sa CSR avec comme Common Name le FQDN du serveur hébergeant le service OCSP :
Enfin, on signe cette CSR avec la clé privée de la CA intermédiaire et en invoquant l’extension ocsp du fichier openssl.cnf :
Cette extension contient l’attribut extendedKeyUsage qui contient la valeur OCSPSigning. C’est-à-dire que cette clé signe des révocations OCSP.
6.2 Création du certificat pour Apache avec révocation
Je vais donner les commandes en séquence, ce sont les mêmes que celles utilisées tout au long de l’article. Création de la clé privée du serveur web :
Et de la CSR :
On l’envoie sur la machine inter pour certification :
Une fois sur inter, on la signe :
On récupère le certificat sur www :
Enfin, on configure Apache :
Allons sur le client pour voir ce que le serveur nous présente. Cette commande sert à « aspirer » le certificat présenté par le serveur web :
Dans un second temps, nous le visionnons :
On peut voir que le certificat présenté intègre l’emplacement du serveur OCSP à interroger avant usage. Plaçons-nous maintenant sur inter pour lancer le service de révocation :
Cette commande va lancer un serveur OCSP sur le port 2555 de toutes les interfaces disponibles (-port). Il va gérer les certificats indexés dans le fichier /opt/ca-w-inter/ intermediate/index.txt (-index). Enfin, les arguments -rkey et -rsigner permettent de spécifier respectivement la clé et le certificat du service OCSP. Ouvrons une autre console sur inter pour vérifier le certificat signé pour le compte de www :
On vérifie que le certificat www-w-inter-ocsp-cert.pem n’a pas été révoqué par le serveur lancé ci-dessus -url http://127.0.0.1:2555. Ici, le résultat est good. Cela veut dire que le certificat du serveur web est absent des listes de révocation. Nous allons maintenant le révoquer.
6.3 Révocation du certificat
Pour révoquer un certificat, nous nous appuyons sur le paramètre revoke de la sous-commande ca d’OpenSSL. On lui spécifie le certificat à révoquer www-w-inter-ocsp-cert.pem :
Testons à nouveau la validité du certificat de www :
Le certificat a donc bien été révoqué. Lorsque nous accédons au serveur web, nous tombons sur la page présentée en figure 6. La révocation est un succès !
7. Authentification avec un certificat client
Dans cette dernière section, nous allons générer un certificat pour l’utilisateur voulant se connecter au serveur web. Le navigateur de l’utilisateur devra présenter ce certificat au moment d’accéder au site sous peine de s’en voir refuser l’accès.
7.1 Génération du certificat client
Dans cette section, rien de neuf sous le soleil. On génère une clé privée pour l’utilisateur dans un répertoire à part certifs :
Puis on génère la CSR :
Et on l’envoie à la CA intermédiaire :
Passons à la signature de cette CSR par la CA intermédiaire. Nous allons reprendre quasiment la même commande que pour signer le certificat réalisé section 5.3 à destination du serveur Apache. La seule différence est l’appel à l’extension client_cert. Les deux attributs critiques sont nsCertType = client, email et extendedKeyUsage = clientAuth, emailProtection qui indiquent que ce certificat pourra être utilisé pour de l’authentification client SSL ou de la signature d’e-mails. Allons sur la CA intermédiaire pour procéder à la signature :
Nous constatons que dans la sortie de la signature nous retrouvons les attributs positionnés par l’extension client_cert. Nous pouvons envoyer ce certificat sur le client :
Passons à la configuration du couple serveur web / navigateur.
7.2 Configuration du serveur web
La configuration du serveur web est très rapide, il y a deux directives à changer dans le /etc/apache2/sites-enabled/default-ssl.conf :
Le premier paramètre SSLCACertificateFile donne le chemin complet vers le fichier contenant la chaîne de certification qui a signé le certificat client (chez nous c’est la même que pour le certificat serveur). La seconde, SSLVerifyClient à require, indique à Apache qu’un certificat est nécessaire pour accéder au site. Enfin, SSLVerifyDepth à 2 refuse les certificats ayant plus de deux niveaux de CA dans la chaîne. On redémarre ensuite Apache :
Lorsqu’on y accède sans certificat, le serveur nous renvoie une erreur nous indiquant qu’un certificat est requis (figure 7).
Nous allons configurer le navigateur web pour y ajouter le certificat du client.
7.3 Configuration du navigateur web
Avant d’importer le certificat, il est nécessaire de concaténer la clé privée et le certificat dans un seul fichier. Le format PKCS#12 est utilisé pour stocker les clés privées et les certificats dans un seul fichier chiffré. Nous allons utiliser la commande suivante sur le client pour créer ce fichier :
Je vous conseille de mettre une passphrase, car le fichier contient votre clé privée. Une fois ce fichier créé, il faut l’importer dans le magasin du navigateur web. Cela se passe dans l’onglet Vos certificats comme indiqué dans la figure 8.
Le navigateur vous demandera la passphrase entrée pour protéger le fichier au format PKCS#12. Une fois l’importation réussie, on retourne sur le site qui nous présente cette fois-ci la pop-up de la figure 9.
Ce pop-up sert à sélectionner le certificat à utiliser pour s’authentifier au cas où on en ait plusieurs. Ici, nous n’en avons qu’un seul donc comme dirait JP, « la question elle est vite répondue ». Une fois le certificat sélectionné, l’accès au site est autorisé. On notera qu’à l’instar des certificats serveurs, les certificats clients peuvent être révoqués en suivant la même logique.
Conclusion
Dans cet article, nous avons retracé le cycle de vie d’un certificat SSL de la création à la révocation. Nous nous sommes essentiellement concentrés sur les certificats « serveurs ». Ces certificats sont destinés à authentifier le serveur auprès du client et à chiffrer la communication. C’est le fonctionnement minimal de SSL. Comme nous l’avons vu, SSL peut également authentifier le client auprès du serveur pour une authentification bilatérale. Cette possibilité est à la base de toutes les authentifications sur tokens matériels type USB. En fait, votre token physique fait office de fichier PKCS#12 et il est manipulé par les librairies type OpenSC pour vous authentifier. Vous pourrez retrouver les machines virtuelles du laboratoire utilisées pour l’article à cette URL : https://drive.google.com/file/d/1NQKlNnrllaXfM2F78fn_UxLaaGNAOd8L/view?usp=sharing.
