Abandonnons le mode ligne de commande avec openssl, pour distribuer des certificats TLS à usage domestique. XCA, disponible sous Linux et Windows, est en mesure de gérer une autorité de certification. (Article inspiré de : Managing a PKI with XCA)
Pourquoi ?
Paske qu’on peut le faire, est une raison suffisante. Il est difficile de générer des certificats serveurs pour des machines non joignable depuis internet (ex : un NAS), et pour certain usage une authentification par certificat client est plus sûre et sans mot de passe.
Ce que nous allons faire
A l’aide XCA nous allons créer notre propre AC (autorité de certification), signer des certificats serveurs et générer des certificats utilisateurs. Cet nouvelle AC devra être déployée sur les équipements l’utilisant (PC linux/Windows, mobile iOS/Lineage) – la partie la plus longue.
Mes choix
L’algorithme de signature secp384r1, validé par le NIST, correspond à un RSA7K et est supporté par une majorité d’OS. SHA-384 est cohérent en matière de robustesse. Ces choix sont super-très-beaucoup robustes par rapport à l’usage prévu.
L’absence de CRL (liste de révocation) se justifie par un usage restreint de cette AC. Si une clé privée, vient à être compromise, le mieux est de changer l’identité du serveur ou de l’utilisateur. L’entretien d’une CRL est assez fastidieux, il faut la régénérer régulièrement et la déposer sur un serveur web qui doit tourner en permanence. XCA ne prévoit pas d’automatisme.
Une AC à tout faire. Pour un grand déploiement, les bonnes pratiques voudraient que l’on dédie une AC à un seul usage : certificat serveur, utilisateur, chiffrement, horodatage, signature de code,…
Démarrage
Après avoir lancé XCA, dans Fichier – Nouvelle base de données, choisir un chemin d’accès où la créer, puis saisir un long mot de passe pour protéger la base dont la future clé privée de l’autorité de certification (Keepass peut vous aider pour le générer et le retenir).
Création de la racine
Dans l’onglet certificat, clic sur nouveau certificat, régler l’algorithme de signature sur SHA384, le modèle sur [défaut CA] et clic sur appliquer les extensions. Elles positionnent les extensions pour que le certificat soit considéré comme une autorité de certification. Une autorité de certification est un certificat auto-signé.
Dans l’onglet sujet, je renseigne quelques champs (seul le « CommonName » est franchement utile), puis je clique sur Générer une nouvelle clé.
Dans la nouvelle fenêtre, dans type de clé, je choisis EC pour une courbe elliptique, puis la courbe secp384r1 (Windows 10 ne support p512 qu’après modification de paramètres). Puis, clic sur créer. Pour rester cohérent, nos certificats utiliserons aussi des courbes elliptiques pour leurs bi-clés.
Une boite de dialogue nous informe de la création de l’objet le plus précieux de notre PKI – la clé privée de notre autorité de certification. Elle est stockée dans la base.
Dans l’onglet Extensions, modifier la période à 30 années (10 par défaut). A noter la petite coche ‘Critical’. Une extension ‘critique’ doit être connue pour faire confiance au certificat. Par exemple, si mon navigateur reçoit un certificat avec une extension critique qu’il ne connaît pas, il doit le rejeter.
Les onglets Usage de la clé, Netscape et Avancé ont été remplis à partir du modèle. Clic sur ‘OK’ pour créer le certificat.
Déployer cette nouvelle racine
Votre nouveau certificat racine doit être reconnu par vos équipements (serveurs, PC, téléphones). Tout d’abord l’exporter, clic sur l’onglet certificat, puis exporter, choisir un chemin et OK. Ceci n’exporte que la partie publique du certificat (sans la clé privée), raison pour laquelle XCA ne propose pas de mot de passe.
Debian Trixie / Ubuntu 24.04
Après avoir transférer le nouveau certificat racine sur la machine, en ligne de commande :
sudo cp /home/marc/Documents/Racine_Maison.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates
Il n’est pas nécessaire de déployer l’AC sur un serveur web, présentant un certificat émis sur celle-ci. Le serveur web ne vérifie pas l’authenticité du certificat qu’il envoie. Le navigateur, lui, doit le fait. Certaine implémentation commerciale l’exige, mais c’est inutile.
Firefox
Sous Linux Firefox ne reprends pas les autorités de certification de l’OS. Dans les paramètres rechercher ‘certificats’, puis sélectionner ‘Gérer les certificats’
Dans le gestionnaire de certificats clic sur autorités et importer…
Après avoir sélection le certificat de la nouvelle autorité (Racine_maison.crt chez moi), cocher les deux cases ‘confirmer cette AC…
Dans le gestionnaire de certificat, la nouvelle AC apparaît dans la liste. Clic sur OK et fermer l’onglet de paramètre de Firefox.
iOS 26
Transférer le certificat racine vers le mobile, (ex : mail), le toucher. Puis, dans les réglages, rechercher « VPN et gestion de l’appareil », toucher la nouvelle AC dans « profil télécharger » et suivre les instructions (il doit manquer une ou deux étapes dans les copies d’écran ci-dessous).
Puis (paske, ce n’est pas fini), il faut faire explicitement confiance à cette nouvelle AC. Aller dans les réglages – général – Informations, descendre en bas, réglages des certificats et valider la nouvelle AC.
Lineage 23
Aucune idée, si sur Android 16, c’est identique. Après avoir déposer le certificat de l’AC racine dans les fichiers du téléphone, aller dans les paramètres, rechercher « Certificat » sélectionner Certificat CA, puis une seconde fois. Sur l’écran d’avertissement toucher « Installer quand même », puis s’authentifier, enfin sélectionner le fichier de certificat de l’AC racine.
Windows 10 22H2
Après avoir déposer le certificat de l’AC racine sur le système de fichier, double-cliquer dessus, puis cliquer sur « installer un certificat ». Sélectionner « Ordinateur Local » (si vous avez les droits d’admin, sinon choisir « utilisateur actuel »), puis clic suivant. Réaliser une élévation de privilège. Choisir placer ‘tous les certificats dans le magasin suivant » (*), clic sur parcourir, choisir « Autorités de certification racine de confiance », OK, puis suivant. Enfin clic sur terminer.
(*) Par défaut Windows placera le certificat dans les autorités de certification intermédiaires. Firefox ne lit pas ce dossier.
A partir de là nous sommes prêts à utiliser nos nouveaux certificats.
Signer un certificat serveur
Générer le CSR sur le serveur
Ici, il s’agit d’un serveur apache sous Linux dont le nom est deb13.dync.fr. Je génère une bi-clé elliptique et un csr (requête de certification)
sudo openssl ecparam -out /etc/ssl/private/ec_web.key -name secp384r1 -genkey
sudo openssl req -new -key /etc/ssl/private/ec_web.key -out ec_web.csr -subj "/CN=deb13.dync.fr" -addext "subjectAltName=DNS:deb13.dync.fr"et je récupère le fichier ec_web.csr sur la machine avec XCA.
Créer son modèle de certificat
Ceci est à faire qu’une seule fois, je le fais juste pour augmenter la durée de validité à 3 ans. Le modèle va permettre de positionner certain champs du certificat, en particulier les extensions concernant son usage.
Dans l’onglet modèle, clic sur nouveau. Dans la boite d’initialisation, je sélectionne [default] TLS_server
Dans l’onglet sujet, donner un nom explicite.
Dans l’onglet extensions, je positionne la durée de validité des certificats à 3 ans. Si vous avez des clients Apple (iOS ou MacOS), cette durée ne peut excéder 825 jours (2ans et 3 mois).
Signer le CSR sur XCA
Dans l’onglet « Requêtes de signature de certificats », clic sur importer et sélectionner ec_web.csr.
Dans l’onglet certificats, clic sur nouveau certificat. Dans l’onglet source,
- cocher la case signer cette requête,
- sélection la requête importée,
- sélectionner « utiliser ce certificat pour signer »,
- sélection le certificat racine nouvellement créé,
- positionner l’algorithme de signature à SHA384,
- sélectionner le modèle nouvellement créer,
- clic sur appliquer tout,
- OK
Il est aussi possible de signer directement depuis l’onglet « requêtes de signature de certificat » à partir d’un clic droit. La requête de signature n’est plus utile, elle peut être supprimée de XCA.
Enfin exporter le certificat. Dans l’onglet certificat, clic sur le petit chevron à gauche de l’AC racine, clic sur le certificat, exporter, puis saisir le chemin du fichier.
Retour sur le serveur web
Copier le certificat serveur dans /etc/ssl/certs/. Puis dans le fichier de configuration du serveur Apache (ex default-ssl.conf) positionner les deux variables de certificat comme suit :
SSLCertificateFile /etc/ssl/certs/ec_web.crt
SSLCertificateKeyFile /etc/ssl/private/ec_web.key
Redémarrer apache par sudo apachectl restart.
Si tout s’est bien passé, l’accès au serveur web depuis un navigateur muni de la nouvelle AC, se fait sans alerte.
Générer certificat client
L’usage est essentiellement pour l’authentification des utilisateurs. Une configuration pour Apache est décrite dans un article précédent.
Un modèle pour une durée de validité de 3 ans.
Comme pour le modèle serveur, créer un nouveau modèle à partir de « [Default]TLS_Client » avec une durée de validité de 3 ans.
Un nouveau certificat
Nous allons directement générer la clé dans XCA. La bonne pratique sécurité, est de procéder comme pour le certificat serveur, générer la bi-clé et le CSR sur la machine utilisatrice, puis signer avec XCA et intégrer le tout dans le client. C’est faisable sur un PC linux ou Windows, sur un téléphone mobile j’ai un doute.
Dans le premier onglet « Source », cocher le bouton »Utiliser ce certificat pour signer » et sélectionner son autorité. Positionner l’algorithme de signature à SHA384. Sélectionner le nouveau modèle TLS_Client_3ans et cliquer sur « Appliquer les extensions ».
Aller à l’onglet Sujet. Renseigner quelques champs, seul le CommonName est nécessaire et cliquer sur Générer une clé.
Saisir le même type clé que pour la racine.
Valider la boite de dialogue d’information de génération de clé, puis une fois revenu à l’onglet Sujet cliquer sur OK, pour créer le certificat.
Export du certificat
La nouvelle clé se trouve dans l’onglet éponyme. Dans l’onglet certificat sélection le nouveau certificat, puis cliquer sur Exporter.
Choisir un nom de fichier et le format pkcs #12 (*.pfx ou .p12). Dans ce format seront mis dans le même fichier le certificat et sa clé privée (indispensable pour utiliser le certificat). Le format « pkcs#12 chain » ajoutera le certificat de l’AC racine, voir des AC intermédiaire s’il y en a.
Saisir un mot de passe assez long et complexe pour éviter le vol du certificat pendant le transit vers le client. Il protège la clé privée du certificat.
Import du certificat dans un client
Le certificat doit être intégré au client qui va l’utiliser. Les mécanismes ressemblent à ceux illustré pour le certificat Racine. Côté Linux, je ne connais pas de « magasin utilisateur » utilisable par plusieurs logiciels. Je l’illustre avec Firefox.
Dans les paramètres de Firefox rechercher certificats, puis cliquer sur ‘Gérer les certificats’.
Aller à l’onglet ‘vos certificats’, puis cliquer sur « Importer… »
Rechercher le fichier de certificat (.pfx) et saisir le mot de passe. Le certificat est prêt à être utilisé.
Je conseille vivement de détruire le fichier pfx, il ne sert plus à rien.
Un premier test avec un serveur web configurer pour accepter cette nouvelle AC donne ceci :
S’en est terminé du petit panorama de XCA.