HTTPS local pour le développement : autorité de certification privée, magasins de confiance et exception localhost

Objectif

Servir l'application localement en HTTPS avec un certificat accepté par les navigateurs et les outils en ligne de commande, de sorte que les cookies Secure, les règles de contenu mixte et les URI de redirection OAuth se comportent comme en production, sans avertissement de certificat et sans certificats publics pour des noms non détenus.

Prérequis

Savoir quand ce n'est pas nécessaire : la spécification Secure Contexts considère une origine comme potentiellement fiable lorsque son hôte est une adresse dans 127.0.0.0/8 ou ::1/128 et, pour les agents utilisateurs qui résolvent les noms localhost vers le bouclage comme l'exige la spécification, lorsqu'il s'agit de localhost ou d'un nom se terminant par .localhost ; un simple http://localhost bénéficie donc déjà des API de contexte sécurisé dans de tels navigateurs. Le HTTPS local se justifie lorsqu'il s'agit de tester un comportement spécifique à TLS, d'utiliser un nom d'hôte de développement hors bouclage, ou de faire fonctionner plusieurs services sous un même nom générique. Les recommandations de Let's Encrypt pour localhost consistent à générer son propre certificat, auto-signé ou signé par une racine locale, et à le faire reconnaître dans le magasin de confiance du système d'exploitation.

Étapes

1. Créer une autorité de certification privée une fois par machine de développement. mkcert -install crée une autorité locale et, selon son README, l'installe dans le magasin de confiance du système ainsi que dans le magasin de Firefox lorsqu'il est présent. Ne jamais valider ni partager la clé de l'autorité ; le README avertit que rootCA-key.pem donne un pouvoir complet pour intercepter les requêtes sécurisées émises depuis la machine.
2. Émettre des certificats feuilles uniquement pour des noms de développement, par exemple mkcert app.localhost "*.dev.example.test" 127.0.0.1 ; jamais pour des noms d'hôte de production.
3. Configurer le serveur local ou le proxy inverse avec le certificat et la clé ; le README précise que mkcert ne configure pas les serveurs à la place de l'utilisateur. Garder ces fichiers hors du contrôle de version et des images de conteneurs.
4. Faire en sorte que les clients non-navigateurs fassent confiance à l'autorité. Le README documente NODE_EXTRA_CA_CERTS pour Node.js, pointant vers le fichier racine dans le dossier affiché par mkcert -CAROOT ; d'autres environnements lisent le magasin du système ou nécessitent leur propre variable. Consigner la variable par outil dans le script d'installation.
5. Sur une seconde machine ou dans un conteneur de développement, répéter l'étape 1 ; chaque machine possède sa propre autorité, si bien que les certificats feuilles sont régénérés, et non copiés.
6. Ajouter une vérification au script d'installation : une requête vers le point d'accès HTTPS local doit réussir sans désactiver la vérification.

Résultat attendu

Le navigateur affiche un certificat valide pour l'origine de développement, les cookies Secure fonctionnent, et personne n'apprend à cliquer pour ignorer les avertissements de certificat.

Limites et base de vérification

Une autorité de certification privée dans le magasin du système est une décision de sécurité propre à cette machine ; la clé ne doit être lisible que par son utilisateur. Les appareils mobiles nécessitent une importation séparée du fichier racine, décrite dans le README de mkcert, qui répertorie aussi Java (lorsque JAVA_HOME est défini) et le magasin NSS utilisé par Firefox parmi ses magasins de confiance, sélectionnables avec TRUST_STORES. Procédure synthétisée à partir des documents cités ; aucune mesure n'est revendiquée.