Ich versuche, die Authentifizierung von Client-Zertifikaten für meine asp.net-Website zu erstellen.
Um Client-Zertifikate erstellen zu können, muss ich zuerst eine Zertifizierungsstelle erstellen:
makecert.exe -r -n "CN = Meine persönliche Zertifizierungsstelle" -pe -sv MyPersonalCA.pvk -a sha1 -len 2048 -b 01/01/2013 -e 01/01/2023 -eine Behörde MeinPersonalCA.cer
Dann muss ich es nach IIS 7 importieren, aber da es das .pfx-Format akzeptiert, konvertiere ich es zuerst
pvk2pfx.exe -pvk MyPersonalCA.pvk -spc MyPersonalCA.cer -pfx MyPersonalCA.pfx
Nach dem Import von MyPersonalCA.pfx versuche ich, die https-Site-Bindung zu meiner Website hinzuzufügen und das oben genannte SSL-Zertifikat auszuwählen. Ich erhalte jedoch die folgende Fehlermeldung:
Irgendwelche Vorschläge?
Dies muss eine Art IIS Fehler sein, aber ich habe die Lösung gefunden.
1- Exportieren Sie MyPersonalCA.pfx aus IIS.
2- Konvertieren Sie es in .pem :
openssl pkcs12 -in MyPersonalCA.pfx -out MyPersonalCA.pem -nodes
3- Konvertieren Sie es zurück in .pfx :
openssl pkcs12 -export -in MyPersonalCA.pem -inkey MyPersonalCA.pem -out MyPersonalCA.pfx
4- Importiere es zurück nachISIS.
Ich bin über das gleiche Problem gestoßen, habe es aber anders gelöst. Ich glaube, das Konto, das ich verwendete, hat sich seit dem ersten Versuch, das Zertifikat einzurichten, bis zu dem Zeitpunkt geändert, zu dem ich zurückkehrte, um die Arbeit abzuschließen, wodurch das Problem erstellt wurde. Was das Problem ist, weiß ich nicht, aber ich vermute, es hat mit einer Art Hash des aktuellen Benutzers zu tun, und das ist in einigen Szenarien inkonsistent, da der Benutzer geändert oder neu erstellt wird usw.
Um dies zu beheben, habe ich sowohl IIS als auch das Zertifikat-Snap-In (für aktuellen Benutzer und lokalen Computer) alle Referenzen des fraglichen Zertifikats entfernt:
Als Nächstes importierte ich die * .pfx-Datei in das Certs-Snap-In in MMC und platzierte sie im Knoten Lokaler Computer\Personal:
Ab diesem Zeitpunkt konnte ich zu IIS zurückkehren und es in den Serverzertifikaten finden. Schließlich ging ich zu meiner Website, bearbeitete die Bindungen und wählte das richtige Zertifikat aus. Es hat funktioniert, weil der Benutzer während des gesamten Prozesses konsistent war.
Zu dem in einer anderen Antwort erwähnten Punkt sollte es nicht notwendig sein, es als exportierbar zu kennzeichnen, da dies ein größeres Sicherheitsproblem ist. Sie erlauben effektiv jedem, der mit ähnlichen Berechtigungen an die Box gelangt, Ihr Zertifikat mitzunehmen und es an einen anderen Ort zu importieren. Das ist natürlich nicht optimal.
Sicherheitswarnung: Das Kontrollkästchen bedeutet, dass das Zertifikat von Benutzern gelesen werden kann, die es nicht lesen können. Beispielsweise der Benutzer, der den Arbeitsprozess IIS ausführt. Verwenden Sie in der Produktion stattdessen die andere Antwort .
Dies ist auch bei mir der Fall und wurde behoben, indem beim Importieren sichergestellt wurde, dass "Dieses Zertifikat darf nicht exportiert werden" angehakt gesetzt werden:
(Danke an diesen Beitrag !)
Das interessiert wahrscheinlich niemanden mehr, aber ich bin gerade mit meiner IIS 7-Website-Bindung konfrontiert worden. Die Art und Weise, wie ich es behoben hatte, ging zur Zertifizierungsstelle und fand das Zertifikat, das dem Server mit dem Problem ausgestellt wurde. Ich habe das Benutzerkonto überprüft, das das Zertifikat angefordert hat. Ich habe mich dann mit diesem Konto unter Verwendung von RDP am IIS -Server angemeldet. Ich konnte das https-Protokoll nur mit diesem Konto erneut binden. Es waren keine Exporte, Neuausstellungen oder Erweiterungen zum Wechseln von Hacks erforderlich.
In unserem Fall trat dieses Problem auf, weil wir das Zertifikat in einer virtuellen Maschine installiert und ein Image davon zur weiteren Verwendung erstellt haben.
Beim Erstellen eines weiteren VM aus dem zuvor erstellten Image sendet das Zertifikat die Nachricht.
Um dies zu vermeiden, installieren Sie das Zertifikat auf jedem neu installierten VM.
Wir hatten das gleiche Problem, weil das Zertifikat nicht ordnungsgemäß in den Zertifikatsspeicher "Aktueller Benutzer" importiert wurde. Wenn Sie es aus dem Store des aktuellen Benutzers entfernen und in den Zertifikatspeicher für lokale Computer importieren, wurde das Problem behoben.
Ich hatte das gleiche Problem. Gelöst durch Entfernen des Zertifikats aus dem persönlichen Speicher (von jemandem eingelegt) und aus dem Webhosting. Alles erledigt durch den IIS Manager. Dann fügte ich wieder zum Webhosting-Store hinzu (alles geprüft) und ich kann HTTPS wieder verwenden.
Ich habe diesen Fehler aufgrund einer falschen openssl-Befehlszeile während des Exports des PKCS # 12-Zertifikats erhalten. -certfile key war falsch. Ich habe das Zertifikat erneut exportiert und es wurde erfolgreich importiert.
In meinem Fall lag dies daran, dass der Benutzer des World Wide Publishing Service keine Berechtigungen für das Zertifikat hatte. Greifen Sie nach der Installation des Zertifikats auf das Zertifikatsmodul in MMC zu und klicken Sie mit der rechten Maustaste auf das Zertifikat mit dem Problem. Wählen Sie "Private Keys verwalten ..." aus dem Menü "All Tasks" und fügen Sie den obigen Benutzer hinzu. Dies war in meinem Fall ein SYSTEM-Benutzer.
Laut dem MSDN-Blogpost kann dies passieren, wenn das aktuelle Benutzerkonto nicht über die Berechtigung verfügt, auf die private Schlüsseldatei zuzugreifen, die sich im Ordner " C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys ". Dies kann anscheinend behoben werden, indem Sie dem Benutzerkonto/der Benutzergruppe die Berechtigung "Vollzugriff " für den oben genannten Ordner erteilen.
Ich bin auf dasselbe Problem gestoßen und konnte es beheben, indem ich einfach die PFX-Datei mit dem folgenden Befehl erneut importierte: Erlaube den Export dieses Zertifikats Kontrollkästchen aktiviert .
Diese Methode stellt jedoch ein Sicherheitsrisiko dar, da jeder Benutzer, der Zugriff auf Ihren IIS Server hat, Ihr Zertifikat mit dem privaten Schlüssel exportieren kann.
In meinem Fall habe nur ich Zugriff auf meinen IIS Server - daher war es kein großes Risiko.
Es ist mir gelungen, dieses Problem zu beheben, indem die PFX-Datei des SSL-Zertifikats mit Windows Certificate Manager importiert wurde.
http://windows.Microsoft.com/de-de/windows-Vista/view-or-manage-ihr-zertifikate
Versuchen :
Ich hatte gerade diese Ausgabe heute und fühle mich gezwungen, meine Lösung in der Hoffnung zu veröffentlichen, dass Sie weniger Haare verlieren als ich gerade getan habe.
Nachdem wir die oben genannten Lösungen ausprobiert hatten, mussten wir das SSL-Zertifikat vom SSL-Anbieter erneut ausstellen (RapidSSL stellt als Reseller für GeoTrust aus).
Bei diesem Vorgang gab es keine Kosten, es dauerte nur fünf Minuten, bis die Bestätigungs-E-Mails (admin @) ankamen, und wir erhielten erneut Zugang.
Nachdem wir die Antwort erhalten hatten, verwendeten wir Serverzertifikate IIS>, um sie zu installieren. Das Snap-In MMC wurde nicht benötigt.
https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&id=SO5757
Wir haben ein Remote-Desktop-Fenster für den Server durchgehend geöffnet, um Probleme mit unterschiedlichen Anmeldekonten/Sitzungen usw. zu vermeiden. Ich glaube, es ist ein IIS Fehler, wie ein anderer Experte meint, da wir nur ein RDC-Konto haben. Das Ärgerlichste ist, dass das gleiche Zertifikat zwei Monate lang einwandfrei funktioniert hat, bevor es plötzlich "bricht".
Anstatt das cert von IIS zu importieren, tun Sie es von MMC . Dann gehen Sie zu IIS, um zu binden.
Beim Versuch, localhost pfx cert für meine Entwicklungsmaschine zu binden, habe ich diese Fehlermeldung erhalten. Bevor ich etwas davon ausprobierte, versuchte ich zuerst etwas Einfacheres.
Danach scheint alles zu funktionieren.
In meinem Fall habe ich kürzlich eine neuere Version eines Zertifikats (PFX für IIS) von StartSSL importiert und das Entfernen des alten Zertifikats vergessen, was irgendwie zu diesem Fehler geführt hat (jetzt zwei gleiche Sorten). Ich habe beide entfernt, den richtigen importiert und jetzt funktioniert es.