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

10191
kontur

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 gut 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 dies früher der Fall war. Ich ging jedoch zu den Firefox-Einstellungen unter Zertifikate. 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 das selbstsignierte Zertifikat wieder lokal arbeiten kann?

Edit: Ich sehe in den Versionshinweisen zu FF 59 keine Erwähnung , aber etwas in der neuen Version führt dazu, dass alle meine lokalen virtuellen Hosts in * .dev-Domänen automatisch versuchen, eine https-Verbindung herzustellen (dh alle http Anfragen 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.

10
Meine Vermutung ist, 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 vor 6 Jahren 0
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. vor 6 Jahren 0
@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 vor 6 Jahren 0
@kontur für mich geht es bei dem Link um: preferences # privacy, um sowohl die Privatsphäre als auch die Sicherheitseinstellungen festzulegen, deshalb habe ich gesagt, Privacy. Betrachten Sie es als Fehler. vor 6 Jahren 0
`.dev` ist eine (etwas) neue gTLD im Besitz von Google. Sehen Sie meinen anderen Kommentar unten und https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/ Patrick Mevzek vor 6 Jahren 0

3 Antworten auf die Frage

9
kontur

Ich bin immer noch nicht ganz klar, wie das alles genau zusammenpasst, aber wie in dieser Antwort .dev dargelegt, sind Domänen nun offizielle TLDs. Es scheint also so, als ob Browser ein HSTS-Verhalten erzwingen und https-Verbindungen erzwingen. Für diese TLDs scheint es, dass mein selbstsigniertes Zertifikat nicht mehr in Firefox akzeptiert wurde. Durch das Ändern meiner virtuellen Hosts zur Verwendung wurde .testdas Problem gelöst, ohne irgendetwas in meinen selbstsignierten Zertifikaten ändern zu müssen.

Es ist erwähnenswert, dass in Firefox seit der Version 59 heute 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 ist es sicher zu sagen, dass die Abkehr von der nun offiziell verwendeten .devTLD viele Kopfschmerzen bereitet.

Ja, `.dev` ist seit einiger Zeit eine gültige TLD. Verwenden Sie ** NOT ** nicht, um Ihre internen Ressourcen zu benennen. 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 Domain-Namen und verwenden Sie eine Subdomain wie "int.example.com" oder "dev.example.com", um alle Ihre internen Namen anzufügen. Sie haben dann nie Kollisionen oder Probleme (solange Sie daran denken, den Domainnamen jedes Jahr zu erneuern!) Patrick Mevzek vor 6 Jahren 1
Siehe https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/ Patrick Mevzek vor 6 Jahren 2
Danke für den Link. Die dort genannten Zeitlinien stehen nicht ganz in einer Reihe, aber vielleicht sprach der Autor über Entwicklungsvorschauen oder ähnliches. 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 den SSL-Fehler in `.dev`-Domains. Wenn Sie nicht wissen, dass es sich um eine TLD handelt, besteht keine Chance, dass Sie auf dieses Problem schließen. kontur vor 6 Jahren 1
8
Andy Mercer

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 diskutieren. Ich persönlich denke, dass der Nutzen das Risiko überwiegt, aber Sie sind für Ihre eigene Sicherheit verantwortlich.

enter image description here

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 vor 6 Jahren 1
Ich stimme dir nicht zu. HSTS ist relativ neu. Wir haben es in den letzten 20 Jahren gut gemacht, und 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 vor 6 Jahren 0
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 nie 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 anderen Angriffen ausgesetzt. Patrick Mevzek vor 6 Jahren 0
Erstens bedeutet nichts, was ich gesagt habe, dass wir die in den letzten 20 Jahren erfundenen Dinge nicht verwenden sollten. Zweitens ist ".dev" für eine lokale Umgebung kein "falscher Name". Es ist eine typische Praxis für eine lange Zeit. Erst kürzlich wurde `.dev` als TLD hinzugefügt. Ich werde mein Setup nicht ändern, weil ICANN sich für einen Geldgriff entschieden hat. Andy Mercer vor 6 Jahren 0
Eine Lösung wie diese: https://security.stackexchange.com/a/154176 betrifft mindestens eine Site, nicht alle. Patrick Mevzek vor 6 Jahren 0
`.dev` ist ein falscher Name, das ist nicht zu debattieren, nur eine Tatsache. Sie sollten nicht nur einen Namen erfinden und hoffen, dass es keine Kollision gibt. Sie werden passieren. So schlechte Wahl von Anfang an, sorry. Eine typische Auswahl macht es standardmäßig nicht gut. Und wenn Sie dagegen sind, dann pflegen Sie einfach einen lokalen autorisierenden Server für `.dev`. Was wiederum eine falsche Lösung ist, aber ich werde aufhören zu streiten, da es nicht fruchtbar ist, da Sie das Kernproblem, das Sie haben, nicht verstehen. Patrick Mevzek vor 6 Jahren 0
"Wir haben es in den letzten 20 Jahren gut geschafft", da HSTS HTTPS standardmäßig aktiviert, um sich vor Downgrades und Cookie-Hijacking zu schützen, Sie sagen nur, dass es Ihnen ohne HTTPS und somit TLS seit den letzten 20 Jahren gut geht. Ich habe Angst, das von einem Entwickler zu hören. Sowieso... Patrick Mevzek vor 6 Jahren 0
So herablassend, wie ich weiß, klingt dies mit zunehmendem Alter, und Sie werden feststellen, dass Dinge wie "Best Practice" und "False" flexibel sind und sich im Laufe der Zeit ändern. Was die Leute derzeit als "falsch" betrachten, wurde über viele Jahre nicht für falsch gehalten und ist möglicherweise in Zukunft nicht mehr der Fall. In Bezug auf diese spezielle Diskussion müssen wir uns nur damit einverstanden erklären. Andy Mercer vor 6 Jahren 0
Eine Kollision ist eine Kollision ist eine Kollision. Gestern, heute und morgen. Wenn Sie nicht verstehen, dass das DNS global ist, sollten Sie nicht einfach einen Namen hijacken, von dem Sie glauben, dass er von keinem anderen verwendet wird. Eine interessante Abkürzung, die vielleicht am Anfang anfängt, schneller zu denken, aber Sie beißt zu einem späteren Zeitpunkt, wie Sie gerade erfahren haben. So herablassend es auch sein mag: Versuchen Sie beim nächsten Mal in Ihrer beruflichen Karriere, explizite Kollisionen zu vermeiden. Es ist gut für Sie und für das Internet weltweit. Patrick Mevzek vor 6 Jahren 0
Ich denke, @AndyMercer ist .dev für die lokale Entwicklung nicht allein. Ich habe gerade mein FF auf Version 58 zurückgesetzt, weil ich mich jetzt einfach nicht darum kümmern kann, alle meine lokalen Dev-Sites zu ändern. George vor 6 Jahren 0
@Pieter die Tatsache, dass eine bestimmte Anzahl von Leuten einen Fehler macht, konvertiert sie nicht automatisch in eine gute Praxis ... `.dev` existiert seit vielen Jahren, irgendwann sollten die Leute anfangen zu bemerken: Es geht nur um die Änderungen auf HSTS, dass die Menschen beeinflusst wurden. Es ist bedauerlich, dass solch eine schlechte Entscheidung tatsächlich getroffen wurde. Das zeigt auch, dass alle Beispiele in Zeile und Beitrag hier darauf achten sollten, dass die in RFC2606 referenzierten Namen verwendet werden, da diese in Zukunft garantiert keine Kollisionen erzeugen. ** Jeder andere Name kann in der Zukunft kollidieren. ICANN wird neue gTLDs öffnen. Patrick Mevzek vor 6 Jahren 0
@PatrickMevzek> Alle hier aufgeführten Beispiele und Beiträge sollten sicherstellen, dass die in RFC2606 referenzierten Namen verwendet werden, da diese in Zukunft garantiert keine Kollisionen verursachen. Das lässt nicht viel Spielraum mit .test, .example, .invalid und .localhost. Ich denke, wir müssen kreativer werden und so etwas wie .localdev machen, was ** vielleicht von ICANN geöffnet wird, aber hoffentlich wird das in ferner Zukunft sein :) George vor 6 Jahren 0
@Pieter Bitte lesen Sie meinen Kommentar oben: Registrieren Sie einen beliebigen Domain-Namen in einer beliebigen TLD, die Sie wünschen, und Sie haben dann für die gesamte Dauer (oder für die Dauer, die Sie dafür bezahlen) eine Möglichkeit, jede Art von interner Benennung vorzunehmen, die Sie wünschen, weil Sie ** ** Sichern Sie sich einen Namen, indem Sie ihn global registrieren, anstatt ihn willkürlich auszuwählen und zu hoffen, dass niemand anderes dasselbe tun wird. Die Namen im RFC werden von ICANN niemals geöffnet. Patrick Mevzek vor 6 Jahren 0
Vielen Dank für dieses Update. Funktioniert in Firefox 59.0.1 (und Firefox Dev Edition 60) hervorragend. Unsere aktuellen ".dev" -Projekte werden schließlich in ein anderes TLD-Suffix verschoben, aber dies hilft vorerst nicht, die lokale Entwicklung zu stoppen. Jake Bathman vor 6 Jahren 1
Danke für die Antwort. Es könnte funktionieren, aber die negativen Auswirkungen dieser Lösung scheinen das Positive aufzuwiegen. kontur vor 6 Jahren 0
Keine Möglichkeit darüber. Es funktioniert. In Bezug auf die Sicherheitsbedenken hängt es von Ihrem Arbeitsablauf und Ihrer Situation ab. Deshalb sage ich, diese Kommentare durchzulesen. Andy Mercer vor 6 Jahren 0
-2
Gerard H. Pille

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.

Lassen Sie sich nicht verschlüsseln, wenn der Server und die Domäne öffentlich verfügbar sind? Ich suche nach Optionen zur Verwendung von SSL auf lokalen virtuellen Hosts. kontur vor 6 Jahren 2
Ja, das funktioniert nicht für Leute, die sich lokal entwickeln. Andy Mercer vor 6 Jahren 0
die frage ist über LOKAL DEV George vor 6 Jahren 0
@Pieter ist das dasselbe wie "lokale Entwicklung"? Denn das machen wir. Gerard H. Pille vor 6 Jahren 0
@ GerardH.Pille ja das ist es natürlich. Erzähl es bitte. George vor 6 Jahren 0
@ GerardH.Pille Sie können Zertifikate nur dann verschlüsseln, wenn der Server über das Internet erreichbar ist. Für meine lokale Entwicklung ist dies nicht der Fall, daher ist dies nicht machbar. Bitte informieren Sie mich, wenn etwas fehlt. kontur vor 6 Jahren 0
Das vielleicht? https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html Verwenden Sie Ihre Produktions-URL mit einem Präfix wie "test-", "dev-". Gerard H. Pille vor 6 Jahren 0

Verwandte Probleme