Jak naprawić Firefoksa 59, który nie akceptuje już mojego certyfikatu SSL na .dev virtualhost

20

W moim lokalnym środowisku Apache mam witrynę, która wymaga SSL do programowania, więc korzystam z certyfikatu z podpisem własnym. Witryna lokalna działała dobrze w Firefox i Chrome do tej pory, ale po zaktualizowaniu Firefoksa do wersji 59 dzisiaj nie mogę zmusić go do zaakceptowania wyjątku bezpieczeństwa (w Chrome samopodpisany certyfikat nadal działa).

Firefox podaje mi dodatkowe informacje na zablokowanej stronie:

... używa nieprawidłowego certyfikatu bezpieczeństwa. Certyfikat nie jest zaufany, ponieważ jest samopodpisany. Kod błędu: SEC_ERROR_UNKNOWN_ISSUER

Nie ma opcji, aby zezwolić na wyjątek tutaj, tak jak kiedyś, ale poszedłem do Preferencji Firefoksa w obszarze Certyfikaty, a następnie w zakładce „Serwer” dodałem wyjątek dla domeny lokalnej. Certyfikat jest następnie wymieniony w poprawnej nazwie lokalnego serwera, szczegóły pokazują moje ustawienia certyfikatu Wydane przez i Wydane są takie same, z prawidłowym okresem.

Ktoś ma podobne problemy z FF 59 lub może mieć wskazówkę, co zrobić, aby samopodpisany certyfikat znów działał lokalnie?

Edycja: Nie widzę żadnej wzmianki o tym w informacjach o wydaniu FF 59, ale coś w nowej wersji powoduje, że wszystkie moje lokalne wirtualne hosty w domenach * .dev automatycznie próbują ustanowić połączenie https (to znaczy wszystkie http żądania * .dev są automatycznie wysyłane na adres URL https). Być może coś w tym zachowaniu jest również przyczyną tych problemów dla moich rzeczywistych wirtualnych hostów https.

ssl ssl-certificate firefox

— kontur
źródło

1

Domyślam się, że potrzebujesz teraz urzędu certyfikacji dla certyfikatu z podpisem własnym, ponieważ Firefox stopniowo zaostrzał wymagania w ciągu ostatnich kilku wydań. Jednak dzięki Let's Encrypt nie ma powodu, aby używać certyfikatów z podpisem własnym.

— Simon Greenwood

Nie chcę zgadywać, ale myślę, że @ SimonGreenwood ma rację. Ale zwykle Firefox po prostu ustawia nowe opcje jako domyślne i umożliwia edycję ustawień. Sprawdź swoje ustawienia prywatności.

@Broco Jeśli coś jest w ustawieniach bezpieczeństwa, a nie w ustawieniach prywatności. Jak wspomniano powyżej, dodałem nawet wyjątek bezpieczeństwa, ale Firefox nadal nalega, aby nie móc zweryfikować certyfikatu, ponieważ oczywiście wystawca nie jest znany.

— kontur

@kontur dla mnie link dotyczy: preferencji # prywatność, aby ustawić zarówno ustawienia prywatności, jak i bezpieczeństwa, dlatego powiedziałem prywatność. Rozważ opublikowanie go jako błędu.

2

@SimonGreenwood Istnieje wiele powodów, aby nie używać szyfrowania w połączeniu lokalnym. Nie chciałoby się konfigurować enrpyt.

— Jon

15

Nadal nie jestem do końca jasne, jak to wszystko dokładnie do siebie pasuje, ale jak wskazano w tej odpowiedzi, .dev domeny są teraz oficjalnymi TLD. Wygląda na to, że przeglądarki wymuszają zachowanie HSTS i wymuszają połączenia https. W przypadku tych TLD wydaje się, że mój samopodpisany certyfikat nie został już zaakceptowany w przeglądarce Firefox. Zmiana wirtualnych hostów na używanie .testrozwiązała problem bez konieczności zmiany czegokolwiek w moich samopodpisanych certyfikatach.

Warto zauważyć, że w Firefoksie również moje wirtualne hosty bez SSL działały dzisiaj od wersji 59, ponieważ zachowanie HSTS wydawało się wymuszać SSL na wirtualnych hostach, których nie ustawiłem jako obsługujących za pośrednictwem SSL. W Chrome nadal to działało, ale w każdym razie można bezpiecznie powiedzieć, że odejście od oficjalnie używanej .devTLD rozwiąże wiele problemów.

— kontur
źródło

1

Tak, .devjest prawidłową TLD od pewnego czasu, więc NIE używaj jej do nazywania swoich wewnętrznych zasobów. To samo dotyczy innych nazw: nie używaj nazw, których według ciebie nikt nie użyje. Użyj nazw testowych wymienionych w RFC2606 lub po prostu zarejestruj prawdziwą nazwę domeny w dowolnym miejscu i użyj subdomeny, takiej jak int.example.comlub, dev.example.comaby dodać wszystkie nazwy wewnętrzne. Nigdy nie będziesz mieć kolizji ani problemów (o ile pamiętasz, aby co roku odnawiać nazwę domeny!)

— Patrick Mevzek

2

Zobacz ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts

— Patrick Mevzek

1

Dzięki za link. Wspomniane tam ramy czasowe nie do końca się pokrywają, ale być może autor mówił o zapowiedziach rozwoju itp. Biorąc pod uwagę to, co wiem teraz, naprawdę trudno zrozumieć, dlaczego dostawcy przeglądarek nie dodają dodatkowych informacji debugowania, w szczególności w odniesieniu do błędu SSL w .devdomenach. O ile nie wiesz, że to TLD, nie ma szans, abyś wywnioskował, że to jest problem.

— kontur

12

Jest na to łatwy sposób.

Iść do about:config
Wyszukaj „network.stricttransportsecurity.preloadlist”.
Ustaw na false.

OSTRZEŻENIE: Spowoduje to całkowite wyłączenie HSTS . Spójrz na komentarze do tej odpowiedzi, aby uzyskać dyskusję na temat wad tej metody. Osobiście uważam, że korzyść przewyższa ryzyko, ale jesteś odpowiedzialny za własne bezpieczeństwo.

— Andy Mercer
źródło

4

To bardzo zły pomysł, ponieważ to ustawienie będzie dotyczyć wszystkich odwiedzanych witryn, a nie tylko własnych. Obniżasz swoje bezpieczeństwo.

— Patrick Mevzek

Nie zgadzam się. HSTS jest stosunkowo nowy. Przez ostatnie 20 lat nic nam nie było, więc powiedzenie, że wyłączenie go jest bardzo złe dla bezpieczeństwa, jest przesadzone. Po drugie, nawet jeśli jest to zły pomysł, tak naprawdę nie ma innej opcji, jeśli chcę, aby moje serwery programistyczne nadal działały, co nie wymaga naprawdę długich zmian w moim środowisku programistycznym.

— Andy Mercer

1

Takie rozwiązanie: security.stackexchange.com/a/154176 przynajmniej wpływa tylko na jedną stronę, a nie na wszystkie.

— Patrick Mevzek

1

Jakkolwiek protekcjonalne, jak wiem, zabrzmi to z wiekiem, ale zdasz sobie sprawę, że rzeczy takie jak „najlepsza praktyka” i „zła” są elastyczne i zmieniają się z czasem. To, co ludzie obecnie uważają za „złe”, nie było uważane za złe przez wiele lat i może już nie być w przyszłości. Jeśli chodzi o tę konkretną dyskusję, będziemy musieli zgodzić się nie zgodzić.

— Andy Mercer

1

Dzięki za tę poprawkę, działa świetnie dla mnie w Firefox 59.0.1 (i Firefox Dev Edition 60). Nasze obecne .devprojekty zostaną ostatecznie przeniesione na inny przyrostek TLD, ale na razie nie pomaga to zatrzymać lokalnego rozwoju.

— Jake Bathman

5

Ustawianie security.enterprise_roots.enabledsię truena about:configstronie rozwiązać to dla mnie i pozwolił mój certyfikat z podpisem własnym do pracy w trakcie rozwoju.

Trwa dyskusja na temat zalet tego domyślnego włączenia:
Ustaw security.enterprise_roots.enabled na true .

Chociaż celem tej flagi jest umożliwienie Firefoxowi korzystania z magazynu głównego urzędu certyfikacji CA jako ważnego źródła dla urzędów certyfikacji, naprawiło to sytuację dla mojego własnego przypadku użycia, w którym mam samopodpisany certyfikat wielu domen, którego używam lokalnie do testowania (subjectAltName's) . Nawet po dodaniu certyfikatu do listy certyfikatów Firefoksa dopiero po jego włączeniu zezwoliłem na załadowanie strony lokalnej.

— Sean Aitken
źródło

Dzięki, działało!

— informatik01

0

Miał ten sam problem w przeglądarce internetowej bazyliszka . Próbowałem zmienić ustawienia sieciowego serwera proxy lub zmodyfikować flagi „network.stricttransportsecurity.preloadlist” lub „security.enterprise_roots.enabled” ... ale to nie rozwiązało problemu braku przycisku dodania certyfikatu dla zablokowanej strony internetowej. Tylko dzięki temu udało się:

Idź do about:support.
Kliknij Open Directoryprofil przeglądarki.
Zamknij przeglądarkę całkowicie.
Edytuj plik „ SiteSecurityServiceState.txt ” w powyższym katalogu.
Znajdź i usuń całą linię zawierającą zablokowaną stronę HSTS.
Zapisz plik i ponownie otwórz przeglądarkę w tej witrynie.

— Noam Manos
źródło

-3

Poszedłem do „Let's Encrypt”

https://letsencrypt.org/

Ważne tylko przez 3 miesiące, ale odświeżenie można zautomatyzować.

Jak widać w uwagach, istnieje pewien haczyk. Nasze domeny programistyczne i testowe nazywa się dev-www.example.com i test-www.example.com. Używamy certyfikatu wieloznacznego z produkcji.

— Gerard H. Pille
źródło

5

Czy szyfrowanie Let's nie polega na tym, że serwer i domena są publicznie dostępne? Szukam opcji użycia SSL na lokalnych wirtualnych hostach.

— kontur

Tak, to nie działa dla osób zajmujących się rozwojem lokalnym.

— Andy Mercer

pytanie dotyczy LOKALNEGO

@ Pieter to to samo co „rozwój lokalny”? Ponieważ to właśnie robimy.

— Gerard H. Pille,

1

@ GerardH.Pille Możesz wygenerować Let's encrypt certyfikaty tylko wtedy, gdy serwer jest dostępny z Internetu. W przypadku mojego rozwoju lokalnego tak nie jest, więc nie jest to wykonalne. Proszę doradzić, jeśli czegoś brakuje.

— kontur