Сведения об отзыве сертификата безопасности для этого сайта недоступны excel

Обновлено: 23.01.2025

Сертификаты

Я написал несколько инструкций по этому процессу, в том числе с чего начать, как грамотно обновить и как использовать двойные сертификаты. Это всё здорово, не правда ли? Но в чём проблема? А проблема возникнет тогда, когда всё пойдёт не по плану и у вас случится плохой день.

Нас хакнули

Если злоумышленник завладел нашим секретным ключом, то он может выдать себя за нас. Повторим это: кто-то в интернете может доказать, что он — это вы, хотя в реальности он таковым не является. Это реальная проблема, и прежде чем вы подумаете «Со мной такого никогда не произойдёт», вспомните Heartbleed. Этот крошечный баг в библиотеке OpenSSL позволял злоумышленнику украсть ваш секретный ключ, даже если вы соблюдали все меры безопасности. Кроме этого, было бесчисленное множество случаев, когда секретные ключи утекали из-за случайности или небрежности. Реальность такова, что мы можем потерять наш секретный ключ, а когда это случается, нам требуется способ помешать злоумышленнику использовать наш сертификат. Нужно его отозвать.

Отзыв

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

Как только мы узнаём о факте взлома, мы связываемся с CA и просим отозвать наш сертификат. Нужно доказать факт владения сертификатом, и как только мы сделали это, то CA помечает сертификат как отозванный. Теперь нужен способ сообщить об этом факте каждому клиенту, которому может потребоваться данная информация. Прямо в этот момент браузер, конечно, ничего не знает, и это проблема. Есть два механизма, которые используются для распространения информации: это список отозванных сертификатов (Certificate Revocation List, CRL) и протокол проверки статуса сертификата (Online Certificate Status Protocol, OCSP).

Списки отозванных сертификатов

Проблема CRL в том, что списки содержат много сертификатов от конкретных центров сертификации. Не вдаваясь в излишние детали, они разбиваются на промежуточные сертификаты CA, а центр сертификации может выдавать списки меньшими частями, но проблема остаётся той же. У списка CRL немалый размер. Другая проблема в том, что у клиента нет свежей копии CRL, ему нужно запросить её при первоначальном подключении к сайту, что может сделать всю процедуру заметно медленнее. Всё это выглядит не очень приятно, так что посмотрим на OCSP.

Протокол проверки статуса сертификата

OCSP предлагает намного более красивое решение проблемы и имеет значительное преимущество перед CRL. Здесь мы спрашиваем у CA статус единственного, конкретного сертификата. Это значит, что CA должен вернуть только простой ответ: сертификат либо хороший, либо отозван, и такой ответ гораздо меньше по размеру, чем список CRL. Отлично!

Полный сбой

Выше я говорил о CRL и OCSP, двух механизмах проверки сертификатов браузером, и они выглядят таким образом.

После получения сертификата браузер обратится к одному из этих сервисов и отправит запрос для окончательного выяснения статуса сертификата. А что, если у вашего CA плохой день и его инфраструктура в офлайне? Что, если ситуация выглядит так?

Здесь у браузера только два варианта. Он может отказаться принимать сертификат, поскольку не способен проверить его статус. Или взять на себя риск и принять сертификат, не зная его статус, отозван он или нет. У обоих вариантов есть свои преимущества и недостатки. Если браузер откажется принимать сертификат, то каждый раз при уходе инфраструктуры CA в офлайн ваши сайты тоже уходят туда же. Если браузер продолжит принимать сертификаты, то он рискует принять сертификат, который был украден, и подвергает пользователя риску. Это трудный выбор, но прямо сейчас, сегодня, ничего такого на самом деле не происходит…

Частичный сбой

На самом деле сегодня браузеры выполняют так называемую проверку отзыва сертификата с частичным сбоем. То есть браузер попытается проверить статус сертификата, но если ответ не пришёл совсем или не пришёл за короткий промежуток времени, то браузер просто забывает об этом. Ещё хуже, что Chrome даже не пытается проверить сертификат. Да, вы прочитали правильно, Chrome даже не пытается проверить статус сертификата, который ему поступает. Вы можете найти это странным, но я полностью согласен с их подходом и я рад сообщить, что Firefox тоже, вероятно, скоро начнёт работать так же. Позвольте объяснить. Проблема с полным сбоем очевидна: если у CA плохой день, то у нас тоже он будет, вот так мы пришли к логике частичного сбоя. Браузер теперь пытается осуществить проверку сертификата на предмет отзыва, но полностью отказывается от неё, если она занимает слишком много времени или если кажется, что CA ушёл в офлайн. Погодите, какие были последние слова? Проверка сертификата на предмет отзыва отменяется, «если кажется, что CA ушёл в офлайн». Интересно, может ли злоумышленник имитировать такие условия?

Если вы осуществляете атаку MiTM, то вам нужно всего лишь блокировать запрос на проверку сертификата и создать впечатление, что CA не работает. Браузер тогда столкнётся с частичным сбоем проверки и продолжит радостно использовать отозванный сертификат. Если вас никто не атакует, то каждый раз при проверке этого конкретного сертификата вы тратите время и ресурсы на проверку, что сертификат не отозван. И один раз, когда вас атакуют — тот единственный раз, когда вам по-настоящему нужна такая проверка — злоумышленник просто блокирует соединение, и браузер проходит через частичный сбой. Адам Лэнгли из Google лучше всех описал, что такое отзыв сертификата: это ремень безопасности, который рвётся в момент аварии, и он прав. Вы каждый день садитесь в машину и пристёгиваете ремень безопасности — и он даёт вам приятное и комфортное ощущение безопасности. А потом в один день что-то идёт не по плану — вы попадаете в аварию, и вот тут вы вылетаете в ветровое стекло. В тот единственный раз, когда он действительно нужен, ремень безопасности вас подводит.

Исправление проблемы

Проприетарные механизмы

Если сайт скомпрометирован и злоумышленник получил секретный ключ, то он может подделать этот сайт и причинить некоторый вред. Здесь ничего хорошего, но могло быть и хуже. Что если CA скомпрометирован и злоумышленник получил секретный ключ для промежуточного сертификата? Это было бы катастрофой, потому что тогда злоумышленник может подделать буквально любой сайт, который захочет, подписав собственный сертификат. Поэтому вместо онлайновой проверки промежуточных сертификатов на предмет отзыва у Chrome и Firefox есть собственные механизмы для той же задачи.

В Chrome он называется CRLsets, а в Firefox — OneCRL. Эти механизмы проверяют списки отозванных сертификатов, объединяя доступные CRL и выбирая оттуда сертификаты. Так проверяются особо ценные сертификаты вроде промежуточных, но что насчёт обычных, наших с вами?

OCSP Must-Staple

Чтобы объяснить, что такое OCSP Must-Staple, нужно сначала вкратце разобраться, что такое OCSP Stapling. Я не хочу здесь вдаваться в лишние подробности, вы можете получить всестороннюю информацию из моего блога по OCSP Stapling, но вот суть. OCSP Stapling избавляет браузер от необходимости отправлять запрос OCSP, выдавая ответ OCSP вместе с самим сертификатом. Это называется OCSP Stapling, потому что сервер должен «скрепить» (staple) ответ OCSP с сертификатом и выдать их вместе.

На первый взгляд это кажется немного странным, потому что сервер как будто «сам удостоверяет» собственный сертификат как неотозванный, но всё работает правильно. Ответ OCSP действует только короткий промежуток времени и подписан CA точно так же, как сертификат. Так что если браузер может удостовериться, что сертификат подписан CA, то точно так он может удостовериться, что ответ OCSP тоже подписан этим CA. Это устраняет большую проблему приватности и избавляет клиента от бремени выполнять внешний запрос. Лучший вариант! Но на самом деле не лучший, извините. OCSP Stapling — отличная вещь, и все мы должны поддерживать эту технологию на своих сайтах, но действительно ли мы думаем, что её будет поддерживать злоумышленник? Нет, я так не думаю, конечно же он не будет этого делать. Что нам на самом деле нужно — так это заставить сервер поддерживать OCSP Stapling, и вот для чего нужен OCSP Must-Staple. При запросе нашего сертификата у CA мы просим его установить на нём флаг OCSP Must-Staple. Этот флаг указывает браузеру, что сертификат должен поставляться с откликом OCSP или он будет отвергнут. Установить флаг легко.

После установки этого флага мы должны гарантировать, что используется OCSP Staple, иначе браузер отвергнет сертификат. В случае компрометации, если злоумышленник получит наш ключ, ему также придётся использовать OCSP Staple вместе с нашим сертификатом, а если он не включит OCSP Staple, то ответ OCSP скажет, что сертификат отозван, и браузер его не примет. Тада!

OCSP Expect-Staple

Хотя Must-Staple кажется отличным решением проверки отзыва сертификатом, это не совсем так. На мой взгляд, одной из самых больших проблем является то, что я как оператор сайта не могу точно знать, насколько надёжны метки OCSP Staple и как их принимает клиент. Без включенного OCSP Must-Staple это не является проблемой, но если включить OCSP Must-Staple и мы не уверены в надёжности или правильности OCSP Staple, это проблема для сайта. Чтобы попытаться и получить некую обратную связь о качестве меток OCSP Staple, мы можем активировать функцию под названием OCSP Expect-Staple. Я писал о ней раньше, и вы можете узнать все подробности в блоге OCSP Expect-Staple, но здесь тоже объясню вкратце. Вдобавок к списку предзагрузки HSTS вы запрашиваете браузер прислать отчёт, удовлетворён ли он меткой OCSP Staple. Вы можете собирать отчёты сами или использовать мой сервис report-uri.io, в обоих случаях вы точно узнаете, когда ваш сайт столкнулся с проблемами при работе OCSP Must-Staple. Поскольку использование списка предзагрузки HSTS не настолько очевидно, как мне бы хотелось, я также написал спецификацию для определения нового заголовка безопасности под названием Expect-Staple, чтобы обеспечивать ту же функциональность ценой меньших усилий. Идея в том, что теперь вы можете установить этот заголовок и включить функцию отправки отчётов, которые так нам нужны, ещё до активации Must-Staple. Установка заголовка будет простой, как и всех остальных заголовков безопасности:

Поддельные сертификаты

Если мы говорим об отзыве сертификатов, то должны рассмотреть тему их подделки. Если некто пытается скомпрометировать CA или как-то ещё получить сертификат, который ему не положен, то как он будет действовать? Если я прямо сейчас взломаю CA и получу сертификат на ваш сайт, то вы не узнаете об этом до тех пор, пока об этом не сообщат в новостях. У вас в компании даже может быть инсайдер, который получит сертификат в обход внутренних процедур, и он будет делать с ним всё что захочет. Нам нужна стопроцентная прозрачность, и скоро мы её получим. Это Certificate Transparency.

Certificate Transparency

CT — новое требование, которое станет обязательным в начале следующего года. Оно предусматривает, что все сертификаты должны заноситься в публичный журнал, чтобы браузер им доверял. Вы можете почитать статью с более подробным описанием CT, но суть в том, что CA заносит все выданные сертификаты в журнал CT.

Эти журналы полностью открыты, и любой может посмотреть их, так что если кто-то получит сертификат на ваш сайт, то вы об этом узнаете. Например, здесь вы можете увидеть все сертификаты, выданные на мой домен, и поискать свой собственный. Есть также сервис CertSpotter от sslmate для той же цели, а я использую инструмент Facebook Certificate Transparency Monitoring, который присылает вам письмо каждый раз, когда выдан сертификат на заданный домен. Стандарт CT — это фантастическая идея, и я не могу дождаться, когда он станет обязательным, но есть одна оговорка. Дело в том, что CT — это только первый шаг. Знать об этих сертификатах хорошо, но у нас по-прежнему остаются все упомянутые проблемы с их отзывом. Тем не менее, мы можем решать только по одной проблеме за раз, и даже самые лучшие в мире механизмы отзыва неэффективны, если мы не знаем, какие сертификаты нужно отзывать. CT по крайней мере даёт нам эту информацию.

Авторизация центров сертификации

Предотвратить выдачу сертификата намного проще, чем пытаться отозвать его, и именно для этого нужна авторизация центров сертификации (CAA). Опять же, подробности есть в статье по ссылке, но вкратце суть в том, что мы можем авторизовать только конкретные центры сертификации выдавать нам сертификаты, в отличие от нынешней ситуации, когда мы не можем указать вообще никаких предпочтений. Авторизация делается так же просто, как создание записи DNS:

scotthelme.co.uk. IN CAA 0 issue "letsencrypt.org"

Хотя авторизация CA — не особенно сильный механизм, и он не способен помочь во всех ситуациях некорректной выдачи сертификатов, но в некоторых случаях он полезен, так что следует заявить о своих предпочтениях, создав запись CAA.

Заключение

В настоящий момент существует реальная проблема, что мы не можем отозвать сертификат, если кто-то получил наш секретный ключ. Только представьте, во что это выльется при раскрытии следующей глобальной уязвимости масштаба Heartbleed! Одна вещь, которую вы можете попытаться сделать — это ограничить размер ущерба от утечки, сократив срок действия своего сертификата. Вместо трёх лет указывайте один год или даже меньше. Let's Encrypt выдаёт только сертификаты, которые действительны всего лишь 90 дней! С сокращением времени жизни вашего сертификата у злоумышленника будет меньше времени для злоупотреблений. Кроме этого мы мало что можем сделать.

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

После принятия сертификатов страница авторизации яндекса открывается. В мозиле или хроме открывается в каком-то ущербном виде, как будто включается текстовый режим (т.е. не грузятся картинки и оформления).

На компьютере заведующей всё работает нормально, но у неё DNS прописан - гугловский - 8.8.8.8 уже пару месяцев.
На одном из компьютеров попробовал этот же днс - не помогло.

Надо будет проверить следующее - подключить 4g-модем к этому компьютеру и проверить (вчера эта мысль не пришла в голову).
А больше мыслей нет.

Как я понимаю нужно как-то добавить этот центр сертификации и проверить его доступность - а как?
И есть ли общий список, может есть ещё какие-то недостающие для других сайтов?

Добавлено:
Да, и еще. не мешайте коней разной масти. Если обсуждаем Centrum, то Centrum. Если же некий Inside, то эскюзе муа, это совсем другое.
С чем работаем?

Добавлено:
И снова еще. Вы когда определитесь с сертификатом, который не работает, вышлите мне его на мыло (открыл в профиле), дабы нам здесь не мусорить.

Да, и такой симптом, что после изменений, внесенный в куда угодно, фильрация ДНС, фаервол и т.п действует на работоспособность SSL не сразу, а через некоторое время, с вероятностью 95% указывает на недоступность CRL

А нашёл где почта

Добавлено:
О хитром подключении к интернету я написал, т.к. в нём действительно могут крыться проблемы. Но для этих пользователей (компьютеров) ничего и не менялось, менялось только для компьютера заведующей (пару месяцев назад) и у неё как работало, так и работает, а у них перестало.

Так же понятно, что если пользователь зашел на фишинговый сайт, да еще и не только принял, а даже установил левый сертификат, то что бы хакеру не слушать? Ему в ухо кричат, так все и слышно. Скорее, его трудно слушать сторонним субъектам.
Выслал мне топикстартер сертификаты. Ну лажа полная. Wildcard, не доверенный, без CRLDP. на коленке сделано короче.

Топикстартеру.
Советую поменять пароли. Пользоваться впредь аккуратнее.

Добавлено:
В общем вот так вот )я топикстартеру отписал) и раждаются ботнеты, происходят утечки переписки в СМИ. Ничего гениального.

nslookup - 8.8.8.8
Addresses: 217.69.139.202
94.100.180.200
217.69.139.200
94.100.180.202

Monsterik1
Вы пишите когда попробуете. Какой смысл писать, что мол я сейчас в метро, доберусь отпишу? Так не надо.

Что такое SSL

Текущие тенденции сайтостроения предполагают высокую безопасность соединения пользователя с веб-ресурсом. Это необходимо для защиты персональных данных, секретных номеров банковских карт и информации о проводимых сделках. Организуется безопасность подключением протокола шифрования Secure Sockets Layer (сокращенно SSL).

Сертификат выпускается доверенным центром Certification Authority (CA).
После выдачи он подключается к домену средствами провайдера хостинга.
Срок его действия ограничен 1 годом, после чего требуется продление.

При появлении любых сомнений в исправности защиты регистрироваться на сайте или вводить ранее выданные логин и пароль не рекомендуется. Тем более не стоит осуществлять онлайн-оплату с банковских карт или электронных кошельков, ведь не исключено, что проблема возникла из-за взлома ресурса злоумышленниками.

Причины появления ошибок SSL

Существует всего две причины, почему браузер отображает ошибку сертификата SSL со стороны сервера. Первая заключается в окончании срока активации, вторая – это покупка сертификата у поставщика без достаточных полномочий для выдачи «полноценной защиты». Например, виной может быть выбор самоподписанного сертификата, лишь эмулирующего работу реального протокола.

Остальные проблемы обычно скрываются на локальном компьютере:

Произошел сброс системного времени.
Неправильно настроена антивирусная программа.
Сбоит браузер или установленное расширение.
Срабатывает вредоносный скрипт.

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

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

Время и дата

Сертификат SSL имеет четко обозначенный срок действия с датой активации и деактивации. Такой подход отчасти дает дополнительную защиту, потому что в случае технического сбоя в системных часах компьютера сайты перестают открываться. Сброс времени обычно происходит «назад», на дату изготовления материнской платы, на что и реагирует система.

Варианты исправления ситуации:

Вручную внести корректную дату и время, после чего обновить страницу в браузере.
Воспользоваться функцией синхронизации через интернет, встроенной в Windows.
Заменить батарейку на памяти BIOS. При первом запуске ПК нужно внести корректные данные.

Каждый раз после изменения времени рекомендуется ручное обновление страницы или перезапуск браузера. Такой шаг активирует повторное соединение с сервером и позволяет зайти на сайт «с нуля», но уже с правильным временем, соответствующим сроку действия сертификата SSL (после активации и до ее завершения).

Настройки антивируса и брандмауэра

Варианты исправления ситуации:

Функция временного отключения имеется в любой защитной программе, даже интегрированной в операционную систему Windows. Но это не гарантирует полную деактивацию приложения. В этом случае разобраться в ситуации поможет открытие сайта на другом компьютере или запуск безопасного режима (актуально для проводного подключения к интернету).

Браузер и операционная система

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

Варианты исправления ситуации:

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

Остается еще один вариант – сбросить настройки браузера до состояния «по умолчанию». Способ аналогичен переустановке, но экономит время. Правда, он неэффективен, если проблема возникла из-за сбоя в одном из служебных файлов программы. Отдельное внимание стоит уделить расширению, выполняющему функции антивирусной защиты, ведь оно часто блокирует даже безопасное соединение.

Заражение компьютерными вирусами

Выдачей ошибки SSL браузер, вероятно, предупреждает о попытке его подмены, переадресации на сайт-клон или иной угрозе. В это случае рекомендуется провести полную проверку компьютера на наличие вирусов. Если присутствуют другие признаки заражения, стоит скачать парочку программ со свежими антивирусными базами (например, CureIt).

Варианты исправления ситуации:

Временно отключить все программы из автозагрузки.
Провести очистку диска от временных файлов.
Перезагрузить компьютер после предыдущих шагов.

Выполняются перечисленные действия программами типа CCleaner. Они дают прямой доступ как к автозагрузке операционной системе, так и к списку расширений установленных браузеров. Также в таких программах обычно есть функция удаления ненужных системных файлов, в которых запросто может быть тело компьютерного вируса.

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

Но это установит этот параметр только для моего пользователя, а не для других пользователей. Другие пользователи все еще сталкиваются с этой проблемой.

В сертификате веб-сайта CRL Distribution Point -> имя точки распространения - > Полное имя URL= http:/ / ss.symcb.com/ss. crl ". CRL точка распространения URL недоступна, так как на сервере нет подключения к интернету.

OS : Windows 2012 R2

Офис : Office Профессиональный Плюс 2016

1 ответ

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

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