Pour effectuer des tests d’une application web en local, dans de bonnes conditions, il est judicieux d’utiliser une connexion HTTPS. Le problème, c’est qu’un certificat auto-signé ne permet pas de le faire proprement. C’est là que l’outil open source mkcert intervient : il crée une autorité de certification locale, l’installe dans les magasins de confiance de votre machine, puis génère des certificats reconnus sans le moindre avertissement.
Dans cet article, je vous propose un guide pratique pour installer et utiliser mkcert sur une machine Debian. Nous verrons comment mettre en place l’autorité de certification, générer un certificat pour vos services, l’exploiter avec Nginx ou Apache, et étendre la confiance à une autre machine.
Qu’est-ce que mkcert ?
mkcert est un utilitaire en ligne de commande qui génère des certificats TLS destinés au développement et aux environnements locaux. Il crée une autorité de certification locale, l’ajoute au magasin de confiance du système et à celui des navigateurs, puis signe avec elle les certificats que vous demandez. Résultat : vos services en HTTPS sont acceptés sans alerte, sur les noms de votre choix, y compris localhost, une adresse IP ou un domaine interne.
Cet outil est entièrement gratuit et publié sur GitHub : github.com/FiloSottile/mkcert
Pourquoi un certificat auto-signé ne suffit pas
Un certificat auto-signé est signé par lui-même : aucune autorité connue du système ne le cautionne, donc le navigateur affiche une erreur. Vous pouvez ajouter une exception, mais il faut la répéter sur chaque poste, chaque navigateur et à chaque renouvellement. Ce n’est pas propre pour tester dans de bonnes conditions.
mkcert prend le problème par l’autre bout. Il génère une véritable autorité de certification (une CA racine), l’installe une fois dans les magasins de confiance, puis signe autant de certificats que nécessaire avec cette CA. Tous les certificats qui en découlent sont acceptés d’emblée, sans exception à valider. Le tout en local, sans connexion avec un service externe.
Ce que mkcert ne fait pas
Soyons clairs sur le périmètre de l’outil, cela évitera les mauvaises surprises :
Il ne configure pas vos serveurs. mkcert produit un couple certificat / clé, à vous de l’intégrer dans Nginx, Apache, Traefik ou votre application.
Il ne gère aucun renouvellement automatique. Il n’y a ni agent, ni tâche planifiée, ni protocole ACME.
Il n’a aucune vocation à servir en production ou sur les postes d’utilisateurs finaux. C’est un outil pour du dev ou du lab.
Prérequis
Pour suivre ce tutoriel, il vous faut :
Une machine sous Debian, avec un accès sudo.
Le paquet libnss3-tools, indispensable pour que mkcert alimente le magasin de confiance de Firefox et de Chrome ou Chromium.
Une résolution DNS fonctionnelle pour les noms que vous comptez utiliser, via /etc/hosts ou un serveur DNS interne. Sur ce point, notre tutoriel sur Technitium DNS Server pour héberger son propre serveur DNS vous sera utile si vous gérez un domaine interne dans votre homelab.
Installer mkcert sur Debian
Deux méthodes s’offrent à vous. Je vous recommande la première, plus simple.
Depuis les dépôts officiels Debian
mkcert est disponible sous la forme d’un paquet prêt à l’emploi pour Debian. L’installation se résume donc à deux paquets :
sudo apt update
sudo apt install mkcert libnss3-tools
Vérifions la version installée :
mkcert -version
v1.4.4
Depuis le binaire officiel
Si vous préférez utiliser la source du binaire, récupérez la version publiée sur GitHub :
curl -L -o mkcert https://github.com/FiloSottile/mkcert/releases/download/v1.4.4/mkcert-v1.4.4-linux-amd64
chmod +x mkcert
sudo mv mkcert /usr/local/bin/mkcert
Des binaires sont également disponibles pour arm64, ce qui couvre les Raspberry Pi et les VM ARM. Là encore, n’oubliez pas sudo apt install libnss3-tools.
Créer l’autorité de certification locale
Nous devons maintenant appeler mkcert avec l’option -install afin de créer la CA racine puis de l’ajouter aux magasins de confiance détectés. C’est une étape à effectuer une seule fois sur cette machine.
mkcert -install
Sur un poste Debian avec Firefox installé, la sortie ressemble à ceci :
Quelques précisions sur ce qui vient de se passer :
Lancez cette commande sans sudo. mkcert élèvera lui-même ses privilèges au moment d’écrire dans le magasin système, ce qui garantit que les fichiers de la CA restent dans votre répertoire personnel.
Sur Debian, la CA est déposée dans /usr/local/share/ca-certificates/ sous la forme d’un fichier .crt, puis update-ca-certificates est exécuté pour rafraîchir le magasin système.
La ligne relative aux navigateurs n’apparaît que si certutil est présent et si un profil Firefox ou Chromium existe déjà. Si vous venez d’installer le navigateur, lancez-le une première fois puis rejouez mkcert -install. Ce point sera détaillé juste après.
Redémarrez vos navigateurs pour qu’ils prennent en compte la nouvelle autorité de certification locale.
Le cas des navigateurs récents
Sur une machine à jour, mkcert -install peut se solder par l’erreur spécifiée ci-dessous, alors même que le magasin système a été correctement alimenté :
The local CA is now installed in the system trust store! ⚡️
ERROR: no Firefox and/or Chrome/Chromium security databases found
Pourtant, Mozilla Firefox était bien présent sur ma machine. L’explication tient à un mouvement de fond côté navigateurs : Mozilla comme Google ont aligné leurs répertoires sur la spécification XDG Base Directory, à quelques versions d’intervalle. Les emplacements historiques, connus de mkcert 1.4.4 publié en 2022, ne sont donc plus ceux utilisés par défaut.
NavigateurEmplacement connu de mkcertEmplacement utilisé désormaisFirefox, versions récentes~/.mozilla/firefox/~/.config/mozilla/firefox/Chrome et Chromium, versions récentes~/.pki/nssdb~/.local/share/pki/nssdb
Dans les deux cas, l’ancien chemin reste utilisé s’il existe déjà. Seules les installations récentes, sans historique, basculent vers le nouvel emplacement. C’est ce qui explique que le problème touche surtout les machines fraîchement installées.
Vous aurez peut-être relevé que la sortie présentée plus haut montre au contraire une installation réussie dans le magasin Firefox. Il n’y a pas de contradiction : Debian distribue Firefox ESR, une branche avec un support étendu qui reste plusieurs versions en retard sur la branche rapide et conserve donc l’ancien emplacement. Toutefois, ceci va bouger puisque Firefox 153 est désormais la nouvelle version ESR (depuis juillet 2026).
Le problème se manifeste plutôt sur les distributions qui suivent la branche rapide de Firefox, ou dès qu’un navigateur Chromium récent crée sa base de données. J’ai eu le cas sur une machine Linux Mint utilisée comme seconde machine pour ensuite utiliser le certificat mkcert (ce point sera détaillé par la suite).
J’ai dû commencer par localiser les bases NSS :
find ~ -name “cert9.db” 2>/dev/null
Ce qui m’a retourné ces chemins :
/home/flo/.config/mozilla/firefox/7xfvgrng.default-release/cert9.db
/home/flo/.local/share/pki/nssdb/cert9.db
Il suffit ensuite d’importer la CA à la main avec certutil, ce qui revient exactement à ce que mkcert aurait fait. Pour Firefox, en adaptant l’identifiant du profil au vôtre :
# Importer la CA dans le profil Firefox
certutil -A -d sql:$HOME/.config/mozilla/firefox/7xfvgrng.default-release -t “C,,” -n “mkcert development CA” -i “$(mkcert -CAROOT)/rootCA.pem”
# Contrôler que l’autorité est bien présente
certutil -L -d sql:$HOME/.config/mozilla/firefox/7xfvgrng.default-release | grep mkcert
Pour Chrome et Chromium, la base est unique et le chemin ne varie pas :
# Importer la CA dans la base NSS partagée de Chrome
certutil -A -d sql:$HOME/.local/share/pki/nssdb -t “C,,” -n “mkcert development CA” -i “$(mkcert -CAROOT)/rootCA.pem”
L’option -t “C,,” déclare le certificat comme autorité de confiance pour l’authentification des serveurs TLS. Redémarrez le navigateur concerné et l’avertissement sur la connexion HTTPS disparaîtra. Notez que la base de Chrome n’est créée qu’au premier lancement du navigateur, donc ouvrez-le une fois avant de jouer la commande.
Où sont stockés les fichiers de la CA
L’emplacement du répertoire de la CA est donné par l’option -CAROOT :
mkcert -CAROOT
Ce dossier contient deux fichiers :
rootCA.pem, le certificat de l’autorité, valable 10 ans. C’est lui que vous distribuerez aux autres machines (si c’est pour du dev en local, ce ne sera pas utile).
rootCA-key.pem, la clé privée de l’autorité, protégée en lecture seule pour son propriétaire.
Attention : quiconque met la main sur rootCA-key.pem peut émettre un certificat valide pour n’importe quel domaine et intercepter le trafic TLS de toute machine qui fait confiance à cette CA. Ce fichier ne doit jamais être partagé, ni copié sur un poste tiers. Ici, c’est une CA locale sans importance, mais c’est toujours bien de le rappeler.
Note : la variable d’environnement CAROOT permet de pointer vers un autre répertoire, ce qui autorise le maintien de plusieurs CA en parallèle (une par projet, par exemple).
Générer un certificat pour vos services
La CA étant en place, nous allons pouvoir générer un premier certificat. Au sein de la commande, vous listez tous les noms que le certificat doit couvrir. Domaines, sous-domaines, caractère générique, localhost et adresses IP peuvent être mélangés dans la même commande.
Voici un exemple où tout est mélangé :
mkcert app.it-connect.local “*.it-connect.local” localhost 127.0.0.1 ::1
Dans la commande précédente, j’ai protégé le caractère générique par des guillemets, sans quoi le shell tenterait de l’interpréter avant même que mkcert ne le reçoive. Et gardez en tête l’avertissement affiché par l’outil : un wildcard X.509 ne couvre qu’un seul niveau de sous-domaine.
Deux fichiers sont créés dans le répertoire courant. Le suffixe +4 indique simplement que quatre noms supplémentaires accompagnent le premier. Les certificats émis sont valables 2 ans et 3 mois. Si les noms de fichiers générés ne vous conviennent pas, imposez vos propres chemins avec -cert-file et -key-file. Ces options doivent impérativement précéder la liste des noms :
mkcert -cert-file /etc/ssl/mkcert/app.pem -key-file /etc/ssl/mkcert/app-key.pem app.it-connect.local
Vérifier le contenu du certificat
Avant d’aller plus loin, et bien que ce soit facultatif, vous pouvez contrôler ce que contient réellement le certificat, notamment les noms alternatifs du sujet (SAN), qui sont ce que le navigateur regarde en pratique.
openssl x509 -in app.it-connect.local+4.pem -noout -subject -issuer -dates -ext subjectAltName
Si on analyse la capture d’écran ci-dessus, on constate que le champ OU reprend le nom d’utilisateur et le nom d’hôte de la machine qui a créé la CA, ce qui permet d’identifier facilement l’origine d’un certificat. Pour aller plus loin sur l’analyse d’un certificat, notre tutoriel dédié explique comment récupérer et lire le contenu d’un certificat x.509 avec OpenSSL.
Utiliser le certificat avec Nginx ou Apache
Le rôle de mkcert, c’est de créer la CA et de délivrer des certificats. Ce certificat doit ensuite être lié à une application, et bien souvent, cela passe par la configuration d’un serveur Web. Voici comment les intégrer aux deux serveurs web les plus courants sous Debian : Nginx (sudo apt update && sudo apt install nginx) et Apache2 (sudo apt update && sudo apt install apache2).
Commençons par déplacer les fichiers dans un emplacement adapté et sécurisons la clé privée.
Créez le répertoire de destination :
sudo mkdir -p /etc/ssl/mkcert
Déplacez le certificat et la clé :
sudo mv app.it-connect.local+4.pem app.it-connect.local+4-key.pem /etc/ssl/mkcert/
Enfin, vous devez restreindre l’accès à la clé privée au seul compte root :
sudo chown root:root /etc/ssl/mkcert/app.it-connect.local+4-key.pem
sudo chmod 600 /etc/ssl/mkcert/app.it-connect.local+4-key.pem
Côté Nginx, créez un fichier de site dédié plutôt que de modifier /etc/nginx/nginx.conf. Sur Debian, les hôtes virtuels se déclarent dans /etc/nginx/sites-available/ puis s’activent par un lien symbolique dans /etc/nginx/sites-enabled/. Créez le fichier de configuration :
sudo nano /etc/nginx/sites-available/app.it-connect.local
Puis, ajoutez la configuration ci-dessous. Elle déclare un hôte basique, accessible en HTTPS (HTTP redirigé vers HTTPS) et avec les certificats déclarés. La racine de l’application web est associée au répertoire /var/www/app et au nom app.it-connect.local. Pour cette démonstration, j’en profite aussi pour créer un fichier basique dans la racine web.
server {
listen 80;
listen [::]:80;
server_name app.it-connect.local;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
http2 on;
server_name app.it-connect.local;
ssl_certificate /etc/ssl/mkcert/app.it-connect.local+4.pem;
ssl_certificate_key /etc/ssl/mkcert/app.it-connect.local+4-key.pem;
root /var/www/app;
index index.html;
}
Il reste à activer le site, à contrôler la syntaxe puis à recharger le service.
Activez le site en créant le lien symbolique :
sudo ln -s /etc/nginx/sites-available/app.it-connect.local /etc/nginx/sites-enabled/
Vérifiez la configuration avant de l’appliquer et rechargez le service :
sudo nginx -t
sudo systemctl reload nginx
Le site default livré à l’installation écoute lui aussi sur le port 80, mais il ne perturbe pas notre hôte virtuel puisque le nom de domaine est bien associé à la directive server_name. Une fois que c’est fait, vous pouvez tester !
Côté Apache, activez d’abord le module SSL, puis déclarez l’hôte virtuel dans un fichier dont l’extension .conf est obligatoire :
sudo a2enmod ssl
sudo nano /etc/apache2/sites-available/app.it-connect.local.conf
Ajoutez ceci dans le fichier de configuration :
ServerName app.it-connect.local
DocumentRoot /var/www/app
SSLEngine on
SSLCertificateFile /etc/ssl/mkcert/app.it-connect.local+4.pem
SSLCertificateKeyFile /etc/ssl/mkcert/app.it-connect.local+4-key.pem
Sauvegardez et enregistrez. Activez le site puis vérifiez la configuration avant de recharger le service.
sudo a2ensite app.it-connect.local
sudo apache2ctl configtest
sudo systemctl reload apache2
Le port 443 est mis en écoute par le fichier ports.conf dès que le module SSL est actif, il n’y a donc rien à ajouter de ce côté.
Créez enfin la racine du site si elle n’existe pas (et créez un index basique pour le site web, si besoin) :
sudo mkdir -p /var/www/app
echo “” | sudo tee /var/www/app/index.html
Maintenant que votre serveur web est configuré, il ne reste plus qu’à tester ! Pour cela, vous devez accéder à votre site, par exemple : https://app.it-connect.local. Procédez en local pour l’instant, c’est-à-dire avec un navigateur installé sur le poste où la CA a été installée. Le cadenas doit s’afficher sans le moindre avertissement ! Voici un exemple :
Faire confiance à la CA sur vos autres machines
C’est ici que mkcert devient réellement intéressant en homelab : un seul certificat racine à distribuer, et l’ensemble de vos services internes passe en HTTPS propre sur tous vos postes. Je dis ça, mais il y a aussi d’autres façons de procéder. C’est un exemple, comme le fait d’utiliser mkcert pour avoir un certificat valide lorsqu’on dev en est un autre.
Sur le principe : l’installation dans un magasin de confiance ne nécessite pas la clé privée de la CA. Vous n’avez donc à copier que rootCA.pem.
Le transfert se fait très bien en SCP, depuis la machine qui héberge la CA. Dans cet exemple, celle-ci a été créée sur le serveur Debian (192.168.220.128) et nous la déployons vers un poste client situé sur le même réseau (192.168.220.134) :
scp “$(mkcert -CAROOT)/rootCA.pem” [email protected]:~/mkcert-ca/
L’usage de $(mkcert -CAROOT) évite d’avoir à retenir le chemin exact du répertoire. Notez bien qu’on ne transfère que rootCA.pem. J’insiste là-dessus : rootCA-key.pem reste sur la machine d’origine, et il n’y a aucune raison de le faire voyager sur le réseau.
Une fois le fichier déposé, deux options s’offrent à vous sur la machine de destination.
La première consiste à réutiliser mkcert, ce qui suppose de l’installer également sur cette machine :
sudo apt install mkcert libnss3-tools
Puis, vous devez pointer CAROOT sur le dossier contenant rootCA.pem, puis installer la CA :
export CAROOT=~/mkcert-ca
mkcert -install
C’est un peu plus lourd, mais cette méthode couvre d’un coup le magasin système, celui de Firefox, celui de Chrome ou Chromium et celui de Java. Sur un poste de travail, c’est ce que vous voulez.
Note : si mkcert renvoie ERROR: no Firefox and/or Chrome/Chromium security databases found, reportez-vous à la section précédente où j’évoquais les divergences au niveau des répertoires recherchés par mkcert. Le magasin système, lui, aura déjà été alimenté correctement.
La seconde se passe complètement de mkcert et s’appuie sur les outils déjà présents sur toute machine Debian :
sudo cp ~/mkcert-ca/rootCA.pem /usr/local/share/ca-certificates/mkcert-homelab.crt
sudo update-ca-certificates
Rien à installer, mais seul le magasin système est alimenté. C’est parfait pour un serveur sans interface graphique ou un conteneur, où aucun navigateur n’entre en jeu. Gardez d’ailleurs en tête que sous Linux, Chrome et Chromium s’appuient sur NSS et non sur le magasin système : cette méthode ne suffit donc pas pour un poste de travail.
Un rapide contrôle permet de valider que l’autorité est bien reconnue par le système :
openssl s_client -connect app.it-connect.local:443 -brief
La ligne Verification: OK confirme que la CA a bien été prise en compte. Si elle affiche une erreur de vérification, c’est que le certificat racine n’a pas été correctement installé dans le magasin système.
Les options qui servent au quotidien
mkcert reste volontairement minimaliste, mais quelques options méritent d’être connues. Rappelez-vous qu’elles doivent toujours être placées avant la liste des noms.
OptionUsage-ecdsaGénère une clé ECDSA (courbe P-256) au lieu de la clé RSA 2048 bits par défaut-clientProduit un certificat d’authentification client, pratique pour tester du mTLS-pkcs12Crée un fichier .p12 regroupant certificat et clé, attendu par certaines applications Java ou Windows-csrSigne une demande de certificat existante, sans que mkcert ne génère la clé privée-uninstallRetire la CA des magasins de confiance, sans supprimer les fichiers
Conclusion
mkcert fait une chose et la fait bien : supprimer la friction du HTTPS en local. Deux commandes suffisent pour disposer d’une autorité de certification opérationnelle et d’un certificat reconnu par le système comme par les navigateurs. C’est facile et rapide.
Même s’il n’y a pas eu de mises à jour depuis plusieurs années, l’outil fonctionne encore très bien et est encore stable aujourd’hui. Pour des tests en local, il peut rendre encore des services.
Pour aller plus loin :
Cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Mon obsession depuis près de 15 ans ? Rendre l’administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu’un métier, l’IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.