NET::ERR_CERT_COMMON_NAME_INVALID et fichier hosts : solutions

L'erreur NET::ERR_CERT_COMMON_NAME_INVALID survient lorsque le certificat SSL/TLS présenté par le serveur web ne correspond pas au nom de domaine saisi dans le navigateur. Quand vous utilisez le fichier hosts pour router un domaine de test ou de préproduction vers votre serveur local, le certificat servi par défaut est rejeté par les contrôles de sécurité du navigateur.

Comment corriger NET::ERR_CERT_COMMON_NAME_INVALID avec le fichier hosts

Pour corriger NET::ERR_CERT_COMMON_NAME_INVALID lors de l'utilisation du fichier hosts, installez une autorité locale avec `mkcert -install`, générez un certificat TLS incluant vos noms d'hôtes et sous-domaines (via les extensions SAN), puis configurez votre serveur web local (Nginx, Caddy ou Apache) pour servir ce certificat sur le port 443.

Pourquoi cette erreur survient lors des tests avec le fichier hosts

Lorsque vous ajoutez une ligne dans votre fichier hosts :

127.0.0.1  monsite-client.test

Le flux réseau se déroule ainsi :

Consultez également notre guide sur la configuration HTTPS en local et la résolution de l'autorité de certification invalide.

Tableau comparatif des solutions

Solution recommandée : Générer un certificat SAN avec mkcert

Depuis la dépréciation du champ Common Name historique au profit du standard Subject Alternative Name (SAN, RFC 2818), tout certificat moderne doit lister explicitement les domaines cibles.

1. Installer mkcert

Sur macOS (Homebrew) :

brew install mkcert
brew install nss # Recommandé pour le support de Firefox

Sur Linux (Ubuntu/Debian) :

sudo apt install libnss3-tools
curl -JLO "https://dl.filippo.io/mkcert/latest?for=linux/amd64"
chmod +x mkcert-v*-linux-amd64
sudo cp mkcert-v*-linux-amd64 /usr/local/bin/mkcert

Sur Windows (PowerShell via Chocolatey) :

choco install mkcert

2. Initialiser l'autorité de certification locale

mkcert -install

Cette commande ajoute l'autorité racine dans le magasin de certificats de votre système d'exploitation.

3. Créer le certificat couvrant vos domaines déclarés dans le fichier hosts

Spécifiez tous vos domaines et wildcards dans la même commande :

mkcert monprojet.test "*.monprojet.test" api.monprojet.test localhost 127.0.0.1

La commande génère deux fichiers clés dans votre répertoire courant :

• monprojet.test+4.pem (le certificat public)
• monprojet.test+4-key.pem (la clé privée)

4. Configurer votre serveur web local (exemple Nginx)

server {
    listen 443 ssl http2;
    server_name monprojet.test api.monprojet.test;

    ssl_certificate /chemin/vers/monprojet.test+4.pem;
    ssl_certificate_key /chemin/vers/monprojet.test+4-key.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto https;
    }
}

Rechargez Nginx (sudo nginx -s reload) et rafraîchissez votre page. Le cadenas de sécurité valide la connexion sans erreur de nom commun.

Le piège des extensions TLD : pourquoi éviter .dev et .app

Certains développeurs choisissent des extensions comme monprojet.dev ou monprojet.app dans leur fichier hosts.

• Les extensions .dev et .app sont des domaines de premier niveau réels gérés par Google Registry.
• Ils sont inscrits dans la liste HSTS preload intégrée aux navigateurs.
• Tout accès en HTTP est immédiatement converti en HTTPS strict, et le navigateur interdit formellement de cliquer sur "Continuer vers le site" si le certificat n'est pas irréprochable.

Pour vos configurations de test dans /etc/hosts, privilégiez toujours les TLD réservés définis par la RFC 2606 :

• .test (ex: client.test)
• .example
• .localhost