La plupart du temps, http://localhost
se comporte comme HTTPS à des fins de développement. Toutefois, dans certains cas particuliers (noms d'hôte personnalisés ou utilisation de cookies sécurisés sur plusieurs navigateurs, par exemple), vous devez configurer explicitement votre site de développement pour qu'il se comporte comme HTTPS afin de représenter avec précision le fonctionnement de votre site en production. (Si votre site Web de production n'utilise pas HTTPS, passez en priorité au protocole HTTPS).
Cette page explique comment exécuter votre site en local avec HTTPS.
Pour obtenir de brèves instructions, consultez l'article de référence rapide.**
Exécuter votre site en local avec HTTPS à l'aide de mkcert (recommandé)
Pour utiliser HTTPS avec votre site de développement local et accéder à https://localhost
ou https://mysite.example
(nom d'hôte personnalisé), vous devez disposer d'un certificat TLS signé par une entité approuvée par votre appareil et votre navigateur, appelée autorité de certification (CA) approuvée.
Le navigateur vérifie si le certificat de votre serveur de développement est signé par une autorité de certification approuvée avant de créer une connexion HTTPS.
Nous vous recommandons d'utiliser mkcert, une autorité de certification multiplate-forme, pour créer et signer votre certificat. Pour connaître d'autres options utiles, consultez la section Exécuter votre site en local avec HTTPS: autres options.
De nombreux systèmes d'exploitation incluent des bibliothèques telles que openssl pour la création de certificats. Cependant, ils sont plus complexes et moins fiables que mkcert et ne sont pas nécessairement multiplates-formes, ce qui les rend moins accessibles aux équipes de développement plus importantes.
Préparation
Installez mkcert (une seule fois).
Suivez les instructions pour installer mkcert sur votre système d'exploitation. Par exemple, sous macOS:
brew install mkcert brew install nss # if you use Firefox
Ajoutez mkcert à vos autorités de certification racine locales.
Dans le terminal, exécutez la commande suivante :
mkcert -install
Cela génère une autorité de certification locale. L'autorité de certification locale générée par mkcert n'est approuvée que localement, sur votre appareil.
Générez un certificat signé par mkcert pour votre site.
Dans votre terminal, accédez au répertoire racine de votre site ou au répertoire dans lequel vous souhaitez conserver votre certificat.
Exécutez ensuite la commande ci-dessous :
mkcert localhost
Si vous utilisez un nom d'hôte personnalisé tel que
mysite.example
, exécutez la commande suivante:mkcert mysite.example
Cette commande effectue deux opérations:
- Génère un certificat pour le nom d'hôte que vous avez spécifié.
- Laisse la commande mkcert signer le certificat.
Votre certificat est maintenant prêt et signé par une autorité de certification approuvée localement par votre navigateur.
Configurez votre serveur pour qu'il utilise HTTPS le certificat TLS que vous venez de créer.
La marche à suivre dépend de votre serveur. Voici quelques exemples:
vous vous si vous r j
server.js
(remplacez{PATH/TO/CERTIFICATE...}
et{PORT}
):const https = require('https'); const fs = require('fs'); const options = { key: fs.readFileSync('{PATH/TO/CERTIFICATE-KEY-FILENAME}.pem'), cert: fs.readFileSync('{PATH/TO/CERTIFICATE-FILENAME}.pem'), }; https .createServer(options, function (req, res) { // server code }) .listen({PORT});
vous vous si vous quand http-server.
Démarrez votre serveur comme suit (remplacez
{PATH/TO/CERTIFICATE...}
):http-server -S -C {PATH/TO/CERTIFICATE-FILENAME}.pem -K {PATH/TO/CERTIFICATE-KEY-FILENAME}.pem
-S
exécute votre serveur via HTTPS, tandis que-C
définit le certificat et-K
définit la clé.Avec un serveur de développement React:
Modifiez votre
package.json
comme suit et remplacez{PATH/TO/CERTIFICATE...}
:"scripts": { "start": "HTTPS=true SSL_CRT_FILE={PATH/TO/CERTIFICATE-FILENAME}.pem SSL_KEY_FILE={PATH/TO/CERTIFICATE-KEY-FILENAME}.pem react-scripts start"
Par exemple, si vous avez créé un certificat pour
localhost
dans le répertoire racine de votre site:|-- my-react-app |-- package.json |-- localhost.pem |-- localhost-key.pem |--...
Votre script
start
devrait alors se présenter comme suit:"scripts": { "start": "HTTPS=true SSL_CRT_FILE=localhost.pem SSL_KEY_FILE=localhost-key.pem react-scripts start"
MONTH ⁕ Autres exemples:
Ouvrez
https://localhost
ouhttps://mysite.example
dans votre navigateur pour vérifier que vous exécutez votre site localement avec HTTPS. Aucun avertissement ne s'affichera, car celui-ci fait confiance à mkcert en tant qu'autorité de certification locale.
Guide de référence rapide sur mkcert
Pour exécuter votre site de développement local avec HTTPS:
-
Configurer mkcert.
Si vous ne l'avez pas encore fait, installez mkcert, par exemple sur macOS:
brew install mkcert
Cochez la case install mkcert pour obtenir des instructions Windows et Linux.
Ensuite, créez une autorité de certification locale:
mkcert -install
-
Créez un certificat de confiance.
mkcert {YOUR HOSTNAME e.g. localhost or mysite.example}
Cela crée un certificat valide que mkcert signe automatiquement.
-
Configurez votre serveur de développement pour qu'il utilise HTTPS et le certificat que vous avez créé à l'étape 2.
Vous pouvez désormais accéder à https://{YOUR HOSTNAME}
depuis votre navigateur, sans avertissement
</div>
Exécuter votre site en local avec HTTPS: autres options
Voici d'autres façons de configurer votre certificat. Ceux-ci sont généralement plus compliqués ou plus risqués que mkcert.
Certificat autosigné
Vous pouvez également décider de ne pas utiliser une autorité de certification locale telle que mkcert, mais de signer votre certificat vous-même. Cette approche présente quelques pièges:
- Les navigateurs ne vous considèrent pas comme une autorité de certification. Ils afficheront donc des avertissements que vous devez contourner manuellement. Dans Chrome, vous pouvez utiliser l'indicateur
#allow-insecure-localhost
pour ignorer automatiquement cet avertissement surlocalhost
. - Cette méthode n'est pas sécurisée si vous travaillez sur un réseau non sécurisé.
- Ce n'est pas nécessairement plus facile ni plus rapide que d'utiliser une autorité de certification locale comme mkcert.
- Les certificats autosignés ne se comportent pas exactement de la même manière que les certificats de confiance.
- Si vous n'utilisez pas cette technique dans un contexte de navigateur, vous devez désactiver la vérification des certificats pour votre serveur. Si vous oubliez de le réactiver en production, vous rencontrez des problèmes de sécurité.
![Des captures d'écran des avertissements dans les navigateurs s'affichent lorsqu'un certificat autosigné est utilisé.](https://web.dev/static/articles/how-to-use-local-https/image/screenshots-the-warnings-953f06ad1aebc.jpg?authuser=3&hl=fr)
Si vous ne spécifiez pas de certificat, les options HTTPS du serveur de développement de React et d'Vue créent un certificat autosigné. Cette opération est rapide, mais elle s'accompagne des mêmes avertissements du navigateur et autres pièges liés aux certificats autosignés. Heureusement, vous pouvez utiliser l'option HTTPS intégrée aux frameworks d'interface et spécifier un certificat de confiance locale créé à l'aide de mkcert ou d'un certificat similaire. Pour en savoir plus, consultez l'exemple mkcert avec React.
Si vous ouvrez le site exécuté localement dans votre navigateur à l'aide de HTTPS, votre navigateur vérifie le certificat de votre serveur de développement local. Lorsqu'il constate que vous avez signé le certificat vous-même, il vérifie si vous êtes enregistré en tant qu'autorité de certification de confiance. Puisque vous n'êtes pas un utilisateur, cela signifie que votre navigateur ne peut pas approuver le certificat, et qu'il affiche un avertissement vous indiquant que votre connexion n'est pas sécurisée. La connexion HTTPS sera quand même créée si vous continuez, mais à vos propres risques.
![Schéma expliquant pourquoi les navigateurs ne font pas confiance aux certificats autosignés](https://web.dev/static/articles/how-to-use-local-https/image/why-browsers-dont-trust-9aa014d2da64b.jpg?authuser=3&hl=fr)
Certificat signé par une autorité de certification standard
Vous pouvez également utiliser un certificat signé par une autorité de certification officielle. Cela s'accompagne des complications suivantes:
- Vous avez plus de travail de configuration à effectuer que lorsque vous utilisez une technique d'autorité de certification locale telle que mkcert.
- Vous devez utiliser un nom de domaine valide que vous contrôlez. Cela signifie que vous ne pouvez pas utiliser d'autorités de certification officielles pour les opérations suivantes :
localhost
et d'autres noms de domaine réservés tels queexample
outest
.- Tout nom de domaine que vous ne contrôlez pas.
- Domaines de premier niveau non valides. Pour en savoir plus, consultez la liste des domaines de premier niveau valides.
Proxy inverse
Une autre option pour accéder à un site s'exécutant localement avec HTTPS consiste à utiliser un proxy inverse tel que ngrok. Cela s'accompagne des risques suivants:
- Toute personne avec qui vous partagez l'URL du proxy inverse peut accéder à votre site de développement local. Cela peut être utile pour présenter votre projet aux clients, mais cela peut également permettre à des personnes non autorisées de partager des informations sensibles.
- Certains services de proxy inverse facturent l'utilisation. La tarification peut donc être un facteur dans votre choix de service.
- De nouvelles mesures de sécurité dans les navigateurs peuvent affecter le fonctionnement de ces outils.
Indicateur (non recommandé)
Si vous utilisez un nom d'hôte personnalisé tel que mysite.example
dans Chrome, vous pouvez utiliser une option pour forcer le navigateur à considérer mysite.example
comme sécurisé. Évitez d'effectuer cette opération pour les raisons suivantes:
- Vous devez être sûr à 100% que
mysite.example
génère toujours une adresse locale. Vous risqueriez de divulguer des identifiants de production. - Cet indicateur ne fonctionne que dans Chrome. Vous ne pouvez donc pas effectuer de débogage sur plusieurs navigateurs.
Nous vous remercions pour vos contributions et vos commentaires à tous les contributeurs et évaluateurs, en particulier Ryan Sleevi, Filippo Valsorda, Milica Mihajlija et Rowan Merewood. 🙌
Image d'arrière-plan de l'image principale par @anandu sur Unsplash, modifiée.