So beheben Sie, dass Firefox 59 mein selbstsigniertes SSL-Zertifikat auf .dev virtualhost nicht mehr akzeptiert


10

In meiner lokalen Apache-Umgebung gibt es eine Site, für die SSL für die Entwicklung erforderlich ist. Daher habe ich ein selbst signiertes Zertifikat verwendet. Die lokale Site hat bisher in Firefox und Chrome einwandfrei funktioniert, aber nachdem ich Firefox auf Version 59 aktualisiert habe, kann ich die Sicherheitsausnahme nicht akzeptieren (in Chrome funktioniert das selbstsignierte Zertifikat weiterhin).

Firefox gibt mir diese zusätzlichen Informationen auf der gesperrten Seite:

... verwendet ein ungültiges Sicherheitszertifikat. Das Zertifikat wird nicht als vertrauenswürdig eingestuft, da es selbstsigniert ist. Fehlercode: SEC_ERROR_UNKNOWN_ISSUER

Es gibt keine Option, die Ausnahme hier zuzulassen, da es früher war, aber ich habe die Firefox-Einstellungen unter Zertifikate aufgerufen. Dann habe ich auf der Registerkarte "Server" eine Ausnahme für die lokale Domäne hinzugefügt. Das Zertifikat wird dann unter dem korrekten lokalen Servernamen aufgeführt. Die Details zeigen meine Zertifikatseinstellungen von Ausgestellt von und Ausgestellt als identisch mit einer gültigen Zeitspanne.

Wer hat ähnliche Probleme mit FF 59 oder hat vielleicht eine Ahnung, wie er das selbstsignierte Zertifikat vor Ort wieder funktionsfähig machen kann?


Edit: Ich sehe keine Erwähnung im Versionshinweise zu FF 59 etwas in der neuen Version bewirkt jedoch, dass alle meine lokalen virtuellen Hosts in * .dev-Domänen automatisch versuchen, eine https-Verbindung herzustellen (dh alle http-Anforderungen für * .dev werden automatisch an die https-URL gesendet). Vielleicht ist etwas über dieses Verhalten auch das, was diese Probleme für meine tatsächlichen virtuellen https-Hosts verursacht.


Ich vermute, dass Sie jetzt eine Zertifizierungsstelle für ein selbstsigniertes Zertifikat benötigen, da Firefox die Anforderungen in den letzten Versionen schrittweise verschärft hat. Mit Let's Encrypt gibt es jedoch keinen Grund mehr, selbstsignierte Zertifikate zu verwenden.
Simon Greenwood

Ich möchte nicht raten, aber ich denke, @SimonGreenwood ist richtig. Normalerweise setzt Firefox jedoch nur die neuen Optionen als Standard und ermöglicht Ihnen das Bearbeiten der Einstellungen. Überprüfen Sie Ihre Datenschutzeinstellungen.

@Broco Wenn es sich um Sicherheitseinstellungen handelt, nicht um Datenschutzeinstellungen. Wie bereits erwähnt, habe ich sogar eine Sicherheitsausnahme hinzugefügt. Firefox besteht jedoch weiterhin darauf, das Zertifikat nicht validieren zu können, da der Aussteller offensichtlich unbekannt ist.
kontur

@kontur für mich geht es bei dem link um: preferences # privacy, um sowohl die privacy- als auch die sicherheitseinstellungen festzulegen, deshalb habe ich gesagt, privacy. Betrachten Sie es als Fehler.

.dev ist eine (etwas) neue gTLD im Besitz von Google. Siehe meinen anderen Kommentar unten ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts
Patrick Mevzek

Antworten:


9

Ich bin immer noch nicht ganz klar, wie das alles genau zusammenpasst, aber wie gesagt in dieser Antwort .dev Domänen sind jetzt offizielle TLDs. Es scheint also so, als ob Browser ein HSTS-Verhalten und https-Verbindungen erzwingen. Bei diesen TLDs scheint es, dass mein selbstsigniertes Zertifikat nicht mehr in Firefox akzeptiert wurde. Ändern meiner virtuellen Hosts zur Verwendung .test Das Problem wurde gelöst, ohne dass ich meine selbstsignierten Zertifikate ändern musste.

Es ist erwähnenswert, dass in Firefox seit Version 59 auch meine nicht-SSL-virtuellen Hosts aktiv waren, da das HSTS-Verhalten SSL für virtuelle Hosts zu zwingen schien, die ich nicht als SSL-Server eingerichtet hatte. In Chrome funktionierte dies immer noch, aber in beiden Fällen kann man sicher sagen, dass man sich von dem jetzt offiziell verwendeten entfernt .dev TLD löst viele Kopfschmerzen.


1
Ja, .dev ist seit einiger Zeit eine gültige TLD NICHT benennen Sie Ihre internen Ressourcen. Gleiches gilt für jeden anderen Namen: Verwenden Sie keinen Namen, von dem Sie annehmen, dass er von keinem anderen verwendet wird. Verwenden Sie entweder Testnamen, auf die in RFC2606 verwiesen wird, oder registrieren Sie einfach irgendwo einen echten Domainnamen und verwenden Sie eine Subdomain wie int.example.com oder dev.example.com um alle Ihre internen Namen zu ergänzen. Sie haben dann niemals Kollisionen oder Probleme (solange Sie nicht daran denken, den Domainnamen jedes Jahr zu erneuern!)
Patrick Mevzek


1
Danke für den Link. Die dort genannten Zeitlinien stehen nicht ganz in einer Reihe, aber vielleicht hat der Autor über Entwicklungsvorschauen oder ähnliches gesprochen. Angesichts dessen, was ich jetzt weiß, ist es wirklich schwer zu verstehen, warum Browser-Anbieter keine zusätzlichen Debugging-Informationen hinzufügen würden, insbesondere im Hinblick auf SSL-Fehler .dev Domänen. Wenn Sie nicht wissen, dass es sich um eine TLD handelt, besteht keine Chance, dass Sie auf dieses Problem schließen.
kontur

9

Dies lässt sich leicht umgehen.

  1. Gehe zu about:config
  2. Suchen Sie nach "network.stricttransportsecurity.preloadlist".
  3. Stellen Sie es auf false.

WARNUNG: Dadurch wird HSTS vollständig deaktiviert . Sehen Sie sich die Kommentare zu dieser Antwort an, um etwas über die Nachteile dieser Methode zu erfahren. Ich persönlich denke, dass der Nutzen das Risiko überwiegt, aber Sie sind für Ihre eigene Sicherheit verantwortlich.

enter image description here


1
Dies ist eine sehr schlechte Idee, da diese Einstellung für alle Websites gilt, die Sie nicht nur für Ihre eigene besuchen. Sie senken Ihre Sicherheit.
Patrick Mevzek

Ich stimme dir nicht zu. HSTS ist relativ neu. Wir haben es in den letzten 20 Jahren gut gemacht, also zu sagen, dass das Deaktivieren für die Sicherheit sehr schlecht ist, ist übertrieben. Zweitens, selbst wenn es eine schlechte Idee ist, gibt es keine andere Möglichkeit, wenn meine Entwicklungsserver weiterarbeiten sollen, was keine wirklich langwierigen Änderungen an meiner Entwicklungsumgebung erfordert.
Andy Mercer

Aus denselben Gründen sollten wir also nichts verwenden, was in den letzten 20 Jahren erfunden wurde. Das ist nur ein Scheinargument. RFC auf HSTS ist vor 6 Jahren. Sie deaktivieren absichtlich Sicherheitsmaßnahmen, was niemals eine gute Idee ist. Der Fehler besteht darin, falsche Namen zu verwenden. Stattdessen sollten Sie Energie in die Lösung dieses Problems investieren, da es das wahre Problem ist. Andernfalls werden Sie erneut gebissen und durch die Deaktivierung der Sicherheitseinstellungen werden Sie für andere Angriffe geöffnet.
Patrick Mevzek

Erstens bedeutet nichts, was ich gesagt habe, dass wir die in den letzten 20 Jahren erfundenen Dinge nicht verwenden sollten. Zweite, .dev für eine lokale Umgebung ist kein "falscher Name". Es ist eine typische Praxis für eine lange Zeit. Erst vor kurzem .dev als TLD hinzugefügt. Ich werde mein Setup nicht ändern, weil ICANN sich für einen Geldgriff entschieden hat.
Andy Mercer

1
Vielen Dank für dieses Update. Funktioniert in Firefox 59.0.1 (und Firefox Dev Edition 60) hervorragend. Unser gegenwärtiger .dev Projekte werden schließlich in ein anderes TLD-Suffix verschoben, dies hilft jedoch vorerst nicht, die lokale Entwicklung zu stoppen.
Jake Bathman

-3

Ich ging für "Let's Encrypt"

https://letsencrypt.org/

Nur für 3 Monate gültig, die Aktualisierung kann jedoch automatisiert werden.

Wie Sie in den Ausführungen sehen können, gibt es einen Haken. Unsere Entwicklungs- und Testdomains heißen dev-www.example.com und test-www.example.com. Wir verwenden das Wildcard-Zertifikat aus der Produktion.


2
Lasst uns nicht verschlüsseln, wenn der Server und die Domäne öffentlich verfügbar sind? Ich suche nach Optionen für die Verwendung von SSL auf lokalen virtuellen Hosts.
kontur

Ja, das funktioniert nicht für Leute, die sich lokal entwickeln.
Andy Mercer

die frage bezieht sich auf LOKAL DEV
Pieter

@Pieter ist das dasselbe wie "lokale Entwicklung"? Denn das machen wir.
Gerard H. Pille

@ GerardH.Pille ja das ist es natürlich. Erzähl es bitte.
Pieter
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.