Ich musste mich durch selbstsignierte Zertifikate unter Windows rätseln, indem ich Teile der gegebenen Antworten und weitere Ressourcen kombinierte. Hier ist mein eigener (und hoffentlich vollständiger) Durchgang. Ich hoffe, es erspart Ihnen einige meiner schmerzhaften Lernkurven. Es enthält auch Infos zu verwandten Themen, die früher oder später angezeigt werden, wenn Sie Ihre eigenen Zertifikate erstellen.
Erstellen Sie ein selbstsigniertes Zertifikat unter Windows 10 und niedriger
Verwenden Sie nicht makecert.exe. Es wurde von Microsoft veraltet.
Der moderne Weg verwendet einen Powershell-Befehl.
Windows 10:
Öffnen Sie Powershell mit Administratorrechten:
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:
In Powershell auf diesen Systemen sind die Parameter -FriendlyName und -NotAfter nicht vorhanden. Entfernen Sie sie einfach aus der obigen Befehlszeile.
Öffnen Sie Powershell mit Administratorrechten:
New-SelfSignedCertificate -DnsName "*.dev.local", "dev.local", "localhost" -CertStoreLocation cert:\LocalMachine\My
Eine Alternative ist die Verwendung der folgenden Methode für ältere Windows-Versionen, mit der Sie alle Funktionen von Win 10 für die Zertifikaterstellung verwenden können ...
Ältere Windows-Versionen:
Meine Empfehlung für ältere Windows-Versionen lautet, das Zertifikat auf einem Win 10-Computer zu erstellen, es mit einer mmc-Instanz in eine .PFX-Datei zu exportieren (siehe "Vertrauen Sie dem Zertifikat" weiter unten) und es mit dem in den Zertifikatspeicher auf dem Zielcomputer zu importieren altes Windows-Betriebssystem. Um das Zertifikat zu importieren, klicken Sie NICHT mit der rechten Maustaste darauf. Obwohl das Kontextmenü das Element "Zertifikat importieren" enthält, konnten alle meine Versuche unter Win Server 2008 nicht verwendet werden. Öffnen Sie stattdessen eine andere mmc-Instanz auf dem Zielcomputer und navigieren Sie zu "Zertifikate (lokaler Computer) / Persönlich / Zertifikate". Klicken Sie mit der rechten Maustaste in den mittleren Bereich und wählen Sie Alle Aufgaben → Importieren.
Das resultierende Zertifikat
Beide oben genannten Befehle erstellen ein Zertifikat für die Domänen localhost
und *.dev.local
.
Die Win10-Version hat zusätzlich eine Live-Zeit von 15 Jahren und den lesbaren Anzeigenamen "Dev Cert * .dev.local, dev.local, localhost".
Update: Wenn Sie im Parameter -DnsName
(wie oben gezeigt) mehrere Hostnameneinträge angeben, wird der erste dieser Einträge zum Betreff der Domäne (AKA Common Name). Die vollständige Liste aller Hostnameneinträge wird im Feld Subject Alternative Name (SAN) des Zertifikats gespeichert. (Vielen Dank an @BenSewards für den Hinweis.)
Nach der Erstellung ist das Zertifikat sofort in allen HTTPS-Bindungen von IIS verfügbar (Anweisungen unten).
Vertrauen Sie dem Zertifikat
Das neue Zertifikat ist nicht Teil einer Vertrauenskette und wird daher von keinem Browser als vertrauenswürdig angesehen. Um dies zu ändern, kopieren wir das Zertifikat in den Zertifikatspeicher für vertrauenswürdige Stammzertifizierungsstellen auf Ihrem Computer:
Öffnen Sie mmc.exe, Datei → Snap-In hinzufügen / entfernen → wählen Sie "Zertifikate" in der linken Spalte → Hinzufügen → wählen Sie "Computerkonto" → Weiter → "Lokaler Computer ..." → Fertig stellen → OK
Wählen Sie in der linken Spalte "Zertifikate (lokaler Computer) / Persönlich / Zertifikate".
Suchen Sie das neu erstellte Zertifikat (in Win 10 kann die Spalte "Anzeigename" hilfreich sein).
Wählen Sie dieses Zertifikat aus und drücken Sie Strg-C, um es in die Zwischenablage zu kopieren.
Wählen Sie in der linken Spalte "Zertifikate (lokaler Computer) / Vertrauenswürdige Stammzertifizierungsstellen / Zertifikate".
Drücken Sie Strg-V, um Ihr Zertifikat in diesen Speicher einzufügen.
Das Zertifikat sollte in der Liste der vertrauenswürdigen Stammautoritäten angezeigt werden und gilt jetzt als vertrauenswürdig.
Verwendung in IIS
Jetzt können Sie zum IIS-Manager gehen, die Bindungen einer lokalen Website auswählen → Hinzufügen → https → einen Hostnamen des Formulars myname.dev.local
eingeben (Ihr Zertifikat ist nur gültig für *.dev.local
) und das neue Zertifikat auswählen → OK.
Zu Hosts hinzufügen
Fügen Sie außerdem Ihren Hostnamen zu C: \ Windows \ System32 \ drivers \ etc \ hosts hinzu:
127.0.0.1 myname.dev.local
glücklich
Jetzt sollten Chrome und IE das Zertifikat als vertrauenswürdig behandeln und Ihre Website beim Öffnen laden https://myname.dev.local
.
Firefox unterhält einen eigenen Zertifikatspeicher. Um Ihr Zertifikat hier hinzuzufügen, müssen Sie Ihre Website in FF öffnen und zu den Ausnahmen hinzufügen, wenn FF Sie vor dem Zertifikat warnt.
Für den Edge-Browser sind möglicherweise weitere Aktionen erforderlich (siehe weiter unten).
Testen Sie das Zertifikat
Um Ihre Zertifikate zu testen, ist Firefox die beste Wahl. (Glaub mir, ich bin selbst ein Chrome-Fan-Boy, aber FF ist in diesem Fall besser.)
Hier sind die Gründe:
- Firefox verwendet einen eigenen SSL-Cache, der beim erneuten Laden der Schicht gelöscht wird. Änderungen an den Zertifikaten Ihrer lokalen Websites werden daher sofort in den Warnungen von FF angezeigt, während andere Browser möglicherweise einen Neustart oder eine manuelle Bereinigung des Windows-SSL-Cache benötigen.
- Außerdem gibt FF Ihnen einige wertvolle Hinweise, um die Gültigkeit Ihres Zertifikats zu überprüfen: Klicken Sie auf Erweitert, wenn FF die Zertifikatwarnung anzeigt. FF zeigt Ihnen einen kurzen Textblock mit einer oder mehreren möglichen Warnungen in den mittleren Zeilen des Textblocks:
Das Zertifikat ist nicht vertrauenswürdig, da es selbst signiert ist.
Diese Warnung ist richtig! Wie oben erwähnt, verwendet Firefox den Windows-Zertifikatspeicher nicht und vertraut diesem Zertifikat nur, wenn Sie eine Ausnahme hinzufügen. Die Schaltfläche dazu befindet sich direkt unter den Warnungen.
Das Zertifikat ist für den Namen nicht gültig ...
Diese Warnung zeigt, dass Sie etwas falsch gemacht haben. Die (Platzhalter-) Domain Ihres Zertifikats stimmt nicht mit der Domain Ihrer Website überein. Das Problem muss gelöst werden, indem entweder die (Unter-) Domain Ihrer Website geändert wird oder indem ein neues Zertifikat ausgestellt wird, das übereinstimmt. Tatsächlich könnten Sie in FF eine Ausnahme hinzufügen, auch wenn das Zertifikat nicht übereinstimmt, aber mit einer solchen Kombination würden Sie in Chrome niemals ein grünes Vorhängeschlosssymbol erhalten.
Firefox kann an dieser Stelle viele andere nette und verständliche Warnungen zu Zertifikaten anzeigen, wie abgelaufene Zertifikate, Zertifikate mit veralteten Signaturalgorithmen usw. Ich habe keinen anderen Browser gefunden, der mir dieses Feedback gegeben hat, um Probleme zu beheben.
Welches (Sub-) Domain-Muster soll ich entwickeln?
Im obigen Befehl New-SelfSignedCertificate haben wir die Platzhalterdomäne verwendet *.dev.local
.
Sie denken vielleicht: Warum nicht verwenden *.local
?
Einfacher Grund: Es ist als Wildcard-Domain illegal.
Platzhalterzertifikate müssen mindestens einen Domainnamen der zweiten Ebene enthalten.
Domains des Formulars *.local
sind also gut geeignet, um HTTP-Websites zu entwickeln. Aber nicht so sehr für HTTPS, da Sie gezwungen wären, für jedes neue Projekt, das Sie starten, ein neues Matching-Zertifikat auszustellen.
Wichtige Randnotizen:
- Gültige Hostdomänen dürfen NUR Buchstaben durch z, Ziffern, Bindestriche und Punkte enthalten. Keine Unterstriche erlaubt! Einige Browser sind sehr wählerisch in Bezug auf dieses Detail und können es Ihnen schwer machen, wenn sie sich hartnäckig weigern, Ihre Domain
motör_head.dev.local
mit Ihrem Platzhaltermuster abzugleichen *.dev.local
. Sie werden eingehalten, wenn Sie zu wechseln motoer-head.dev.local
.
- Ein Platzhalter in einem Zertifikat stimmt nur mit EINEM Label (= Abschnitt zwischen zwei Punkten) in einer Domain überein, niemals mehr.
*.dev.local
Streichhölzer myname.dev.local
aber NICHTother.myname.dev.local
!
- Mehrstufige Platzhalter (
*.*.dev.local
) sind in Zertifikaten NICHT möglich. So other.myname.dev.local
kann nur durch eine Wildcard der Form abgedeckt werden *.myname.dev.local
. Daher ist es am besten, keinen Domain-Teil der vierten Ebene zu verwenden. Fügen Sie alle Ihre Variationen in den Teil der dritten Ebene ein. Auf diese Weise erhalten Sie ein einziges Zertifikat für alle Ihre Entwicklungsseiten.
Das Problem mit Edge
Hier geht es nicht wirklich um selbstsignierte Zertifikate, sondern um den gesamten Prozess:
Nachdem Sie die obigen Schritte ausgeführt haben, zeigt Edge beim Öffnen möglicherweise keinen Inhalt an myname.dev.local
.
Der Grund ist ein charakteristisches Merkmal der Netzwerkverwaltung von Windows 10 für moderne Apps, das als "Netzwerkisolation" bezeichnet wird.
Um dieses Problem zu lösen, öffnen Sie eine Eingabeaufforderung mit Administratorrechten und geben Sie den folgenden Befehl einmal ein:
CheckNetIsolation LoopbackExempt -a -n=Microsoft.MicrosoftEdge_8wekyb3d8bbwe
Weitere Informationen zur Edge- und Netzwerkisolation finden Sie hier:
https://blogs.msdn.microsoft.com/msgulfcommunity/2015/07/01/how-to-debug-localhost-on-microsoft-edge/
makecert.exe
, um in meinem Pfad zu sein. Für die Zertifikate dachte ich, ich wäre sicherer und benutzerfreundlicher-a SHA512 -len 8192
- die Generierung hat ewig gedauert. Und wie ich vermutet hatte, hatte dies keine Auswirkungen auf die von IIS verwendete Verschlüsselungsstufe. Standardmäßig verwendet IIS 128-Bit. Um dies zu ändern , müssen Sie Gruppenrichtlinien ausführen . Ein weiterer Hinweis für andere Leser: Ändern Sie die magischen Zahlen danach nicht mehr-eku
, sie sind erforderlich.