Ich habe einunternehmen.svIch habe eine Domäne und vor Kurzem ein RapidSSL-Wildcard-Zertifikat erworben. Ich habe es installiert und mit vielen Browsern (Firefox, Chromium, Chrome, IE) und SSL-Prüftools getestet. Es funktionierte auf allen einwandfrei, außer auf Google Chrome, und das weder unter Windows, Linux noch unter Android.
Jedes Mal, wenn ich über Google Chrome auf die Website zugreife, wird eine Warnung angezeigt, dass ich versucht habe, darauf zuzugreifenwww.firma.svoderwasauchimmer.company.svaber der Server identifiziert sich als **.company.sv*. Wenn ich trotz der Warnung fortfahre und auf das rote Schloss klicke, wird mir angezeigt, dass ich mit einem Server verbunden bin, der nur innerhalb meines Netzwerks gültig ist und nicht durch eine externe Zertifizierungsstelle validiert werden kann.
Ich habe den Support des Zertifikats-Wiederverkäufers kontaktiert, aber sie konnten mir keine klare Antwort auf das Problem geben. Ich habe mich gefragt, ob es etwas damit zu tun hat, dass TLD.sv. Ich habe auch den Chromium-Quellcode geprüft, aber es scheint irgendwie sinnlos, da das Zertifikat auf Chromium einwandfrei funktioniert.
Vielleicht ist es erwähnenswert, dass ich NGINX auf einem Ubuntu 12.04-Server verwende und dass ich ein kostenloses Einzeldomänenzertifikat von Comodo getestet habe, bevor ich das Wildcard-Zertifikat gekauft habe.
Antwort1
Es scheint, als hätten Sie vergessen, das Zwischenzertifikatspaket auf Ihrem Webserver zu installieren. Besuchen Sie die Website des Zertifikatsanbieters, um das Zwischenzertifikatspaket herunterzuladen.
Für nginx muss dies mit Ihrem Zertifikat verknüpft und in die ssl_certificateDirektive eingefügt werden, zum Beispiel:
# cat company.sv.crt ca_bundle.crt > company.sv.chained.crt
Und in Ihrer Nginx-Konfiguration:
ssl_certificate /etc/path/to/company.sv.chained.crt
Antwort2
Ich vermute, dass Sie den Site-Namen im Feld „Subject CN=“ haben. Er muss im Feld „Subject Alternate Name“ stehen, damit Chrome ihn akzeptiert. Wenn Sie das Zertifikat im Browser anzeigen oder mitopenssl x509 -in certificate-file -text
Sehen:
Diese grundlegenden Anforderungen schreiben vor, dass Zertifizierungsstellen in den von ihnen ausgegebenen SSL-Zertifikaten immer mindestens einen alternativen Antragstellernamen angeben müssen. Dies bedeutet, dass eine Anwendung heute nicht mehr sowohl den allgemeinen Namen als auch den alternativen Antragstellernamen prüfen muss, sondern nur den letzteren überprüfen muss.
Derzeit nehmen die meisten Zertifizierungsstellen den ersten DNS-Namen aus dem alternativen Antragstellernamen auch in das Feld „Allgemeiner Name“ auf. Dies geschieht jedoch in erster Linie aus Gründen der Aktualität und wird in nicht allzu ferner Zukunft nicht mehr so gemacht.
Zertifikate können die Domäne/IP, an die sie gebunden sind, auf zwei Arten ausdrücken: eine unstrukturierte und mehrdeutige (commonName) und eine wohldefinierte (subjectAltName). Wenn keine SubjectAltNames vorhanden sind, vergleicht Chrome derzeit die Domäne mit dem commonName, sofern vorhanden.
Dieser Vorschlag soll diesen Fallback-Pfad entfernen und tatsächlich einen SubjectAltName erfordern. Idealerweise würden wir dies für alle Zertifikate tun (öffentlich vertrauenswürdige und privat vertrauenswürdige), aber wenn Bedenken hinsichtlich des Kompatibilitätsrisikos bestehen, können wir es auf öffentlich vertrauenswürdige Zertifikate beschränken.