Warum vertraut Windows 2012 R2 meinem selbstsignierten Zertifikat nicht?

In einer Testumgebung werde ich derzeit daran gehindert, einige Dinge zu testen, die bald bereitgestellt werden müssen (eigentlich schon, aber Sie wissen, wie die Fristen verlaufen ...), weil Windows sich weigert, dem selbstsignierten Zertifikat zu vertrauen, das wir in unserem haben isolierte Testumgebung. Obwohl ich das Problem mit dem "echten" Zertifikat und einigen DNS-Tricks nur umgehen konnte, habe ich das Zertifikat aus Sicherheits- / Kompartimentierungsgründen nicht angegeben.

Ich versuche, eine Verbindung zu einem Linux-basierten E-Mail-Server namens Zimbra herzustellen. Es wird ein automatisch generiertes selbstsigniertes OpenSSL-Zertifikat verwendet. Während die Seiten, die Google aufgedeckt hat, speziell auf IIS-Websites mit selbstsignierten IIS-Zertifikaten verweisen, denke ich nicht, dass die Methode zur Erstellung tatsächlich von Bedeutung ist.

Gemäß den Anweisungen, die ich hier und hier gefunden habe , sollte dies eine einfache Angelegenheit sein, das Zertifikat im Trusted Root Certification Authority-Speicher des lokalen Computers zu installieren. Was ich getan habe, sowie das Zertifikat manuell zu kopieren und direkt über das MMC-Snap-In zu importieren. Abmeldungen und Neustarts ändern nichts.

Hier ist der Zertifikatfehler, den ich jedes Mal erhalte:

Und hier ist der Zertifizierungspfad (Spoiler: Es ist nur das Zertifikat selbst):

Schließlich ist hier das Zertifikat sicher im Zertifikatspeicher des lokalen Computers versteckt, genau wie die Anweisungen, die ich gefunden habe, besagen, dass sie sein sollten:

Diese Anweisungen beziehen sich speziell auf Vista (in der zweiten wird das Betriebssystem nicht erwähnt) und IIS, während ich Server 2012 R2 verwende, der eine Verbindung zu einem Linux-basierten Server herstellt. Es gibt einige Unterschiede im Importassistenten (z. B. hat meiner die Option, für den aktuellen Benutzer oder das lokale System zu importieren, obwohl ich beide ausprobiert habe). Vielleicht muss ich hier etwas anderes tun? Eine Einstellung, die ich nicht gefunden habe und die geändert werden muss, damit sie dem Zertifikat wirklich vertraut, dem ich bereits gesagt habe, dass sie vertrauen soll?

Wie kann Windows Server 2012 R2 einem selbstsignierten Zertifikat vertrauen?

Der Fehler, den Sie erhalten, besteht nicht darin, dass es sich nicht um ein vertrauenswürdiges Stammzertifikat handelt, sondern dass die Kette zu einem vertrauenswürdigen Zertifikat nicht überprüft werden kann. Wenn ein Teil der Kette gebrochen ist, nicht vertrauenswürdig ist oder fehlt, erhalten Sie einen solchen Fehler. Der Fehler, den ich mit einem nicht vertrauenswürdigen, selbstsignierten Stamm bekommeist dies: Dieses CA-Stammzertifikat ist nicht vertrauenswürdig. Installieren Sie dieses Zertifikat im Store Trusted Root Certification Authorities, um die Vertrauenswürdigkeit zu aktivieren. Für Sie heißt es jedoch, dass es nicht bis zu einem vertrauenswürdigen Stammzertifikat überprüft werden kann. Dies kann daran liegen, dass Sie openssl während des Selbstsignierungsprozesses angewiesen haben, das Zertifikat mit einem anderen Stamm zu signieren (nicht mit Selbstsignatur), oder dass es nicht als Stammzertifizierungsstelle festgelegt wurde. Wenn es das erste ist, müssen Sie stattdessen dem Stamm vertrauen, mit dem es signiert wurde. Wenn es das letztere ist, müssen einige Eigenschaften in openssl.conf festgelegt werden.

Nach allem, was ich herausfinden kann, müssen Sie zmaster als vertrauenswürdige Quellzertifizierungsstelle hinzufügen, da WS2k12 versucht, das Zertifikat anhand eines Hosts zu überprüfen, von dem es nichts weiß. Sie haben Recht damit, dass die Generierungsmethode nicht wichtig ist, aber eine überprüfbare Quelle. Dies hat den Effekt, dass WS2k12 einem Zertifikat nicht vertraut, nur weil es den Namen $ Random_issuing_authority hat. Es muss in der Lage sein, das Zertifikat zu überprüfen.

Ich hatte das gleiche Problem. Es stellte sich heraus, dass meine Lösung darin bestand, die von dovecot verwendeten .crt- und .key-Dateien für den Mailserver zu aktualisieren. Exim4 in der Mail hatte einen aktualisierten Zertifikat- / Schlüsselsatz, aber Dovecot zeigte immer noch auf den alten Zertifikat- / Schlüsselsatz.

Das alte Zertifikat / Schlüssel-Paar funktionierte in den meisten Situationen einwandfrei, jedoch weder mit Outlook.com noch mit MS Outlook 2013.

Aufgrund von Problemen mit Outlook.com habe ich kürzlich das exim4-Zertifikat aktualisiert. Jetzt verwendet dovecot [und der Webmail-Server] auch die neuen Zertifikats- (und Schlüssel-) Dateien. Der Mailserver selbst wurde kürzlich ebenfalls aktualisiert [von alten Debian-Squeeze-lts auf Wheezy]. Das alte Setup war mit dem alten Zertifikat- / Schlüsselsatz rundum in Ordnung, aber nach dem Upgrade musste ich zuvor den neuen Zertifikat- / Schlüsselsatz erstellen MS-Produkte funktionieren ordnungsgemäß mit dem Mailserver.

Ich denke, das Problem ist, wie Sie auf die Ressourcen zugegriffen haben. Für Ihr lokales Netzwerk verwenden Sie möglicherweise den Hostnamen anstelle des vollständigen Domänennamens. Ihr Zertifikat wird jedoch für den vollständigen Domainnamen ausgestellt.

Installieren Sie das Zertifikat für vertrauenswürdige Stammzertifizierungsstellen und vertrauenswürdige Herausgeber.