Ошибка чтения файла сертификата запроса на сертификат или crl

Обновлено: 04.07.2024

Возможно, вы видели файлы цифровых сертификатов с различными расширениями имен файлов, такими как .crt , .cer , .pem или .der . Эти расширения обычно соответствуют двум основным схемам кодирования сертификатов и ключей X.509: PEM (Base64 ASCII) и DER (двоичный). Однако есть некоторые совпадения и используются другие расширения, поэтому вы не всегда можете определить, с каким файлом вы работаете, просто взглянув на имя файла; вам может потребоваться открыть его в текстовом редакторе и посмотреть сами.

Что такое OpenSSL?
OpenSSL - очень полезный набор инструментов командной строки с открытым исходным кодом для работы с X.509 сертификаты, запросы на подпись сертификатов (CSRs) и криптографические ключи. Если вы используете вариант UNIX, такой как Linux или macOS, OpenSSL, вероятно, уже установлен на вашем компьютере. Если вы хотите использовать OpenSSL в Windows, вы можете включить Подсистема Linux в Windows 10 или установить Cygwin.

Расширения имени файла PEM

Как выглядит сертификат PEM?

Общие преобразования PEM

В приведенных ниже командах OpenSSL замените имена файлов ВСЕМИ ЗАГЛАВНЫМИ буквами фактическими путями и именами файлов, с которыми вы работаете.

Просмотр содержимого файла сертификата PEM

Конвертировать сертификат PEM в DER

DER (отличительные правила кодирования) это двоичная кодировка для X.509 сертификаты и закрытые ключи. В отличие от PEM, файлы в кодировке DER не содержат текстовых операторов, таких как -----BEGIN CERTIFICATE----- , Файлы DER чаще всего встречаются в контексте Java.

Расширения имени файла DER

DER-кодированные файлы обычно находятся с расширениями .der и .cer .

Как выглядит DER-кодированный сертификат?

Общие преобразования DER

Просмотр содержимого файла сертификата в кодировке DER

Конвертировать DER-кодированный сертификат в PEM

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

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

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

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

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

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

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

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

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

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

Механизм CRL

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

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

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

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

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

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

Механизм OCSP

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

В запросе указывается серийный номер проверяемого сертификата (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:

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

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

время установки TLS-соединения не увеличивается, поскольку в момент установки соединения OCSP не выполняется ни клиентом, ни сервером;
снижается нагрузка на OCSP-серверы УЦ;
клиент не раскрывает УЦ используемые им сетевые ресурсы.

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

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

Продолжение следует… А пока — отличная новость!

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

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

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

Эта статья помогает устранить ошибку сертификата ADFS 2.0 при попытке построения цепочки сертификатов.

Применяется к: Windows Server 2012 R2
Исходный номер КБ: 3044974

Сводка

Большинство проблем Active Directory Federated Services (AD FS) 2.0 относятся к одной из следующих основных категорий. В этой статье содержатся пошаговые инструкции по устранению неполадок с сертификатами.

Симптомы

Эта проблема начинается после изменения или замены сертификата AD FS.

Программа перестает принимать маркер, выданный AD FS.

AD FS возвращает одну из следующих ошибок при приеме подписанного запроса или ответа или при попытках шифровать маркер, который должен быть выдан в приложение Rely Party:

Event ID 316
Ошибка произошла во время попытки построить цепочку сертификатов для доверяемой стороны сертификата доверия.
Event ID 315
Ошибка произошла при попытке построения цепочки сертификатов для сертификата доверия поставщика утверждений.
Event ID 317
Ошибка произошла при попытке построить цепочку сертификатов для доверяемой стороне сертификата шифрования доверия.

Следующие удостоверения событий, связанных с сертификатом, регистрируются в журнале событий AD FS:

ID события 133
Описание. При обработке конфигурации службы Федерации было установлено, что элемент serviceIdentityToken имеет недействительные данные. Закрытый ключ для настроенного сертификата невозможно получить. Ниже гласят значения сертификата:Element: serviceIdentityToken
ID события 385
AD FS 2.0 обнаружил, что один или несколько сертификатов в базе данных конфигурации AD FS 2.0 должны обновляться вручную.
Event ID 381
Ошибка произошла при попытке построения цепочки сертификатов для сертификата конфигурации.
ID события 102
Произошла ошибка включения конечных точек службы Федерации.
Дополнительные данные
Сведения об исключениях:
System.ArgumentNullException: Значение не может быть null.
Имя параметра: сертификат
ID события: 387
AD FS 2.0 обнаружил, что один или несколько сертификатов, указанных в службе Федерации, недоступны для учетной записи службы, используемой службой AD FS 2.0 Windows.
Действие пользователя. Убедитесь, что учетная запись службы AD FS имеет разрешения на чтение на закрытых ключах сертификата.
Дополнительные сведения:
Сертификат подписи маркеров с отпечатком пальца "xxxxxxx"

Решение

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

Шаг 1. Проверка частных ключей

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

Где найти сертификаты

Сертификаты связи службы:

На сервере AD FS нажмите кнопку Начните, нажмите кнопку Выполнить, введите MMC.exe и нажмите кнопку Ввод.

В диалоговом окне Add/Remove Snap-in нажмите кнопку ОК.

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

Чтобы просмотреть свойства сертификата service Communications, разойдите сертификат (локальный компьютер), развяжь личный компьютер и нажмите кнопку Сертификаты.

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

Если сертификаты являются самозаверяемыми сертификатами, которые по умолчанию добавляются сервером ADFS, logon интерактивно на сервере ADFS с помощью учетной записи службы ADFS и проверьте хранилище сертификатов пользователя (certmgr.msc).
Если сертификаты от сертификата (CA), настроенные администраторами ADFS после отключения AutoCertificateRollover, то вы должны иметь возможность найти его в хранилище сертификатов сервера ADFS.

Шаг 2. Убедитесь, что сертификаты не используют закрытый ключ Cryptographic Next Generation (CNG).

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

Дополнительные сведения см. в справке Как определить, используется ли сертификат с помощью ключа CAPI1 или CNG.

Шаг 3. Проверка привязки SSL сертификатов связи Службы в IIS к порту 443

Проверка и исправление

Запустите диспетчер IIS. Чтобы сделать это, нажмите кнопку Начните, нажмите административные средства, а затем нажмите кнопку службы IIS (IIS) Manager.

Щелкните имя сервера, а затем разложите папку Sites.

Найдите веб-сайт (обычно он называется "Веб-сайт по умолчанию"), а затем выберите его.

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

Способ проверки

Откройте управление AD FS 2.0.

Расширение службы, щелкните Сертификат, щелкните правой кнопкой мыши сертификат связи службы, а затем нажмите кнопку Просмотр сертификата.

В области сведений щелкните Скопируйте файл и сохраните файл как Filename.cer.

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

Откройте файл вывода, созданный выше "cert_verification.txt".

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

Проверка отзыва сертификата Leaf прошла
CertUtil: проверка успешно выполненной команды.

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

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

Сбор сетевого следа может помочь, если какой-либо из путей AIA или CDP или OCSP недоступен.

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

Шаг 5. Убедитесь, что учетные записи службЫ ADFS получили разрешение на чтение для закрытого ключа сертификатов ADFS

Проверка разрешения на чтение

На сервере AD FS нажмите кнопку Начните, нажмите кнопку Запустить, введите MMC.exe и нажмите кнопку Ввод.

В диалоговом окне Add/Remove Snap-in нажмите кнопку ОК.

В окне Корневого консоли щелкните Сертификаты (Локальный компьютер), чтобы просмотреть магазины сертификатов компьютера.

Щелкните правой кнопкой мыши службу AD FS, указать все задачи, а затем нажмите кнопку Управление закрытыми ключами.

Проверьте, есть ли у учетной записи AD FS разрешение на чтение.

Шаг 6. Проверьте, включена ли функция ADFS AutoCertificateRollover для сертификатов подписывания маркеров и расшифровки маркеров

Проверка функции ADFS AutoCertificateRollover

В случае отключения AutoCertificateRollover сертификаты подписывания маркеров и расшифровки маркеров не будут возобновляться автоматически. Перед истечении срока действия этих сертификатов убедитесь, что в конфигурацию AD FS добавляется новый сертификат. В противном случае доверчивый участник не будет доверять маркеру, который выдан сервером AD FS.
Если включен AutoCertificateRollover, новые сертификаты для подписания маркеров и расшифровки маркеров будут созданы за 20 дней до истечения срока действия старых сертификатов. Новые сертификаты получат статус Primary через пять дней после их получения. После получения нового набора сертификатов убедитесь, что те же сведения обновляются в доверчивых участниках и доверяющих поставщиках утверждений.

Дополнительные сведения о функции AD FS AutoCertificateRollover см. в следующих темах TechNet:

Шаг 7. Добавление имени службы федерации в сертификат SAN

Если в сертификате включен атрибут SAN (Subject Alternative Name), имя службы федерации также должно быть добавлено в SAN сертификата вместе с другими именами. Дополнительные сведения см. в справке ОАО "Требования к сертификатам SSL".

Шаг 8. Проверка разрешений учетной записи службы для контейнера обмена сертификатами <GUID> (CN= ,CN=ADFS,CN=Microsoft,CN=Program Data,DC= <Domain> ,DC=) <COM>

Проверка и исправление разрешения учетной записи службы

На контроллере домена (DC) откройте Adsiedit.msc.

Подключение контекст именования по умолчанию.

Найдите CN= <GUID> ,CN=ADFS,CN=Microsoft,CN=Program Data,DC= <Domain> ,DC= <COM>.

В этом имени контейнера параметры в скобках представляют фактические значения. Примером GUID является "62b8a5cb-5d16-4b13-b616-06caea706ada".

Щелкните правой кнопкой мыши GUID и нажмите кнопку Свойства. Если имеется несколько GUID, выполните следующие действия:

Начните Windows PowerShell на сервере, на который работает служба AD FS.

Выполните следующую команду:

Найдите GUID запущенной службы AD FS в certificateShareingContainer.

Убедитесь, что у учетной записи службы ADFS есть разрешения На чтение, запись и "Создание всех детских объектов", предоставленные этому объекту и всем потомковой объект.

Шаг 9. Проверка поставщиков утверждений и лиц, которые полагаются на обновления сертификатов

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

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

Шаг 10. Проверка подписанного запроса и ответа от поставщика утверждений или стороне, которая полагается

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

Сценарии

AD FS 2.0 получает подписанный samL-P запрос, который отправляется стороной, которая полагается.

Требующий регистрации запросов на вход является настраиваемым вариантом. Чтобы установить это требование для доверяющих сторон, используйте параметр RequireSignedSamlRequests вместе с Set-ADFSRelyingPartyTrust.

AD FS 2.0 получает подписанный samL-запрос на выход из полагаться стороны. В этом сценарии необходимо подписать запрос на регистрацию.

AD FS 2.0 получает запрос на регистрацию от поставщика утверждений и шифрует запрос на регистрацию для сторон, которые полагаются. В этом случае поставщик утверждений инициирует выход.

AD FS 2.0 выдает зашифрованный маркер для полагаюящейся стороны.

AD FS 2.0 получает выданный маркер от поставщика утверждений.

AD FS 2.0 получает подписанный запрос на регистрацию SAML от поставщика утверждений. В этом сценарии необходимо подписать запрос на регистрацию.

Что нужно проверить, чтобы устранить проблему

Убедитесь, что сертификат доверия поставщика утверждений действителен и не отменяется.

Убедитесь, что AD FS 2.0 может получить доступ к списку отзыва сертификата, если в параметре отзыва не указано "нет" или "только кэш".

Вы можете использовать Windows PowerShell для AD FS 2.0 для настройки следующих параметров отзыва:

Параметр SigningCertificateRevocationCheck для Set-ADFSClaimsProviderTrust или Set-ADFSRelyingPartyTrust-
Параметр EncryptionCertificateRevocationCheck Set-ADFSRelyingPartyTrust или Set-ADFSClaimsProviderTrust-

Дополнительные сведения см. в справке о проблемах с сертификатом устранения неполадок с AD FS 2.0.

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

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

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

В окне Просмотр событий в списке Журналы приложений и служб выберите Microsoft – Windows – CAPI 2 – Operational .

В списке Действия выберите Включить журнал .

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

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

В данном разделе полезно знать UserID . Этот параметр содержит сведения о пользователе, от имени которого была выполнена операция.

В случае из примера причина невозможности проверки отзыва сертификата сервера - в том, что доступ к http://crl4.digicert.com/DigiCertGlobalRootCA.crl есть только у доменных пользователей, а сервер "1С:Предприятия" запущен как сервис от имени локального пользователя.

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

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

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

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

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

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

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

IgnoreServerCertificatesChainRevocationSoftFail=true

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

Читайте также: