11
Webserver zertifikat in der Domäne wird in Browser Firefox und Chrome nicht akzeptiert
Hallo,
ich habe ein Problem mit Zertifikaten in meiner Domäne. Ich habe außerdem keine erfahrung mit zertifikaten.
Es ist eine Test-Umgebung aus 4 Windows Server 2016. Ein DC mit DNS UND CA. Ein Server, auf dem ein Webserver installiert werden soll und zwei normale Clients. Alle sind mitglied der lokalen Domäne.
Ich habe festegestellt, dass beim Domänenjoin das Root-zertifikat der CA automatisch in den Vertrauenswürdige Zertifizierungsstellenspeicher (local machine) installiert wurde. Ich habe dann in der CA das vorgefertigte Template für Webserver aktiviert und verfügbar gemacht. Auf dem Webserver habe ich dann ein Webserver Zertifikat angefordert(Common name=FQDN des webservers). Das wurde in den eigenen Speicher installiert und ist laut certlm.msc gültig.
Ich hab den Fingerprint von diesem Zertifikat genommen und das in der Installation von Windows Admin Center als Webserver zertifikat angegeben. Die website wird über denselben FQDN aufgerufen, auf den das zertifikat ausgestellt ist.
Leider sagt Firefox: SEC_ERROR_UNKNOWN_ISSUER . Die CRL(Certificate Revodcation List) ist in einem LDAP Pfad standardmäßig. ich habe nach Anleitung einen weiteren distribution point in der CA mithilfe von ADSI hinzugefügt. Der wird auch im Zertifikat mitgeliedert, aber es funktkioniert trotzdem nicht.
Was können wir machen, um das zu troubleshooten?
Danke
hmmToast
ich habe ein Problem mit Zertifikaten in meiner Domäne. Ich habe außerdem keine erfahrung mit zertifikaten.
Es ist eine Test-Umgebung aus 4 Windows Server 2016. Ein DC mit DNS UND CA. Ein Server, auf dem ein Webserver installiert werden soll und zwei normale Clients. Alle sind mitglied der lokalen Domäne.
Ich habe festegestellt, dass beim Domänenjoin das Root-zertifikat der CA automatisch in den Vertrauenswürdige Zertifizierungsstellenspeicher (local machine) installiert wurde. Ich habe dann in der CA das vorgefertigte Template für Webserver aktiviert und verfügbar gemacht. Auf dem Webserver habe ich dann ein Webserver Zertifikat angefordert(Common name=FQDN des webservers). Das wurde in den eigenen Speicher installiert und ist laut certlm.msc gültig.
Ich hab den Fingerprint von diesem Zertifikat genommen und das in der Installation von Windows Admin Center als Webserver zertifikat angegeben. Die website wird über denselben FQDN aufgerufen, auf den das zertifikat ausgestellt ist.
Leider sagt Firefox: SEC_ERROR_UNKNOWN_ISSUER . Die CRL(Certificate Revodcation List) ist in einem LDAP Pfad standardmäßig. ich habe nach Anleitung einen weiteren distribution point in der CA mithilfe von ADSI hinzugefügt. Der wird auch im Zertifikat mitgeliedert, aber es funktkioniert trotzdem nicht.
Was können wir machen, um das zu troubleshooten?
Danke
hmmToast
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 536280
Url: https://administrator.de/contentid/536280
Printed on: April 16, 2024 at 11:04 o'clock
11 Comments
Latest comment
Firefox hat einen eigenen Zertifikatsspeicher. Entweder eine neue Firefox-Version nehmen, die das Fallback auf den Windows-Zertifikatsspeicher beherrscht, einen Browser nehmen, der auf den Windows-Zertifikatsspeicher zugreifen kann oder das CA-Zertifikat in den Firefox-Zertifikatsspeicher laden.
Hmm, um das zu verifizieren habe ich den installierten Chrome 78 genommen. Dort kommt eine andere Fehlermeldung: NET::ERR_CERT_COMMON_NAME_INVALID
Aber es kommt trotzdem eine Fehlermeldung.
Der webserver heißt: WindowsAdminCenter.psstest.local
Die website wird bereitgestellt unter: https://windowsadmincenter.psstest.local
das Zertifikat Webserver ist asgestellt für CN=windowsadmincenter.psstest.local bzw. im Zertifikat steht das ohne "CN="
Aber es kommt trotzdem eine Fehlermeldung.
Der webserver heißt: WindowsAdminCenter.psstest.local
Die website wird bereitgestellt unter: https://windowsadmincenter.psstest.local
das Zertifikat Webserver ist asgestellt für CN=windowsadmincenter.psstest.local bzw. im Zertifikat steht das ohne "CN="
Moin,
das sind zwei unabhängige Probleme.
Gruß,
Dani
das sind zwei unabhängige Probleme.
NET::ERR_CERT_COMMON_NAME_INVALID
Aber es kommt trotzdem eine Fehlermeldung.
Fehler: "Alternativer Name für den Zertifikatsinhaber fehlt" oder "NET::ERR_CERT_COMMON_NAME_INVALID" oder "Dies ist keine sichere Verbindung"Aber es kommt trotzdem eine Fehlermeldung.
Gruß,
Dani
Du zeigst auch nur, wie das Zertifikat im Zertifikatespeicher des Servers liegt, aber hast du im IIS auch die Bindung angepasst? Wenn du mal genau hinschaust, siehst du, dass da drei Zertifikate drin liegen. Woher soll der Server jetzt wissen, was er nehmen soll? Hätte man auch erkennen können, wenn man sich das Zertifikat im Browser anzeigen lässt, dass der CN nicht passt.
Chrome unterstützt keinen Self Zertifikate. Nie. Auch nicht mit einer eigenen internen CA.
Für Firefox gibt es einen gpo über die admx templates, worüber du den internen Zertifikats Speicher aktivieren kannst
Für Firefox gibt es einen gpo über die admx templates, worüber du den internen Zertifikats Speicher aktivieren kannst
@wuebra: Stimmt doch gar nicht. Ich habe gerade eben auf einem Rechner, auf dem noch nie Chrome installiert war, die normale Endkundenversion von Google installiert und habe eine Seite aufgerufen, die TLS-verschlüsselt ist und ein Zertifikat einer internen Enterprise-CA nutzt. Keine Warnmeldung, kein Fehler, keine definierte Ausnahme, das Zertifikat ist gültig. Das notwendige Root-Zertifikat dieser CA verteilen wir per GPO an die Clients.
Wenn ich eine TLS-Seite mit einem Zertifikat unserer eigenen Enterprise-CA aufrufe, dann wird ein Fehler gemeldet, aber nur weil das Root-Zertifikat noch SHA1 ist. Im rein internen Betrieb kein Problem.
Wenn ich eine TLS-Seite mit einem Zertifikat unserer eigenen Enterprise-CA aufrufe, dann wird ein Fehler gemeldet, aber nur weil das Root-Zertifikat noch SHA1 ist. Im rein internen Betrieb kein Problem.
Zitat von @tikayevent:
@wuebra: Stimmt doch gar nicht. Ich habe gerade eben auf einem Rechner, auf dem noch nie Chrome installiert war, die normale Endkundenversion von Google installiert und habe eine Seite aufgerufen, die TLS-verschlüsselt ist und ein Zertifikat einer internen Enterprise-CA nutzt. Keine Warnmeldung, kein Fehler, keine definierte Ausnahme, das Zertifikat ist gültig. Das notwendige Root-Zertifikat dieser CA verteilen wir per GPO an die Clients.
@wuebra: Stimmt doch gar nicht. Ich habe gerade eben auf einem Rechner, auf dem noch nie Chrome installiert war, die normale Endkundenversion von Google installiert und habe eine Seite aufgerufen, die TLS-verschlüsselt ist und ein Zertifikat einer internen Enterprise-CA nutzt. Keine Warnmeldung, kein Fehler, keine definierte Ausnahme, das Zertifikat ist gültig. Das notwendige Root-Zertifikat dieser CA verteilen wir per GPO an die Clients.
Ok...wusste ich nicht bzw. Bei mir erscheint der Fehler bei Chrome trotz interner CA. Verteilung des Root CERT auch bei GPO.
Welche Chrome Version ist installiert?
Die aktuellste von gestern. Könnte die 79er sein.
Moin,
Gruß,
Dani
Ok...wusste ich nicht bzw. Bei mir erscheint der Fehler bei Chrome trotz interner CA. Verteilung des Root CERT auch bei GPO.
könnte sein, dass mein Kommentar auch bei dir zutrifft?! Welche Chrome Version ist installiert?
Aktuell noch 78.xGruß,
Dani
Hallo, danke.
Das hat bei mir das Problem in Chrome gelöst. In Firefox dementsprechend nicht. Dort müsste ich dann wie ich gelesen habe noch über die ADMX-Templates die Zertifikate verfügbar machen. Als nächstes muss ich mich dann um die SSL-Zertifikate für WinRM kümmern.
Was eigentlich total beknackt von Microsoft ist, die Tatsache, dass man den Edge auf Windows Server nicht verwenden kann. Und der IE ist für Windows Admin Center nicht supported... Dafür aber der Chrome, wobei der neue Edge natürlich auch auf Chromium basiert. Trotzdem bescheuert.
Das hat bei mir das Problem in Chrome gelöst. In Firefox dementsprechend nicht. Dort müsste ich dann wie ich gelesen habe noch über die ADMX-Templates die Zertifikate verfügbar machen. Als nächstes muss ich mich dann um die SSL-Zertifikate für WinRM kümmern.
Was eigentlich total beknackt von Microsoft ist, die Tatsache, dass man den Edge auf Windows Server nicht verwenden kann. Und der IE ist für Windows Admin Center nicht supported... Dafür aber der Chrome, wobei der neue Edge natürlich auch auf Chromium basiert. Trotzdem bescheuert.
Edge war und ist bis zum Schluss immer eine Spielumgebung gewesen und war nie für den Unternehmenseinsatz gedacht.