Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

Что делать, если у вашего сервера утёк закрытый ключ? Вопрос, ставший особенно актуальным после Heartbleed.

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

К сожалению, всё не так просто. В этой и следующей статьях мы подробно ответим на следующие вопросы:

  • Какие механизмы проверки статуса сертификатов бывают?
  • Как они реализованы в современных Веб-браузерах?
  • Кто виноват? Почему они реализованы именно так?
  • Что делать? Какие есть перспективы?

Эта статья будет полезна тем, кому интересно разобраться в применяющихся на практике механизмах проверки статуса сертификатов (проверки, является ли сертификат отозванным).

UPD: добавили вторую часть статьи! Прочитать можно тут.

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

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

  • CRL (Certificate Revocation List) – проверяется наличие серийного номера сертификата в списке отзыва.
  • OCSP (Online Certificate Status Protocol) – сертификат отправляется на специализированный сервер, где проверяется его статус.

Рассмотрим оба эти способа более подробно с помощью консоли Ubuntu. А в качестве примера проверим на отзыв сертификат для домена habr. com.

TurboConf — расширение возможностей Конфигуратора 1С

ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку «Обновить» в браузере.

Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно. Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.

Методика выявления причины исключения

Для точной диагностики проблемы следует посмотреть записи в журнале CAPI2 операционной системы Windows.

  • По умолчанию журнал не ведется и его следует включить. (Здесь и далее инструкция приводится для Windows 10). В меню Пуск выберите Средства администрирования – Просмотр событий.В окне Просмотр событий в списке Журналы приложений и служб выберите Microsoft – Windows – CAPI2 – Operational.В списке Действия выберите Включить журнал.
  • Ошибка проверки отзыва сертификата средствами операционной системы может выглядеть следующим образом:

Некоторые подробности можно выяснить, если посмотреть ошибки рядом. Например, в данном случае есть такая ошибка:

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

В разделе System указаны дополнительные сведения. Например:

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

Как только сервер запустят от имени доменного пользователя, ошибка проверки отзыва сертификата средствами ОС перестанет воспроизводиться.

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

Как настроить сертификат ЭП в программе 1С:Документооборот 8

Ситуация: недействителен сертификат или электронная подпись

Шифрование и расшифровка файлов

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

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

Использование ЭП предполагает наличие сертификата ключа подписи — документа, содержащего открытый ключ подписи и информацию о ее владельце.

Разделяют 3 вида ЭП:

Простая ЭП – упрощенная подпись. Ее достаточно для установления авторства, например, при ведении переписки.

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

Усиленная квалифицированная электронная подпись лица – в основном используется для подписания юридически значимых электронных документов в системе электронного документооборота. Например, договоров, содержащих печать организации, счетов-фактур, товарных накладных ТОРГ-12 и т. (рис.

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

Как настроить сертификат ЭП в программе 1С

Настройка сертификата ЭП имеет два этапа: настройка программы и персональные настройки.

Настройка программы выполняется во вкладке «Настройка и администрирование» – «Настройка программы» – «Общие настройки» (рис.

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

Для начала работы с ЭП необходимо:

Разрешить использовать электронные подписи в общих настройках программы (рис.

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

Установить на рабочие компьютеры пользователей один или несколько криптопровайдеров и настроить их.

Для того чтобы остальные сотрудники смогли проверять электронные подписи, требуется установить флаг «Проверять подписи и сертификаты на сервере» (рис. 4), затем выполнить установку криптопровайдера на каждый компьютер кластера серверов «1С:Предприятия».

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

По умолчанию в списке программ уже присутствуют два криптопровайдера: ViPNet CSP и КриптоПро CSP. Можно добавить любые другие программы. При этом в 1С:Документооборот 8 уже поставляются готовые настройки для Microsoft Enhanced CSP, ViPNet CSP, КриптоПро CSP, ЛИССИ CSP, Сигнал-КОМ CSP.

Персональные настройки ЭП

После того как администратор установил криптопровайдер и настроил профили криптографии, можно приступать к настройке рабочего места пользователя. Это делается в персональных настройках программы на закладке «Настройка и администрирование»:

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

При подписании документов и файлов программа сама предложит выбрать один из личных сертификатов, установленных в персональных настройках ЭП. Если сертификат не найден, система покажет ошибку:

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

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

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

Для регистрации сертификата необходимо:

Выбрать назначение сертификата: для подписания и шифрования либо только для шифрования.

Выбрать сертификат, установленный на компьютере.

Ввести пароль сертификата для автоматического определения подходящих настроек программы ЭП и шифрования. Для того чтобы выбрать профиль настроек криптографии вручную, необходимо пропустить ввод пароля с помощью кнопки «Отмена».

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

Заполнить карточку сертификата. В назначении указать понятное описание сертификата. Например, «Для подписания внутренних документов» или «Для обмена документами с контрагентами». Назначение будет выводиться при выборе сертификата для подписания.

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

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

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

Любой из установленных сертификатов можно пометить на удаление. На статус подписей, удостоверенных этим сертификатом, это не повлияет.

Если на компьютере текущего пользователя зарегистрировано несколько сертификатов, то откроется окно с возможностью выбора требуемого сертификата.

Пользователь выбирает сертификат и вводит пароль к нему.

Пароль сертификата ЭП можно запомнить на время сеанса работы с программой. Для этого при подписании или расшифровке объекта информационной базы достаточно ввести пароль к сертификату и установить флаг «Запомнить пароль». Если флаг установлен, то до закрытия программы текущему пользователю не придется вводить пароль сертификата ЭП при каждом подписании или расшифровке.

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

Подписанный ЭП документ или файл недоступен для редактирования. Чтобы внести изменения в документ, потребуется удалить все подписи. Каждый пользователь может удалить только свои подписи. Право удаления всех подписей принадлежит администратору.

Подписание резолюций и виз согласования ЭП

К резолюции электронная подпись может быть добавлена вручную или автоматически (при выполнении задачи рассмотрения и утверждения). Для добавления резолюции вручную и проверки ЭП используется группа команд ЭП на панели действий карточки резолюции.

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

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

Обратите внимание: подписанная ЭП резолюция становится недоступна для редактирования. Изменить резолюцию можно только после удаления всех ее ЭП.

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

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

Проверка наличия ЭП резолюций и виз

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

Для того чтобы заверение резолюций электронной подписью было обязательным для определенного вида документа, предусмотрен Флаг «Подписывать резолюции электронной подписью» на закладке Настройки карточки вида документа.

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

После установки флажка программа не позволит сохранить неподписанные резолюции для документа этого вида. Если предметом процесса «Рассмотрение» указан вид документа с обязательной ЭП резолюции, то независимо от выбранного варианта рассмотрения (ввод текста резолюции, исполнение или просто ознакомление) перед выполнением задачи будет запрошена электронная подпись.

Чтобы настроить обязательное подписание визы электронной подписью, при создании процесса согласования нужно установить флаг «Подписывать ЭП при согласовании». При этом процесс будет считаться выполненным только после успешного подписания визы. Если же при подписании визы возникает ошибка или подписание отменяется, то задача так и остается невыполненной.

Читать также:  Инструменты для работы с эросэлторг неправильно настроены на вашем компьютере

На командной панели карточки сертификата ЭП предусмотрена кнопка проверки сертификата.

Кнопка открывает окно с перечнем параметров проверки. Действительный сертификат должен пройти успешную проверку по всем параметрам.

Если проверка не прошла успешно, необходимо нажать на иконку для получения информации об ошибке.

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

Статус проверки электронной подписи сохраняется в информационной базе и отображается в карточке электронной подписи, карточках и списках всех подписываемых объектов.

Проверка подписи и сертификата выполняется раздельно и присваивает электронной подписи один из общих статусов:

■ Действительна – если действительны и подпись, и сертификат;

■ Действительна, но нет доверия к сертификату – если действительна только подпись, но не сертификат;

■ Недействительна – если недействительны ни подпись, ни сертификат.

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

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

Помимо статуса подписи, в карточке ЭП можно ознакомиться с причиной отрицательного результата проверки, датой подписания, владельцем сертификата и перейти в карточку сертификата.

Подпись можно сохранить в файл (например, для дальнейшей пересылки по электронной почте). Расширение файла указывается в персональных настройках ЭП. По умолчанию это p7s.

Недействителен сертификат или электронная подпись

Ниже перечислены наиболее частые причины, по которым недействительный сертификат может быть признан таковым:

■ Требуемый сертификат не прошел проверки по сроку действия при сверке с системными часами или временем подписи в файле. Это означает, что на момент проверки срок действия сертификата истек.

■ Цепочка сертификатов обработана, но прервана на корневом сертификате, который не является доверенным. Это значит, что программе не удается построить цепочку сертификатов для доверенного корневого центра. При этом необходимо проверить:

○ установлены ли на компьютере все сертификаты корневых и подчиненных удостоверяющих центров и действительны ли они;

○ установлен ли список отозванных сертификатов (файл с расширением CRL) и есть ли доступ до OCSP-службы.

■ Не удалось проверить сертификат в списке отозванных, так как соответствующий сервер находится в состоянии offline – в этом случае необходимо запросить список отозванных сертификатов в удостоверяющем центре, выдавшем сертификат, и установить этот список в ОС (файл с расширением CRL). Обратите внимание, что у этого списка ограниченный срок действия, поэтому его необходимо время от времени обновлять.

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

Хеш-значение неправильное – ЭП не соответствует подписанным данным. В качестве проверки убедитесь, что данные не были изменены после подписания:

■ Внутри программы 1С:Документооборот 8 изменение подписанных данных исключено (так как подписанный файл закрыт от редактирования), но целостность файла не гарантируется при хранении в томах.

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

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

Шифрование и расшифровка файлов

Шифрование предназначено для защиты информации от несанкционированного доступа. В функционал 1С:Документооборот входит шифрование информации для защиты от несанкционированного доступа. Расшифровать файл можно только с помощью закрытого ключа одного из сертификатов. Так же в программе реализована возможность ограничения доступа к файлу с помощью прав доступа. Минус этого варианта — файл будет доступен администратору базы. Только если зашифровать файл сертификатом сотрудника, невозможно будет расшифровать файл без ключа сертификата.

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

Зашифровать и расшифровать можно любой файл с помощью группы команд ЭП в подменю «Еще» карточки и списка файлов (рис. 14).

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

После выполнения команды программа предложит вам выбрать сертификат пользователя, который позволит расшифровать этот файл. До этого вам необходимо указать ваш личный сертификат для расшифровки файла. Далее при вызове команды «Расшифровать» программа автоматически выберет нужный сертификат и предложит ввести пароль для расшифровки.

Существуют особенности шифрования файлов:

■ шифруются все версии файла;

■ зашифрованный файл можно копировать, копия останется зашифрованной;

■ зашифрованный файл запрещено редактировать;

■ для зашифрованных файлов не работает полнотекстовый поиск;

■ зашифрованный файл нельзя подписать ЭП, но подписанный ЭП файл можно зашифровать. Программа позволяет проверить подписи зашифрованного файла, причем при выполнении этой операции файл остается зашифрованным.

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

Обязательный сертификат должен быть привязан к каждой из установленных программ шифрования. Для этого в настройках ЭП и шифрования предусмотрена колонка Обязательный сертификат для шифрования.

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

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

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

Специалист компании ООО «Кодерлайн»

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

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

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

Certificate Transparency

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

Сертификаты

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

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

OCSP

Выведем на экран сертификат интересующего нас домена и цепочки промежуточных (Intermediate) сертификатов:

Сохраним в файлы сертификат домена и промежуточный сертификат (код между строками ——BEGIN CERTIFICATE—— и ——END CERTIFICATE——):

/tmp/habr. com. crt
/tmp/intermediate. crt

openssl x509 -in /tmp/habr. com. crt -noout -ocsp_uri

Отправим запрос OCSP-серверу проверить сертификат на предмет отзыва:

Если всё указали правильно, то OCSP-сервер должен вернуть информацию по сертификату.

Здесь интерес представляют последние строчки:

Response verify OK
/tmp/habr. com. crt: good

Об отсутствии сертификата в списке отозванных говорит значение «good», если же сертификат отозвали, то значение будет «revoked».

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

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

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

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

Читать также:  Сертификат происхождения товара по форме ст 1 что это такое

CRL

Скачаем сертификат интересующего нас домена:

Смотрим детали сертификата:

openssl x509 -noout -text -in /tmp/habr. com. crt

Здесь нас интересует в разделе «X509v3 CRL Distribution Points» пункт «Full Name».

Скачиваем по этой ссылке список CLR:

Выдираем серийный номер сертификата:

openssl x509 -in /tmp/habr. com. crt -noout -serial

Смотрим, есть ли этот номер в списке CRL:

Если ничего не нашлось, значит сертификат не является отозванным.

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

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

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

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

Механизмы проверки статуса сертификатов

Применяющиеся на практике механизмы проверки статуса сертификатов основаны на списках отозванных сертификатов (certificate revocation list, CRL) и протоколе онлайн-проверки статуса сертификатов (online certificate status protocol, OCSP).

Дальше в качестве примера будем рассматривать сертификат сервера с доменным именем www. example. com, выданный УЦ «Example Certification Authority», схематично изображённый на рисунке:

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

Механизм CRL

УЦ публикуют CRL, в которые вносятся серийные номера отозванных сертификатов, в точках распространения CRL (CRL distribution point, CDP). Адреса (URL) точек распространения CRL, к которым следует обращаться для получения информации о статусе проверяемого сертификата, как правило, указываются в самом сертификате.

Для проверки статуса сертификата, изображённого на рисунке выше, нужно загрузить CRL, доступный по URL ca. example. com/crl, и проверить, содержится ли в нём серийный номер проверяемого сертификата (46:35:AC:5F).

На рисунке приведено схематическое изображение загруженного CRL.

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

В нём сообщается, что УЦ «Example Certification Authority» были отозваны три сертификата c серийными номерами 00:C9:79:0E, 46:35:AC:5F и 50:4E:6F:C7. Проверяемый сертификат является отозванным, поскольку его серийный номер находится в этом списке.

Клиенты получают свежие CRL одним из следующих способов:

  • (условно в «пассивном» или оффлайн режиме) с помощью периодических обновлений. CRL в базе клиента могут обновляться автоматически, например, при обновлении клиентского ПО или в ручную администратором;
  • (в «активном» или онлайн режиме) самостоятельно подгружая их по мере необходимости из CDP.

CRL чаще всего применяются для оффлайн-проверок и являются мало пригодными для систем, нуждающихся в наиболее актуальной информации о статусе сертификата и требующих упомянутых выше онлайн-загрузок CRL, по следующим причинам:

  • CRL избыточны и плохо подходят для частых повторяющихся загрузок. Иногда их размеры приближаются к 1 МБ;
  • CRL не защищены от атак повторного воспроизведения и позволяют «человеку посередине» подсовывать жертве неактуальные CRL, ещё не содержащие информацию о скомпрометированных ключах.

Механизм OCSP

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

Рассмотрим работу этого протокола на примере для сертификата www. example. com (смотри второй рисунок к статье). Для получения информации о статусе сертификата TLS-клиент с помощью OCSP-клиента отправляет запрос OCSP-серверу (OCSP responder) УЦ, указанному в расширении authority information access (AIA) сертификата:

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

В запросе указывается серийный номер проверяемого сертификата (46:35:AC:5F). Также в запросе опционально может быть передан случайный одноразовый код (nonce), предназначенный для защиты ответа OCSP-сервера от атаки повторного воспроизведения. В ответе OCSP-сервера сообщается, что сертификат с серийным номером 46:35:AC:5F был отозван, поскольку соответствующий ему закрытый ключ был скомпрометирован. OCSP-ответ защищён от подделывания и атаки повторного воспроизведения, поскольку подписан доверенным ключом OCSP-сервера и содержит полученный от клиента случайный одноразовый код.

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

  • увеличение времени установки TLS-соединения;
  • раскрытие истории подключений клиента третьей стороне (УЦ).

OCSP stapling

Для решения этих проблем было предложено расширение протокола TLS, позволяющее прикреплять OCSP-ответы к сертификатам (OCSP stapling) и переносящее ответственность за выполнение OCSP на TLS-сервер.

На рисунке изображена схема использования OCSP stapling:

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

Схема описывает следующие шаги:

  • TLS-сервер, выступая в роли OCSP-клиента, собирает информацию о статусе своей цепочки сертификатов, обращаясь к OCSP-серверам соответствующих УЦ;
  • TLS-сервер кэширует полученные OCSP-ответы;
  • При установке TLS-соединения сервер передаёт клиенту свою цепочку сертификатов вместе с соответствующими ей OCSP-ответами.
  • время установки TLS-соединения не увеличивается, поскольку в момент установки соединения OCSP не выполняется ни клиентом, ни сервером;
  • снижается нагрузка на OCSP-серверы УЦ;
  • клиент не раскрывает УЦ используемые им сетевые ресурсы.

«Но где же тут защита от атаки повторного воспроизведения?» — спросите вы. Тут её действительно нет, однако рассматриваемое расширение протокола TLS позволяет клиентам пересылать случайный одноразовый код при установке соединения:

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

Такой вариант использования OCSP stapling не позволяет кэшировать OCSP-ответы на сервере, из-за чего растёт время установки TLS-соединения и увеличивается нагрузка на серверы УЦ.

Следует отметить, что существует две версии OCSP stapling. Первая версия по неясной причине позволяет прикреплять OCSP-ответ только для сертификата самого сервера. При использовании этой версии ответственность за получение информации о статусе остальных сертификатов цепочки лежит на клиенте. Этот недостаток исправлен в новой версии.

Нас хакнули

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

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

Zabbix

Скрипт ssl-check-revoc. sh может проверять сертификаты не только из консоли, он также вполне подходит в качестве чекера для Zabbix, поэтому всю грязную работу по отслеживанию попадания сертификатов в список отзыва можно поручить системе мониторинга.

Заходим в конфиг Zabbix /etc/zabbix/zabbix_server. conf и смотрим, где лежат скрипты для внешних проверок:

Копируем в этот каталог наш скрипт и рестартуем Zabbix:

sudo cp ssl-check-revoc. sh /etc/zabbix/externalscripts/
sudo systemctl restart zabbix-server

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

Также понадобятся два триггера:

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

Не забываем в экшенах (Configuration >> Actions) настроить способ оповещения в случае срабатывания триггеров.

Теперь осталось создать хосты, сертификаты которых будем регулярно проверять (Configuration >> Hosts >> Create host). На вкладке Templates прилинковываем наш темплейт «Template SSL Checking».

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

И всё! Можно спать спокойно: если SSL-сертификат вашего домена по какой-либо причине попадёт в список отозванных, Zabbix сразу же вам сообщит.

Диагностика ошибок ОС Windows при проверке сертификата

Методика выявления причины исключения

Варианты настройки платформы

Начиная с версии 8. 12 платформа «1С:Предприятие» при установке защищенного (SSL/TLS) соединения выполняет проверку сертификата сервера средствами операционной системы Windows. У конечных пользователей может периодически возникать исключение: «Удаленный узел не прошел проверку. Не удалось выполнить проверку отзыва сертификата». Часто появление такого исключения связано с ограничениями доступа в Интернет или прав пользователя, от имени которого запущена служба сервера «1С:Предприятия».

Кратко о протоколе TLS и инфраструктуре открытых ключей X. 509

Современный защищённый Веб стоит на двух китах: протоколе TLS и инфраструктуре открытых ключей X. 509. Для установки защищённого TLS-соединения сервер должен передать клиенту свой открытый ключ. Аутентичность ключа сервера, пересылаемого через незащищённые публичные сети, обеспечивается цепочкой сертификатов открытых ключей инфраструктуры X. 509.

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

Удостоверяющий центр (УЦ, certification authority, CA) может отозвать подписанный (изданный) им ранее сертификат, например, в случае компрометации закрытого ключа, соответствующего этому сертификату. Поэтому, чтобы исключить возможность подключения к «человеку посередине», при установке TLS-соединения клиент должен не только проверять корректность подписей всей предоставленной сервером цепочки сертификатов, но и проверять статус предоставленных ему сертификатов (сертификат действителен или отозван).

Полный сбой

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

Читать также:  Как подать заявление на сертификат дополнительного образования через госуслуги

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

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

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

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.

Автоматизация

Проверять SSL-сертификаты на предмет отзыва вручную не всегда удобно, поэтому процесс проверки можно автоматизировать.

Для этого берём с Github готовый скрипт ssl-check-revoc. sh, который осуществляет проверку сертификатов методом CRL:

Далее делаем скрипт исполняемым:

chmod a+x ssl-check-revoc

Теперь можно проверять как уже установленные сертификаты для домена, так и сохранённые локально в файлы (опция -f):

/ssl-check-revoc. sh habr. com -v

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

Про проблему отозванных сертификатов и «Кошмар скомпрометированных ключей» мы говорили на «очной ставке» NeoQUEST-2016. У нас даже есть отличное видео, в котором автор статьи рассказывает про отозванные сертификаты:

Пока у нас активно ведется подготовка к очередной «очной ставке» NeoQUEST-2017, которая пройдет в Питере 29 июня (и на которую мы ждём ВСЕХ желающих!), рассказываем интересную новость:

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

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

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

Сертификат для pornhub. com валидный?

Варианты настройки платформы

Платформа «1С:Предприятие 8» поддерживает следующие варианты настройки проверки отзыва сертификата:

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

Внимание! Такая настройка снижает уровень доверия к внешним ресурсам! В случае применения данной настройки ответственность возлагается на пользователя.

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

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

OCSP Must-Staple

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

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

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

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

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

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

Заключение

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

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

Отзыв

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

Не удалось проверить сертификат в списке отозванных соответствующий сервер в состоянии offline

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

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

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

scotthelme. IN CAA 0 issue «letsencrypt. org»

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *