Safari не может подключиться к https

Safari неожиданно не может подключиться ни к одному HTTPS-сайту, потому что он «не может установить безопасное соединение».

Это на учетной записи администратора, а не управляемой учетной записи.

Другая учетная запись администратора может использовать Safari с HTTPS, поэтому для моей учетной записи должно быть что-то конкретное, но я понятия не имею, что.

У Google Chrome нет проблем с подключением к HTTPS-сайтам.

Вещи, которые я пробовал:

• очистил кеш Safari
• удаленные настройки Safari
• Сбросить Safari полностью
• отремонтированный брелок (ошибок не найдено)
• удалил брелок (не помогло)
• восстановленные разрешения в Дисковой утилите
• перезагружена
• надеялся, что это вдруг исправится

Все результаты поиска в Google, которые я видел, предлагали либо восстановить брелок (который я пробовал, но не помог), либо были применимы только в том случае, если был задействован «Родительский контроль», что здесь не применимо.

Если бы мне пришлось угадывать, я бы подумал, что везде, где Safari проверяет «сертификаты», что-то искажается, но я могу ошибаться. Я даже не уверен, где их искать - может быть ~/Library/?

Отчет о forums.macrumors.com , кажется, очень похож на ваш. Это происходит также в Safari 5.1 и совсем недавно.

Решение было удалить:

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

Это снова подняло свою уродливую голову, на этот раз с Йосемити. Это также затронуло все браузеры, которые я обычно использую (Firefox, Chrome, Chrome Canary).

Я попытался последовать этому совету, который включал получение информации о корневом сертификате, используемом веб-сайтом-нарушителем, через веб-браузер: Как исправить: Safari не может открыть страницу, потому что Safari не может установить безопасное соединение

Я не чувствую здесь никакой любви, так как каждый браузер отказывается устанавливать соединение достаточно далеко, чтобы узнать имя издателя сертификата. Я даже пытался использовать open_ssl в командной строке, но также это не удалось:

    [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)

Наконец, я смог открыть веб-сайт на старой машине с Internet Explorer версии 9 и нашел название центра сертификации: Comodo Certification Authority.

Связанная статья намекала на то, что нужно делать, но вот что сработало для меня:

• Откройте приложение Keychain Access.
• Выберите брелок «Корни системы».
• Поиск выдающего центра сертификации (в данном случае Comodo).
• Просмотр сведений о сертификате (двойной щелчок, разверните область «Доверие» окна просмотра).
• В моем случае правилом доверия было: «При использовании этого сертификата».
• Я изменил его на «Всегда доверять», закрыл Keychain Access (после ввода пароля администратора) и загрузил страницу.
• Не желая оставлять его в менее безопасном режиме, я снова использовал Keychain Access и снова переключил его на «Использовать системные настройки по умолчанию».
• Проблема решена, нет ослабления параметров безопасности.

YMMV, но это менее радикально, чем обнуление всех ваших настроек путем устранения настроек безопасности, обнуления всех ваших данных Safari или даже переустановки всей вашей ОС, как предлагают некоторые ссылки, пытающиеся решить эту проблему.

Обновление: мне пришлось перезапустить Chrome / Firefox, чтобы они приняли «обновленный» / сброс настроек сертификата.

Другая возможная причина: корпоративный прокси или MITM

Совсем недавно их было много, а также некоторые приложения не могли подключиться к своим серверам через сеть.

• Симптом: ноутбук или iPhone иногда не могут защитить соединение. Вышеуказанный метод не работает.
• Тест: Запустите iPhone или ноутбук, используя сотовую связь или мобильную точку доступа вместо предполагаемой WiFi или проводной сети.
• Результат: если сотовая связь работает, а не сотовая - нет, то можно заподозрить атаку «человек посередине» (MITM) или корпоративный прокси, похожий на него.

Для меня это было испорчено HSTS.plist. Удаление этого файла решило эту проблему для меня для нескольких доменов:

rm Library/Cookies/HSTS.plist

Затем выйдите из системы и войдите снова (перезапуск Safari не поможет).

О HSTS: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

Удалите файл ~ / Library / Cookies / HSTS.plist и перезапустите мой браузер.

Просмотр и изменение настроек доверия сертификатов в Safari мне помогли.

У меня возникла проблема «не могу установить безопасное соединение» с HTTPS-соединениями из Safari, когда я обновлял самозаверяющий сертификат на NAS.

NAS принудительно устанавливает HTTPS-соединения.

Я уже подключился через LAN к NAS, встретил сертификаты и сказал Safari «доверять».

Попытка подключиться через NAS DDNS поиска дала проблему.

Проверка параметров доверия сертификатов показала, что сертификаты являются доверенными только для IP-адреса локальной сети. Легко меняется.

У меня была похожая проблема, и я обнаружил, что дата на моем компьютере была неправильной, и, таким образом, все сертификаты веб-сайтов безопасности истекли. Я просто скорректировал дату назад и работал без нареканий. Говорят, что установить безопасное соединение невозможно (поскольку тег безопасности был устаревшим на веб-сайте ...). Это также повлияет на все приложения, использующие время и дату, такие как приложения электронной почты и т. Д.

Проблема: Safari не может получить безопасное соединение. Решено: Пройдя по другим блогам, окончательно решил, удалив логин брелка в пароле.