Safari nie może połączyć się z https

Safari nagle nie może połączyć się z żadną witryną HTTPS, ponieważ „nie może nawiązać bezpiecznego połączenia”.

To jest na koncie administratora, a nie na koncie zarządzanym.

Inne konto administratora może używać Safari z HTTPS, więc musi być coś specyficznego dla mojego konta, ale nie mam pojęcia co.

Google Chrome nie ma problemów z połączeniem się ze stronami HTTPS.

Rzeczy, których próbowałem:

• opróżniono pamięć podręczną Safari
• usunięto preferencje Safari
• zresetuj całkowicie Safari
• naprawiony pęku kluczy (nie znaleziono błędów)
• usunięty pęku kluczy (nie pomógł)
• naprawiono uprawnienia w Narzędziu dyskowym
• zrestartowano
• Miałem nadzieję, że to się nagle naprawi

Wszystkie wyniki google, które widziałem, sugerowały albo naprawę pęku kluczy (który próbowałem i który nie pomógł) lub miały zastosowanie tylko, jeśli w grę wchodziły „Kontrola rodzicielska”, co nie ma tutaj zastosowania.

Gdybym musiał zgadywać, pomyślałbym, że gdziekolwiek Safari szuka „certyfikatów” jest w jakiś sposób uszkodzony, ale mogę się mylić. Nie jestem nawet pewien, gdzie ich szukać - może ~/Library/?

Raport na forums.macrumors.com wydaje się być dość podobne do Ciebie. Dzieje się tak również w Safari 5.1 i jest nowością.

Rozwiązaniem było usunięcie:

~/Library/Preferences/com.apple.security.plist

To po prostu znów wyrzuciło brzydką głowę, tym razem z Yosemite. Wpłynęło to również na wszystkie przeglądarki, których zwykle używam (Firefox, Chrome, Chrome Canary).

Próbowałem postępować zgodnie ze wskazówkami tutaj, które dotyczyły uzyskiwania informacji o certyfikacie głównym używanym przez naruszającą witrynę za pośrednictwem przeglądarki internetowej: Jak to naprawić: Safari nie może otworzyć strony, ponieważ Safari nie może nawiązać bezpiecznego połączenia

Nie kocham się tutaj, ponieważ każda przeglądarka odmawia wynegocjowania połączenia na tyle daleko, aby uzyskać nazwę wystawcy certyfikatu. Próbowałem nawet użyć open_ssl w wierszu poleceń, ale również nie powiodło się:

    [foo@bar]$ echo ^d | openssl s_client -connect broken.web.com:443 | tee cert.log
6480:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/SourceCache/OpenSSL098/OpenSSL098-52.40.1/src/ssl/s23_lib.c:185:
CONNECTED(00000003)

Wreszcie udało mi się otworzyć witrynę na starym komputerze z programem Internet Explorer w wersji 9 i znalazłem nazwę urzędu certyfikacji: Urząd certyfikacji Comodo.

W linkowanym artykule wskazano, co należy zrobić, ale oto, co zadziałało dla mnie:

• Otwórz aplikację Dostęp do pęku kluczy.
• Wybierz brelok „System Roots”.
• Wyszukaj wydający urząd certyfikacji (w tym przypadku Comodo).
• Wyświetl szczegóły certyfikatu (kliknij dwukrotnie, rozwiń obszar „Zaufanie” w oknie widoku).
• W moim przypadku reguła zaufania brzmiała: „Podczas korzystania z tego certyfikatu”.
• Zmieniłem go na „Zawsze ufaj”, zamknąłem dostęp do pęku kluczy (po wprowadzeniu hasła administratora) i załadowałem stronę.
• Nie chcąc pozostawiać go w mniej bezpiecznym trybie, ponownie użyłem Keychain Access i przestawiłem z powrotem na „Use System Defaults”.
• Problem rozwiązany, brak rozluźnienia parametrów bezpieczeństwa.

YMMV, ale jest mniej drastyczny niż eliminowanie wszystkich poprawek poprzez eliminację preferencji bezpieczeństwa, eliminowanie wszystkich danych Safari, a nawet ponowną instalację całego systemu operacyjnego, jak sugerują niektóre łącza próbujące rozwiązać ten problem.

Aktualizacja: musiałem ponownie uruchomić Chrome / Firefox, aby zaakceptować „zaktualizowane” / zresetować preferencje certyfikatu.

Kolejny możliwy powód: Prokurent lub MITM

Niedawno było ich sporo, a niektóre awarie niektórych aplikacji do łączenia się z serwerami za pośrednictwem sieci.

• Objaw: czasami laptop lub iPhone nie może nawiązać połączenia. Powyższa metoda nie działa.
• Test: Uruchom iPhone'a lub laptopa za pomocą połączenia komórkowego lub mobilnego hotspotu zamiast podejrzanego WiFi lub sieci przewodowej.
• Wynik: jeśli połączenie komórkowe działa, a połączenie niekomórkowe - podejrzewa atak typu man-in-the-middle (MITM) lub korporacyjny serwer proxy, który wygląda jak jeden.

Dla mnie to było popieprzone HSTS.plist. Usunięcie tego pliku rozwiązało problem dla wielu domen:

rm Library/Cookies/HSTS.plist

Następnie wyloguj się i zaloguj ponownie (samo ponowne uruchomienie Safari nie wykona zadania).

Informacje o HSTS: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

Usunięcie pliku ~ / Library / Cookies / HSTS.plist i ponowne uruchomienie przeglądarki działało dla mnie.

Prawidłowe sprawdzenie i zmiana ustawień zaufania certyfikatu w Safari działało dla mnie dobrze.

Miałem ten problem „nie mogę nawiązać bezpiecznego połączenia” z połączeniami HTTPS z Safari, kiedy aktualizowałem samopodpisany certyfikat na NAS.

NAS wymusza połączenia HTTPS z wyboru.

Połączyłem się już przez LAN z NAS i napotkałem certyfikaty i powiedziałem Safari, żeby „zaufało”.

Problem przy próbie połączenia za pomocą wyszukiwania DDNS na serwerze NAS.

Sprawdzanie ustawień zaufania certyfikatów wykazało, że certyfikaty były zaufane tylko w przypadku adresu IP sieci LAN. Łatwo zmieniane.

Miałem podobny problem i stwierdziłem, że data na moim komputerze była nieprawidłowa, dlatego wszystkie certyfikaty witryny bezpieczeństwa wygasły. Po prostu poprawiłem datę wstecz i działałem bezbłędnie. Utrzymane powiedzenie nie może nawiązać bezpiecznego połączenia (ponieważ znacznik bezpieczeństwa był nieaktualny na stronie ...) To wpłynie również na wszystkie aplikacje, które używają godziny / daty, takie jak aplikacje e-mail itp.

Problem: Safari nie może uzyskać bezpiecznego połączenia. Rozwiązane: Po przejrzeniu innych blogów, ostatecznie rozwiązane przez usunięcie pęku kluczy zaloguj hasło.