В консоли оператора
Microsoft Operations Manager 2005 или консоли
управления
System Center Operations Manager 2007 при
невозможности проверить сертификат могут возникать описанные ниже
ошибки. Ошибки также могут возвращаться в виде событий журнала
приложений. В этом разделе описываются способы устранения этих
ошибок либо приводятся ссылки на документы, которые позволяют
устранить ошибки проверки сертификата.
Дополнительные сведения о том, как транспортная служба Microsoft
Exchange выбирает сертификаты для протокола TLS, см. в разделе
Выбор
TLS-сертификата SMTP.
В ответ на отчет, отправленный в Пенсионный фонд, получено уведомление об ошибке «Не удалось проверить этот сертификат, поскольку не получен правильный список отзыва сертификатов от центра сертификации, выпустившего этот сертификат».
Причина
Пенсионный фонд не обновил список отзыва сертификатов.
Решение
Дождитесь, когда ПФ обновит список отзыва. Обычно это занимает не более суток. Повторно отправлять отчет не требуется.
Если прошло более суток, и не получено извещение о получении (квитанция), обратитесь в удостоверяющий центр, который выдал сертификат.
Нашли неточность? Выделите текст с ошибкой и нажмите ctrl + enter.
Методика выявления причины исключения
Для точной диагностики проблемы следует посмотреть записи в журнале CAPI2 операционной системы Windows.
- По умолчанию журнал не ведется и его следует включить. (Здесь и далее инструкция приводится для Windows 10). В меню Пуск выберите Средства администрирования – Просмотр событий.В окне Просмотр событий в списке Журналы приложений и служб выберите Microsoft – Windows – CAPI2 – Operational.В списке Действия выберите Включить журнал.
- Ошибка проверки отзыва сертификата средствами операционной системы может выглядеть следующим образом:
Некоторые подробности можно выяснить, если посмотреть ошибки рядом. Например, в данном случае есть такая ошибка:
В разделе System указаны дополнительные сведения. Например:
Как только сервер запустят от имени доменного пользователя, ошибка проверки отзыва сертификата средствами ОС перестанет воспроизводиться.
Зачастую проблемы проверки отзыва сертификатов возникают из-за ограничений доступа к интернет-ресурсам, установленными администратором интрасети. Это может быть сделано с помощью прокси, сетевых экранов (включая шлюзы, антивирусы, локальные сетевые экраны и т.п.).
Часто при использовании цифровых сертификатов для Exchange 2010 вы можете столкнуться со следующей ошибкой в консоли EMC, сопровождающейся описанием: The certificate status could not be determinde because the revocation check failed.
Из-за этого вы не можете назначить данный сертификат для служб Exchange из консоли (хотя, при желании, можете это сделать с помощью комманды Enable-ExchangeCertificate из EMS). При этом просмотр самого сертификат может не показать ничего подозрительного.
Более того, попытка проверить доступность списка отзыва сертификатов вручную (например, с помощью веб-браузера, файлового менеджера или adsiedit) заканчивается успешно. Что делать в таком случае?
Если вы используете сторонний сертификат доверенной организации (вроде VeriSign или Thawte), прочитайте данную статью, возможно, ваши проблемы решатся.
Если же вы используете собственную инфраструктуру открытых ключей и центры выдачи сертификатов (например, на базе Microsoft CA), то следует проверить корректность настроек путей AIA и CRL в вашей инфраструктуре. Сделать это можно через оснастку pkiview.msc, запущенной на сервере выдачи сертификатов.
В данном примере используется двухуровневая инфраструктура PKI, с корневым изолированным ЦС (Offline Standalone Root CA) и подчиненным ЦС уровня предприятия (Enterprise Intermediate CA). Проблемы могут быть из-за неправильного конфигурирования путей на этапе установки ЦС или из-за их недоступности на текущий момент (ошибок в DNS, маршрутизации, блокировки брандмаэрами, антивирусами).
Для блокировки проверки выполните на подчиненном ЦС команду: certutil -setreg caCRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE и перезапустите службу ЦС net stop certsvc & net start certsvc
После этого вернитесь на сервер Exchange, очистите кэш certutil -urlcache crl delete и перезагрузите сервер Exchange.
В этом разделе описаны способы устранения ошибок проверки
сертификата или приводятся ссылки на документы, содержащие сведения
об устранении этих ошибок.
Дополнительные сведения о том, как служба транспорта
Microsoft Exchange выбирает сертификаты для протокола TLS, см.
в следующих разделах:
Сертификат действителен, но он является самозаверяющим.
Это сообщение о состоянии указывает, что имя домена в
полях имени субъекта или дополнительного имени субъекта сертификата
не соответствует FQDN отправителя или имени домена получателя.
Чтобы исправить эту ошибку, необходимо создать новый сертификат,
соответствующий полному доменному имени соединителя оправки или
приема, который пытается проверить этот сертификат.
Дополнительные сведения см. в разделе Общие сведения о
сертификатах TLS.
Не
удалось проверить подпись сертификата.
Это сообщение о состоянии указывает, что службе
транспорта Microsoft Exchange не удалось проверить цепочку
сертификатов или что для проверки подписи сертификата использовался
неправильный открытый ключ.
Цепочка
сертификатов обработана, но она заканчивается корневым
сертификатом, которому не доверяет поставщик доверия.
Это сообщение о состоянии указывает, что хранилище
сертификатов компьютера не доверяет сертификату, используемому для
этой операции. Чтобы данный сертификат был доверенным, необходимо,
чтобы в хранилище сертификатов данного компьютера присутствовал его
корневой центр сертификации.
Дополнительные сведения о добавлении сертификатов в
локальное хранилище сертификатов вручную см. в файле справки для
оснастки диспетчера сертификатов в консоли управления Microsoft
(MMC).
Сертификат недействителен для запрошенного использования.
Это сообщение о состоянии указывает, что необходимо
включить сертификат для использования в текущем приложении.
Например, чтобы использовать этот сертификат для безопасности
домена, необходимо включить сертификат для протокола SMTP.
Дополнительные сведения о включении сертификатов см. в
разделе Enable-ExchangeCertificate.
Кроме того, это сообщение о состоянии может указывать,
что поле «Расширенное использовании ключа» для используемого
сертификата содержит неправильные данные. Все сертификаты,
используемые для протокола TLS, должны содержать идентификатор
объекта проверки подлинности сервера (также называется
идентификатором объекта). Чтобы использовать для протокола TLS
сертификат, не содержащий в поле «Расширенное использовании ключа»
идентификатор объекта проверки подлинности сервера, необходимо
создать новый сертификат.
При
проверке необходимого сертификата по системным часам или отметке
времени в подписанном файле его срок действия оказывается
истекшим.
Это сообщение о состоянии указывает, что системное
время установлено неправильно, срок действия сертификата истек или
в системе, подписавшей файл, установлено неправильное время.
Проверьте, выполнены ли следующие условия:
- часы на локальном компьютере показывают точное время;
- срок действия сертификата не истек;
- часы в отправляющей системе показывают точное время.
Если срок действия сертификата истек, необходимо
создать новый сертификат.
Сроки
действия цепочки сертификатов вложены неправильно.
Это сообщение о состоянии указывает, что цепочка
сертификатов повреждена или является ненадежной. Создайте с помощью
командлета New-ExchangeCertificate
новый сертификат либо свяжитесь с центром сертификации, чтобы
проверить цепочку сертификатов, использованную для данного
сертификата.
Сертификат, который может применяться только как конечный субъект,
используется в качестве центра сертификации или наоборот.
Это сообщение о состоянии указывает, что сертификат
недействителен, так как он выпущен сертификатом конечного субъекта,
а не центром сертификации. Сертификат конечного субъекта — это
сертификат, созданный для криптографического использования в
определенном приложении. Создайте с помощью командлета New-ExchangeCertificate
новый сертификат либо свяжитесь с центром сертификации, чтобы
проверить сертификат.
Сертификат или подпись отозваны.
Обратитесь в центр сертификации, чтобы устранить эту
неполадку.
Сертификат явно отозван его поставщиком.
Это сообщение о состоянии указывает, что сервер отзыва
для сертификата недоступен. В некоторых случаях эта ошибка является
временной и связанной с тем, что сервер отзыва сертификатов
функционирует неверно. В противном случае убедитесь в том, что
компьютер имеет доступ к серверу отзыва сертификатов. Если между
компьютером и сервером отзыва сертификатов находится брандмауэр или
прокси-сервер, убедитесь в том, что компьютер настроен
соответствующим образом.
Дополнительные сведения см. в разделе Включение инфраструктуры
открытых ключей на пограничном транспортном сервере для
безопасности домена.
Не
удалось продолжить процесс отзыва. Не удалось проверить
сертификаты.
Проблема CRL в том, что списки содержат много сертификатов от конкретных центров сертификации. Не вдаваясь в излишние детали, они разбиваются на промежуточные сертификаты CA, а центр сертификации может выдавать списки меньшими частями, но проблема остаётся той же. У списка CRL немалый размер. Другая проблема в том, что у клиента нет свежей копии CRL, ему нужно запросить её при первоначальном подключении к сайту, что может сделать всю процедуру заметно медленнее. Всё это выглядит не очень приятно, так что посмотрим на OCSP.
Исправление проблемы
Прямо сейчас в данный конкретный момент времени реальность такова, что мы не можем исправить ситуацию. Впрочем, кое-что можно предпринять и, возможно, в будущем механизм отзыва сертификатов станет по-настоящему надёжным.
Я написал несколько инструкций по этому процессу, в том числе с чего начать, как грамотно обновить и как использовать двойные сертификаты. Это всё здорово, не правда ли? Но в чём проблема? А проблема возникнет тогда, когда всё пойдёт не по плану и у вас случится плохой день.
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 скажет, что сертификат отозван, и браузер его не примет. Тада!
Диагностика ошибок ОС Windows при проверке сертификата
Методика выявления причины исключения
Варианты настройки платформы
Начиная с версии 8.3.12 платформа «1С:Предприятие» при установке защищенного (SSL/TLS) соединения выполняет проверку сертификата сервера средствами операционной системы Windows. У конечных пользователей может периодически возникать исключение: «Удаленный узел не прошел проверку. Не удалось выполнить проверку отзыва сертификата». Часто появление такого исключения связано с ограничениями доступа в Интернет или прав пользователя, от имени которого запущена служба сервера «1С:Предприятия».
Проприетарные механизмы
Если сайт скомпрометирован и злоумышленник получил секретный ключ, то он может подделать этот сайт и причинить некоторый вред. Здесь ничего хорошего, но могло быть и хуже. Что если CA скомпрометирован и злоумышленник получил секретный ключ для промежуточного сертификата? Это было бы катастрофой, потому что тогда злоумышленник может подделать буквально любой сайт, который захочет, подписав собственный сертификат. Поэтому вместо онлайновой проверки промежуточных сертификатов на предмет отзыва у Chrome и Firefox есть собственные механизмы для той же задачи.
В Chrome он называется CRLsets, а в Firefox — OneCRL. Эти механизмы проверяют списки отозванных сертификатов, объединяя доступные CRL и выбирая оттуда сертификаты. Так проверяются особо ценные сертификаты вроде промежуточных, но что насчёт обычных, наших с вами?
Варианты настройки платформы
Платформа «1С:Предприятие 8» поддерживает следующие варианты настройки проверки отзыва сертификата:
- По умолчанию. – С получением исключений «Удаленный узел не прошел проверку. Не удалось выполнить проверку отзыва сертификата».
- Настройка, позволяющая игнорировать ошибки проверки отзыва сертификата и не вызывать на них исключения.
Внимание! Такая настройка снижает уровень доверия к внешним ресурсам! В случае применения данной настройки ответственность возлагается на пользователя.
Для того, чтобы включить игнорирование ошибки проверки отзыва сертификата необходимо в файле conf.cfg добавить строку:
Следует иметь в виду, что данный механизм игнорирует именно ошибки проверки отзыва, а не отменяет проверку отзыва сертификата. Поэтому если сертификат сервера отозван и это подтверждено, то соединение с таким сервером установлено не будет.
Частичный сбой
На самом деле сегодня браузеры выполняют так называемую проверку отзыва сертификата с частичным сбоем. То есть браузер попытается проверить статус сертификата, но если ответ не пришёл совсем или не пришёл за короткий промежуток времени, то браузер просто забывает об этом. Ещё хуже, что Chrome даже не пытается проверить сертификат. Да, вы прочитали правильно, Chrome даже не пытается проверить статус сертификата, который ему поступает. Вы можете найти это странным, но я полностью согласен с их подходом и я рад сообщить, что Firefox тоже, вероятно, скоро начнёт работать так же. Позвольте объяснить. Проблема с полным сбоем очевидна: если у CA плохой день, то у нас тоже он будет, вот так мы пришли к логике частичного сбоя. Браузер теперь пытается осуществить проверку сертификата на предмет отзыва, но полностью отказывается от неё, если она занимает слишком много времени или если кажется, что CA ушёл в офлайн. Погодите, какие были последние слова? Проверка сертификата на предмет отзыва отменяется, «если кажется, что CA ушёл в офлайн». Интересно, может ли злоумышленник имитировать такие условия?
Если вы осуществляете атаку MiTM, то вам нужно всего лишь блокировать запрос на проверку сертификата и создать впечатление, что CA не работает. Браузер тогда столкнётся с частичным сбоем проверки и продолжит радостно использовать отозванный сертификат. Если вас никто не атакует, то каждый раз при проверке этого конкретного сертификата вы тратите время и ресурсы на проверку, что сертификат не отозван. И один раз, когда вас атакуют — тот единственный раз, когда вам по-настоящему нужна такая проверка — злоумышленник просто блокирует соединение, и браузер проходит через частичный сбой. Адам Лэнгли из Google лучше всех описал, что такое отзыв сертификата: это ремень безопасности, который рвётся в момент аварии, и он прав. Вы каждый день садитесь в машину и пристёгиваете ремень безопасности — и он даёт вам приятное и комфортное ощущение безопасности. А потом в один день что-то идёт не по плану — вы попадаете в аварию, и вот тут вы вылетаете в ветровое стекло. В тот единственный раз, когда он действительно нужен, ремень безопасности вас подводит.
Нас хакнули
Если злоумышленник завладел нашим секретным ключом, то он может выдать себя за нас. Повторим это: кто-то в интернете может доказать, что он — это вы, хотя в реальности он таковым не является. Это реальная проблема, и прежде чем вы подумаете «Со мной такого никогда не произойдёт», вспомните Heartbleed. Этот крошечный баг в библиотеке OpenSSL позволял злоумышленнику украсть ваш секретный ключ, даже если вы соблюдали все меры безопасности. Кроме этого, было бесчисленное множество случаев, когда секретные ключи утекали из-за случайности или небрежности. Реальность такова, что мы можем потерять наш секретный ключ, а когда это случается, нам требуется способ помешать злоумышленнику использовать наш сертификат. Нужно его отозвать.
Полный сбой
Выше я говорил о CRL и OCSP, двух механизмах проверки сертификатов браузером, и они выглядят таким образом.
После получения сертификата браузер обратится к одному из этих сервисов и отправит запрос для окончательного выяснения статуса сертификата. А что, если у вашего CA плохой день и его инфраструктура в офлайне? Что, если ситуация выглядит так?
Certificate Transparency
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.
Протокол проверки статуса сертификата
OCSP предлагает намного более красивое решение проблемы и имеет значительное преимущество перед CRL. Здесь мы спрашиваем у CA статус единственного, конкретного сертификата. Это значит, что CA должен вернуть только простой ответ: сертификат либо хороший, либо отозван, и такой ответ гораздо меньше по размеру, чем список CRL. Отлично!
Сертификат для pornhub.com валидный?
Заключение
В настоящий момент существует реальная проблема, что мы не можем отозвать сертификат, если кто-то получил наш секретный ключ. Только представьте, во что это выльется при раскрытии следующей глобальной уязвимости масштаба Heartbleed! Одна вещь, которую вы можете попытаться сделать — это ограничить размер ущерба от утечки, сократив срок действия своего сертификата. Вместо трёх лет указывайте один год или даже меньше. Let’s Encrypt выдаёт только сертификаты, которые действительны всего лишь 90 дней! С сокращением времени жизни вашего сертификата у злоумышленника будет меньше времени для злоупотреблений. Кроме этого мы мало что можем сделать.
Я бы хотел закончить статью вопросом: следует ли нам исправлять процедуру отзыва сертификатов? Впрочем, это тема для другой статьи.
В случае компрометации мы должны отозвать сертификат, чтобы исключить возможность злоупотреблений. Как только сертификат помечен как отозванный, браузер знает, что ему нельзя доверять, даже если у него не закончился срок действия. Владелец запросил отзыв, и ни один клиент больше не должен принимать этот сертификат.
Как только мы узнаём о факте взлома, мы связываемся с CA и просим отозвать наш сертификат. Нужно доказать факт владения сертификатом, и как только мы сделали это, то CA помечает сертификат как отозванный. Теперь нужен способ сообщить об этом факте каждому клиенту, которому может потребоваться данная информация. Прямо в этот момент браузер, конечно, ничего не знает, и это проблема. Есть два механизма, которые используются для распространения информации: это список отозванных сертификатов (Certificate Revocation List, CRL) и протокол проверки статуса сертификата (Online Certificate Status Protocol, OCSP).
Авторизация центров сертификации
Предотвратить выдачу сертификата намного проще, чем пытаться отозвать его, и именно для этого нужна авторизация центров сертификации (CAA). Опять же, подробности есть в статье по ссылке, но вкратце суть в том, что мы можем авторизовать только конкретные центры сертификации выдавать нам сертификаты, в отличие от нынешней ситуации, когда мы не можем указать вообще никаких предпочтений. Авторизация делается так же просто, как создание записи DNS:
scotthelme.co.uk. IN CAA 0 issue «letsencrypt.org»
Хотя авторизация CA — не особенно сильный механизм, и он не способен помочь во всех ситуациях некорректной выдачи сертификатов, но в некоторых случаях он полезен, так что следует заявить о своих предпочтениях, создав запись CAA.