Для начала напомню всем (и не только “айтишникам”) про прекрасную презентацию Бориса – “Траблшутинг для пользы и удовольствия”

А теперь минутка траблшутинга!
Ну а если вы не траблшутер и попали сюда, чтобы устранить внезапно возникшие проблемы с Safari в некоторых версиях OS X, то все что вам нужно – вот эта картинка:

Откройте программу Связка ключей (В папке Программы/Утилиты), зайдите в Настройки, вкладка Сертификаты, отключите проверки, как показано на картинке.
Для очистки совести перезагрузите Мак.

Ну а сисадмины и ботаники могут читать дальше.

1
“У меня стоит работа, я не могу открыть Facebook” (тикет #65710, жалоба редактора отдела глянцевого журнала)
“Почему-то не получается зайти в Basecamp” (тикет #65718, жалоба менеджера по продажам дизайн-агентства)
“Помогите, Интернет мееееедлеееееенныыыыый!” (тикет #65724, жалоба архитектора)
“Парни, а ведь я не могу дать распоряжение оплатить ваш счет” (тикет #65727, босс пост-продакшена)

Что должен сделать сотрудник поддержки, принявший заявку? Провести очень быстрый сбор информации. Чем меньше времени, чем больше информации – тем лучше! Он либо сам поймет, где зарыта собака, либо передаст кубометры земли с собакой дальше по конвейеру.
Какие же вопросы пролетают как молнии в голове сотрудника Helpdesk?

Какие еще сайты не открываются?
А какие открываются?
А что происходит под другим пользователем?
А в другом браузере?
А как там curl?

Только после этого нужно приступать к стандартным процедурам вроде отключения расширений браузера, удаления кэша и настроек и так далее.
И уж тем более нет никакого смысла сразу лезть в настройки DNS или перезагружать маршрутизатор клиента.

2
Итак, в Firefox все работает.
И с помощью curl веб-страничка скачивается (фанаты могут попробовать lynx или links).
Хм, Chrome работает. Погодите, как Chrome работает??? Ведь Chrome это тоже WebKit-based браузер?
Загадочно…

Под другим пользователем проблема та же самая, значит сбрасывать, удалять ничего не нужно.
Что говорят коллеги по отделу? Проблема наблюдается в 10.7, 10.8, 10.9…
В 10.10 и выше ее нет.
И Safari последняя версия и все обновления установлены? И началось не после установки обновлений. Вот же чертовщина!

Так, а что же объединяет те сайты, которые не открываются?
Посмотрим-ка на них.
Ага, похоже это https сайты!
Нет, в Safari не открываются и некоторые “обычные” сайты.

Ну-с, что нам показывает Inspector в Safari (например, разделы Сеть и Ресурсы)?
Ага, все-таки похоже, что проблема с https сайтами или с сайтами, часть контента которых получается по https.

Ага, мы помним эту мистическую проблему прошлого года, когда старые версии OS X не могли связаться с рядом сервисов Google Apps (ныне G Suite). Например, через веб-интерфейс не скачивались вложения из Gmail или не работал чат Hangouts.
Так, секундочку, ведь тогда проблема была только у некоторых пользователей (то есть зависела от сетей, от магистральных провайдеров), мы ее связали с глюком кэш серверов Google у крупных провайдеров (и никогда не узнали правду, так как утром следующего дня проблема исчезла). Но запомним-ка про разные сети.

Да, но почему работает curl?
Так, а если вот так:
openssl s_client -connect bo.vtb24.ru:443

Оккультизм! Все работает! Получаем сертификат, открываем соединение.
То есть системные компоненты работают нормально, а Safari нет…
Может Safari использует другие библиотеки? Эх, матчасть надо учить!

Так, а почему в Safari не все https сайты не открываются (то есть какие-то https сайты открываются)?
О, в чате Helpdesk парни говорят, что сайты все-таки могут открыться если браузер оставить на несколько минут. Таймауты, таймауты…

Ого! Кто-то говорит, что у него в компании все работает. Так, что там было выше про разные сети?

3
“Когда сомневаешься, запускай сниффер!” (Анаксагор, “How to hack the network”, Cisco Press).

Так, запускаем tcpdump, заходим на facebook в Safari.

DNS запросы, DNS ответы…
Не относящаяся к делу ерунда (bonjour, bonjour, еще bonjour)…

А это что такое?
Невообразимое количество запросов к “93.184.220.29.http”.
380 записей?!

Что это за 93.184.220.29?

Так, whois 93.184.220.29 говорит, что это некий edgecast.com.
Online video & content delivery…

Так, а посмотрим-ка еще в выводе tcpdump про этот IP адрес.
Ага, вот же в самом начале наш Мак узнает, что ocsp.digicert.com это 93.184.220.29

ocsp.digicert.com. CNAME cs9.wac.phicdn.net.
cs9.wac.phicdn.net. A 93.184.220.29

Стало быть, при попытке с Мака обратиться к сайту по https, он пытается подключиться к серверу ocsp.digicert.com.

Ну, а ocsp это уже знакомая аббревиатура! Это же из Support Essentials, курс, по которому у нас сдает экзамен каждый hеlpdesk :-)

Online Certificate Status Protocol – протокол проверки статуса SSL сертификатов

Он дает возможность CA отзывать выданные сертификаты, но клиент тоже должен пользоваться этим протоколом.
Ага, видимо, более свежие версии OS X просто не долбят в лоб, как наша подопытная 10.9.5 и у них проблемы нет или она не так явна.

Гугление, еще гугление. Вот, например хорошая статья Yosemite and OCSPD / CRL Security Revocation
А вот, оказывается, почему работает Chrome! “Google отключил проверку отозванных цифровых сертификатов, ссылаясь на борьбу с задержками”.

4
Воркэраунд/Workaround
Кажется решение найдено!

Идем в Keychain Access и отключаем проверку отозванных сертификатов (Связка ключей – Настройки – Сертификаты)

Но ведь боязно! Но ведь Google (не использует)! Да, но ведь сама Apple (недаром включила в систему)!

Может нам пожаловаться в Apple?
Ха-ха-ха, ответ известен заранее “Please, use the latest & greatest” (По-русски – “Все на Sierra, верной дорогой к коммунизму!”)

И все-таки на обед идти нельзя, ведь это не решение, а воркэраунд!

5
Почему в ряде сетей все работает?

Ого! Из некоторых сетей ocsp.digicert.com разрешается в 72.21.91.29. Понятно, у разных провайдеров и разных регионов мы будем получать разные IP адреса для ocsp.digicert.com. Что ж, логично!

Ого! Из некоторых сетей прекрасно доступен и наш родной 93.184.220.29! Вот они файерволы, брандмауэры, межсетевые экраны…
Минутка паранойи в корпоративном чате (когда дело касается SSL, градус паранойи сразу вырастает; можно было бы подумать, что это проделки СОРМ-125, но тогда бы не работал и openssl s_client -connect и т.д..)

Не ленимся, пишем письмо в поддержку digicert. Похоже это в консерватории что-то не так с роутингом или брандмауэрами. Пишем подробнейшим образом, IP адреса, ссылки на жалобы в сети, “не будет ли так любезен многоуважаемый джин”.
Вот когда они исправят ситуацию, это будет настоящее решение!
Ого, ответ приходит очень быстро! Ребята молодцы. Отправим-ка им заодно скриншот их сайта, который не загружается должным образом из-за недоступности content.digicert.com

UPDATE 1
В настоящий момент находимся в переписке с поддержкой Digicert, а она, в свою очередь, в переписке с поддержкой CDN.

UPDATE 2
Паранойя паранойей, но проблема с недоступностью 93.184.220.29 все-таки оказалась не в админах digicert.com или edgecast.com.

IP адрес 93.184.220.29 заблокирован по решению Роскомнадзора, он есть в Реестре запрещенных сайтов

Странно, что внесен в реестр этот IP был в 2013 году, а “все сломалось” только сейчас.
Возможно на этом IP в edgecast.com когда-то хостился запрещенный ресурс, а недавно поменялся IP адрес сервера digicert?
Почитаем решение суда, узнаем, как удалять адреса из реестра, и напишем обновление в Digicert и в Роскомнадзор.

UPDATE 3
4.10.2016 первым делом написали письмо в Роскомнадзор, будем ждать ответа.
Отправили информацию в поддержку Digicert. Может быть им проще будет поменять IP адрес этого сервера или временно отправлять нас на другой сервер.

А решение Ставропольского суда, похоже, знатное. По номеру этого решения находятся старые статьи про блокировку таких популярных сайтов, как GitHub.
Стыдно, конечно, что такая версия блокировки не была проверена, ведь когда все свелось к одному IP, добрый traceroute из нескольких точек навел бы на такие подозрения. Но сбивало с толку то, что некоторые пользователи из России уверяли, что у них нет никаких проблем. А еще больше – жалобы на эту проблему на Apple Discussions и в Facebook, казалось, что это глобальная проблема, затронувшая ряд крупных сетей (сейчас выяснилось, что, несмотря на английский язык, все эти посты были написаны из России). К тому же, это не веб-сайт с какой-то информацией, кто бы мог подумать …

UPDATE 4
Роскомнадзор нам пока не ответил, а из Digicert сегодня написали, попросили собрать для них еще кое-какую диагностическую информацию.

Большое спасибо Денису Барковскому, ap, клиентам и знакомым, кто пожаловался на проблему и мужественным сотрудникам поддержки Шорткат.