Que ce soit pour administrer mes propres services ou tester des communications sécurisées (i.e. HTTPS, SAML,…), l’étape de création des certificats, et de la PKI correspondante, est incontournable.

Je ne sais pas vous, mais moi, ça n’est pas vraiment mon étape préférée. Je ne trouve pas la documentation ni l’usage de openssl(1) particulièrement agréable alors, sans aucune honte, je préfère les solutions graphiques…

Avant de commencer

Installer XCA

XCA est l’application graphique que je préfère pour gérer mes PKI. Il permet de créer les clés, les certificats et les demandes de signatures très intuitivement. Et à la fin, d’exporter le tout facilement.

La page de téléchargement propose tout le nécessaire pour obtenir l’application :

1. Un exécutable Windows pour l’installer,
2. Une archive portable pour l’exécuter sous Windows sans l’installer,
3. Un package pour les utilisateurs de Mac,
4. Une archive contenant le code source si vous voulez le compiler vous-même.

Sous Linux, la plupart des distributions ont un package xca installable en une ligne de commande. Sous Debian, Ubuntu et ses dérivés, le package est disponible par défaut.

sudo apt-get install xca

Pour Red Hat, Centos et ses dérivés, il vous faudra d’abord installer les dépôts additionnels (EPEL) mais une fois fait, xca est disponible en une ligne :

sudo yum install xca

Créer une Base de donnée

Pour stocker vos certificats, et surtout vos clés privées, xca utilise un fichier chiffré spécifique qu’il vous est donc nécessaire de créer.

Pour cela, allez dans le menu Fichier / Nouvelle base de données, choisissez l’emplacement de votre fichier, donnez lui un nom et enregistrez. L’écran suivant vous demande d’entrer un mot de passe pour sécuriser votre fichier.

Créer la CA

Sans surprise, la première chose à créer est la CA, qui nous servira à signer nos autres certificats. Et pour cela, on va dans l’onglet certificats et on clique sur le bouton Nouveau Certificat.

Source

xca ouvrira une nouvelle fenêtre permettant de configurer finement le certificat. Nous n’allons ici que configurer le minimum à travers deux des onglets, source et sujet.

L’onglet Source, ouvert par défaut, permet de configurer le type de certificat comme suit :

• Signer : laisser créer un certificat auto-signé,
• Algorithme de signature : on laisse SHA 256,
• Modèle pour le nouveau certificat : choisir [Default] CA, et cliquez sur le bouton « Appliquer tout »

Je vous conseille vivement de cliquer ensuite sur le bouton Appliquer tout. Ce qui vous simplifiera les étapes suivantes, comme les extensions, l’utilisation de la clé et autres onglets. Si vous savez ce que vous faites, vous pouvez aussi ne rien appliquer et configurer tous ces aspects manuellement.

Sujet

Le deuxième onglet permet de configurer le sujet, c’est à dire la carte d’identité du certificat. Si vous créez une PKI pour faire des tests, seul les deux champs suivants sont importants :

• Nom Interne : qui est utilisé pour l’affichage dans xca,
• commonName : qui est le nom du certificat et l’identifie dans toutes les autres applications.

Les autres champs n’ont qu’un but informatif (détailler l’identité du propriétaire du certificat). Ils sont obligatoires lorsqu’on veut faire signer un certificat par une autorité mais comme vous créez la votre, faite comme vous le sentez.

Dans tous les cas, assurez vous de fournir une clé privée. Pour cela, cliquez simplement sur le bouton Générer une nouvelle clé.

Un pop-up s’ouvrira vous demandant des précisions :

• Nom : utilisé dans xca pour le lister, personnellement, je laisse le cn du certificat,
• Type de clé : algorithme asymétrique pour lequel la clé est utilisée, la valeur par défaut, RSA, correspond à la plupart des cas,
• Taille de la clé : la valeur par défaut est un peu dépassée, l’ANSSI conseille 3072 bits, alors choisissons 4096.

Vous trouverez la justification des 3072 bits dans la section 2.2.1.1 des recommandations de l’ANSSI. Bien qu’aucune clé de moins de 1024 bits n’ait été publiquement factorisée à ce jours, l’ANSSI considère qu’ajouter une marge est nécessaire pour rester prudent.

Cliquer sur Créer et après un court délai, XCA vous informera avoir réussi.

Pour notre cas, nous n’avons pas besoin de configurer les autres onglets, on clique donc sur OK.

Créer le certificat serveur

Partant du principe que vous voulez créer votre PKI pour un serveur (i.e. web), nous pouvons passer au certificat serveur.

De retour dans l’écran des certificats, on clique donc sur Nouveau Certificat.

Source

On retrouve la même fenêtre que précédemment mais cette fois, nous allons changer quelques paramètres.

• Signer : choisir utiliser ce certificat pour signer puis choisir votre CA, root.example.com
• Modèle pour le nouveau certificat : choisir [Default] HTTPS_server.

Encore une fois, je vous conseille de cliquer sur Appliquer tout, ce qui évitera de configurer les onglets suivants.

Sujet

Comme précédemment, nous poursuivons avec la carte d’identité du certificat dans l’onglet Sujet.

• Nom Interne : comme précédemment, il n’est utilisé que pour l’affichage.
• CommonName : doit correspondre au nom d’hôte de votre serveur web, www.example.com par exemple.

Le CommonName était initialement utilisé pour vérifier que le certificat correspondait au site qui l’utilisait mais cette utilisation est maintenant considérée comme obsolète, chrome et firefox ne se basent plus sur ce champ mais sur l’extension « Subject Alternative Name ». Pour vous faciliter la tâche, XCA copie automatiquement votre CN dans cette extension.

Les autres champs sont à but informatif et ne sont important que si vous vouliez faire signer votre certificat par une autorité de certification. C’est à partir de ces données que l’autorité vérifiera votre identité et signera votre certificat. Ici, puisque nous créons notre propre PKI, ces champs n’auront pas d’impact.

Comme précédemment, il faut également Générer une nouvelle clé privée.

Extensions

Comme nous l’avions abordé précédemment, les navigateurs récents ne se basent plus sur le CommonName (CN) mais sur l’extension Subject Alternative Name (SAN) pour vérifier que le certificat reçu correspond au cite contacté.

Si votre certificat n’est créé que pour un seul domaine, XCA vous a déjà copié le CN dans l’extension SAN, vous n’avez donc rien à ajouter et pouvez sauter cette étape.

Si votre serveur est configuré pour répondre à plusieurs domaines (i.e. example.com - pour les utilisateurs qui oublient le www), vous devez l’ajouter spécifiquement.

• X509v3 Subject Alternative Name : pour le configurer, il faut cliquer sur Modifier.

xca ouvre alors un pop-up qui nous permet d’ajouter les extensions. Ici, nous n’allons ajouter qu’une seule entrée DNS, mais suivant votre situation, vous pouvez en mettre plusieurs, y compris des adresses IP.

• Type : choisir DNS
• Contenu : y mettre votre nom de domaine (i.e. example.com).

Remarquez la case cochée en haut à droite « Copier le nom commun » qui, comme son nom l’indique, copie le CommonName, vous évitant de devoir l’ajouter manuellement.

Cliquer sur Appliquer pour prendre en compte l’extension.

Vu que nous n’avons pas besoin de paramètres supplémentaires pour ce certificat, cliquez sur ok.

Exporter

À ce stade, les certificats et les clés n’existent que dans la base de donnée de xca que vous avez créée. Il est donc temps de les exporter pour pouvoir les inclure dans vos logiciels.

Les certificats

Depuis l’application, dans l’onglet Certificats, cliquez sur le bouton Exporter.

xca ouvre un popup qui vous demande quelques paramètres pour l’export :

• Nom du fichier : la valeur par défaut est sûrement déjà adaptée mais vous pouvez choisir un autre fichier. Même si les logiciels ne font pas la différence, je vous conseille de garder une extension .crt.
• Format d’exportation : à moins d’avoir des besoins très spécifiques, et dans ce cas là, vous saurez ce que vous faites, laissez tel quel, PEM (*.crt).

Cliquez ensuite sur OK pour que xca exporte votre certificat dans le fichier.

Les clés

Depuis l’application, dans l’onglet Clés privées, cliquez sur le bouton Exporter.

Comme précédemment, xca ouvrira un pop-up pour personnaliser l’export.

• Nom du fichier : la valeur par défaut est déjà adaptée mais, personnellement, je préfère changer l’extension en .key (pour que tout le monde sache que c’est bien une clé).
• Format d’exportation : à moins d’avoir des besoins très spécifiques, et dans ce cas là, vous saurez ce que vous faites, laissez tel quel, PEM (*.pem).

Cliquez ensuite sur OK pour que xca exporte votre clé privée dans le fichier.

Ce fichier doit être stocké de manière sécurisée car quiconque en prend connaissance peut vous usurper (signer ses propres certificats, intercepter vos communications, …).

Et après ?

Vous voici l’heureux propriétaire de votre propre autorité de certification (votre certificat racine et sa clé privée) qui vous a permis de signer le certificat d’un serveur web. Vous pouvez répéter cette opération pour peupler votre PKI de toujours plus de certificats.

Pour l’utiliser, il ne vous reste plus qu’à déployer les fichiers exportés :

• La CA sur tous les postes de votre réseau, ainsi que chez vos clients, partenaires et autres relations qui auraient besoin de communiquer avec votre serveur,
• Le certificat et la clé du serveur sur ce dernier et puisque vous avez déployé la CA partout ailleurs, il n’y a rien à faire de plus.

Si vous souhaitez effectuer une copie de sauvegarde, le plus pratique est encore de sauvegarder le fichier de la base de donnée. Et si vous voulez spécifiquement sauvegarder un certificat et sa clé, exportez les deux au format PKCS .p12.