J'ai dû me frayer un chemin à travers les certificats auto-signés sous Windows en combinant des éléments provenant des réponses données et d'autres ressources. Voici mon propre guide (et je l'espère complet). J'espère que cela vous épargnera une partie de ma douloureuse courbe d'apprentissage. Il contient également des informations sur des sujets connexes qui apparaîtront tôt ou tard lorsque vous créerez vos propres certificats.
Créer un certificat auto-signé sur Windows 10 et inférieur
N'utilisez pas makecert.exe. Il a été abandonné par Microsoft.
La manière moderne utilise une commande Powershell.
Windows 10:
Ouvrez Powershell avec les privilèges d'administrateur:
New-SelfSignedCertificate -DnsName "*.dev.local", "dev.local", "localhost" -CertStoreLocation cert:\LocalMachine\My -FriendlyName "Dev Cert *.dev.local, dev.local, localhost" -NotAfter (Get-Date).AddYears(15)
Windows 8, Windows Server 2012 R2:
Dans Powershell sur ces systèmes, les paramètres -FriendlyName et -NotAfter n'existent pas. Supprimez-les simplement de la ligne de commande ci-dessus.
Ouvrez Powershell avec les privilèges d'administrateur:
New-SelfSignedCertificate -DnsName "*.dev.local", "dev.local", "localhost" -CertStoreLocation cert:\LocalMachine\My
Une alternative consiste à utiliser la méthode pour l'ancienne version de Windows ci-dessous, qui vous permet d'utiliser toutes les fonctionnalités de Win 10 pour la création de certificats ...
Anciennes versions de Windows:
Ma recommandation pour les anciennes versions de Windows est de créer le certificat sur une machine Win 10, de l'exporter vers un fichier .PFX à l'aide d'une instance mmc (voir «Faire confiance au certificat» ci-dessous) et de l'importer dans le magasin de certificats sur la machine cible avec le ancien système d'exploitation Windows. Pour importer le certificat, ne cliquez PAS dessus avec le bouton droit de la souris. Bien qu'il existe un élément «Importer un certificat» dans le menu contextuel, tous mes essais ont échoué pour l'utiliser sur Win Server 2008. À la place, ouvrez une autre instance mmc sur la machine cible, accédez à «Certificats (ordinateur local) / Personnel / Certificats» , faites un clic droit dans le volet central et sélectionnez Toutes les tâches → Importer.
Le certificat résultant
Les deux commandes ci-dessus créent un certificat pour les domaines localhost
et *.dev.local
.
La version Win10 a en outre une durée de vie de 15 ans et un nom d'affichage lisible de "Dev Cert * .dev.local, dev.local, localhost".
Mise à jour: Si vous fournissez plusieurs entrées de nom d'hôte dans le paramètre -DnsName
(comme indiqué ci-dessus), la première de ces entrées deviendra le sujet du domaine (AKA Common Name). La liste complète de toutes les entrées de nom d'hôte sera stockée dans le champ Autre nom du sujet (SAN) du certificat. (Merci à @BenSewards de l'avoir signalé.)
Après sa création, le certificat sera immédiatement disponible dans toutes les liaisons HTTPS d'IIS (instructions ci-dessous).
Faites confiance au certificat
Le nouveau certificat ne fait partie d'aucune chaîne de confiance et n'est donc pas considéré comme fiable par les navigateurs. Pour changer cela, nous copierons le certificat dans le magasin de certificats pour les autorités de certification racines de confiance sur votre ordinateur:
Ouvrez mmc.exe, Fichier → Ajouter / Supprimer un composant logiciel enfichable → choisissez «Certificats» dans la colonne de gauche → Ajouter → choisissez «Compte d'ordinateur» → Suivant → «Ordinateur local ...» → Terminer → OK
Dans la colonne de gauche, choisissez "Certificats (ordinateur local) / Personnel / Certificats".
Trouvez le certificat nouvellement créé (dans Win 10, la colonne «Nom convivial» peut vous aider).
Sélectionnez ce certificat et appuyez sur Ctrl-C pour le copier dans le presse-papiers.
Dans la colonne de gauche, choisissez «Certificats (ordinateur local) / Autorités de certification racines de confiance / Certificats».
Appuyez sur Ctrl-V pour coller votre certificat dans ce magasin.
Le certificat doit apparaître dans la liste des autorités racines de confiance et est désormais considéré comme fiable.
Utiliser dans IIS
Vous pouvez maintenant accéder au Gestionnaire IIS, sélectionner les liaisons d'un site Web local → Ajouter → https → entrer un nom d'hôte du formulaire myname.dev.local
(votre certificat n'est valide que pour *.dev.local
) et sélectionner le nouveau certificat → OK.
Ajouter aux hôtes
Ajoutez également votre nom d'hôte à C: \ Windows \ System32 \ drivers \ etc \ hosts:
127.0.0.1 myname.dev.local
Heureux
Maintenant, Chrome et IE doivent traiter le certificat comme digne de confiance et charger votre site Web lorsque vous ouvrez https://myname.dev.local
.
Firefox maintient son propre magasin de certificats. Pour ajouter votre certificat ici, vous devez ouvrir votre site Web dans FF et l'ajouter aux exceptions lorsque FF vous avertit du certificat.
Pour le navigateur Edge, d'autres actions peuvent être nécessaires (voir plus bas).
Testez le certificat
Pour tester vos certificats, Firefox est votre meilleur choix. (Croyez-moi, je suis moi-même fan de Chrome, mais FF est mieux dans ce cas.)
Voici les raisons:
- Firefox utilise son propre cache SSL, qui est purgé lors du rechargement par équipes. Ainsi, toute modification des certificats de vos sites Web locaux se reflétera immédiatement dans les avertissements de FF, tandis que d'autres navigateurs peuvent nécessiter un redémarrage ou une purge manuelle du cache SSL de Windows.
- FF vous donne également de précieux conseils pour vérifier la validité de votre certificat: Cliquez sur Avancé lorsque FF affiche son avertissement de certificat. FF vous montrera un court bloc de texte avec un ou plusieurs avertissements possibles dans les lignes centrales du bloc de texte:
Le certificat n'est pas approuvé car il est auto-signé.
Cet avertissement est correct! Comme indiqué ci-dessus, Firefox n'utilise pas le magasin de certificats Windows et ne fera confiance à ce certificat que si vous y ajoutez une exception. Le bouton pour cela se trouve juste en dessous des avertissements.
Le certificat n'est pas valide pour le nom ...
Cet avertissement montre que vous avez fait quelque chose de mal. Le domaine (générique) de votre certificat ne correspond pas au domaine de votre site Web. Le problème doit être résolu en modifiant le (sous-) domaine de votre site Web ou en émettant un nouveau certificat correspondant. En fait, vous pouvez ajouter une exception dans FF même si le certificat ne correspond pas, mais vous n'obtiendrez jamais un symbole de cadenas vert dans Chrome avec une telle combinaison.
Firefox peut afficher de nombreux autres avertissements de certificats intéressants et compréhensibles à cet endroit, comme des certificats expirés, des certificats avec des algorithmes de signature obsolètes, etc. Je n'ai trouvé aucun autre navigateur qui m'a donné ce niveau de rétroaction pour résoudre les problèmes.
Quel modèle de (sous-) domaine dois-je choisir de développer?
Dans la commande New-SelfSignedCertificate ci-dessus, nous avons utilisé le domaine générique *.dev.local
.
Vous pensez peut-être: pourquoi ne pas l'utiliser *.local
?
Raison simple: il est illégal en tant que domaine générique.
Les certificats génériques doivent contenir au moins un nom de domaine de deuxième niveau.
Ainsi, les domaines du formulaire *.local
sont agréables pour développer des sites Web HTTP. Mais pas tellement pour HTTPS, car vous seriez obligé d'émettre un nouveau certificat correspondant pour chaque nouveau projet que vous démarrez.
Remarques secondaires importantes:
- Les domaines hôtes valides peuvent UNIQUEMENT contenir des lettres a creux z, des chiffres, des traits d'union et des points. Aucun trait de soulignement autorisé! Certains navigateurs sont très pointilleux sur ce détail et peuvent vous donner du fil à retordre lorsqu'ils refusent obstinément de faire correspondre votre domaine
motör_head.dev.local
à votre modèle générique *.dev.local
. Ils se conformeront lorsque vous passerez à motoer-head.dev.local
.
- Un caractère générique dans un certificat ne correspondra qu'à UNE étiquette (= section entre deux points) dans un domaine, jamais plus.
*.dev.local
correspond myname.dev.local
mais PAS other.myname.dev.local
!
- Les caractères génériques à plusieurs niveaux (
*.*.dev.local
) ne sont PAS possibles dans les certificats. Donc, other.myname.dev.local
ne peut être couvert que par un caractère générique du formulaire *.myname.dev.local
. Par conséquent, il est préférable de ne pas utiliser une partie de domaine de quatrième niveau. Mettez toutes vos variations dans la partie du troisième niveau. De cette façon, vous vous entendrez avec un seul certificat pour tous vos sites de développement.
Le problème avec Edge
Il ne s'agit pas vraiment de certificats auto-signés, mais toujours lié à l'ensemble du processus:
après avoir suivi les étapes ci-dessus, Edge peut ne pas afficher de contenu lorsque vous ouvrez myname.dev.local
.
La raison est une caractéristique de la gestion du réseau de Windows 10 pour les applications modernes, appelée «isolation du réseau».
Pour résoudre ce problème, ouvrez une invite de commande avec des privilèges d'administrateur et entrez une fois la commande suivante:
CheckNetIsolation LoopbackExempt -a -n=Microsoft.MicrosoftEdge_8wekyb3d8bbwe
Vous trouverez plus d'informations sur l'isolement de périphérie et de réseau ici:
https://blogs.msdn.microsoft.com/msgulfcommunity/2015/07/01/how-to-debug-localhost-on-microsoft-edge/
makecert.exe
être sur mon chemin. Pour les certificats, je pensais que je serais plus sûr et utiliserais-a SHA512 -len 8192
- cela a pris une éternité à générer. Et comme je le soupçonnais, cela n'avait aucun impact sur le niveau de cryptage utilisé par IIS. Par défaut, IIS utilise 128 bits, vous devez effectuer des opérations de stratégie de groupe pour changer cela. À noter également pour les autres lecteurs: ne changez pas les nombres magiques après-eku
, ils sont obligatoires.