Запрашивать у ocsp-серверов подтверждение текущего статуса сертификатов – Новости, справки, информация, советы

Что значит данная ошибка?

В переводе с английского языка текст данной ошибки звучит как «Ошибка безопасности. Неверно подписанный OCSP сертификат». Аналогичными ошибками с сертификатом SSL являются  и ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

Напомню читателю, что аббревиатура OCSP является сокращением от «Online Certificate Status Protocol» (в переводе – «Протокол статуса онлайн-сертификата»). Данный протокол предназначен для проверки статуса сертификата на предмет его отозванности, когда выданный ранее сертификат для какого-либо сайта, удостоверяющий безопасность работы с данным сайтом, может быть отозван у указанного сайта по каким-либо причинам (например, Центр сертификации посчитал работу с таким сайтом не безопасной).

Таким образом, браузер, переходя на данный сайт с «отозванным» сертификатом, может выдать вам ошибку и сообщение «sec_error_ocsp_invalid_signing_cert».

Какие ещё могут быть причины появления подобного сообщения об ошибке? Я бы отметил следующее:

• Случайный сбой в работе компьютера;
• Некорректные системные дата и время;
• Временные неполадки на нужном сетевом ресурсе.

Certutil

Всем известная утилита Certutil.exe, которая поставляется не только с серверными операционными системами, но и с клиентскими тоже. К слову сказать, по сложности синтаксиса и богатством функционала с certutil.exe тягаться может разве что netsh.exe :-).

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

certutil –url pathcertificate.cer

и откроется следующее окно:

Я на сервере CA отозвал один сертификат и решил проверить, что мне на это скажет OCSP. Для этого в правой части выбираем, что хотим проверить статус сертификата с использованием только OCSP и нажимаем кнопку Retrieve. И в верхнем окне мы видим адрес OCSP сервера и статус проверямого сертификата.

Кстати говоря, я себе сделал контекстное меню для .CER и .DER файлов, по которому вызывается эта утилита и можно будет сразу не отходя от кассы проверить сертификат или CDP/AIA того CA, который издал этот сертификат. Вот как выглядит .reg файл:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOTCERFileshellCheck Certificate Revocation Status]

[HKEY_CLASSES_ROOTCERFileshellCheck Certificate Revocation Statuscommand]
@=”certutil -url “%1″”

Ocsp stapling

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

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

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

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

Таким образом:

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

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

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

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

Pkiview.msc

Это стандартная MMC оснастка, которая устанавливается в систему с установкой роли Active Directory Certificates Services (для Windows Server 2008/R2) или с установкой Resource Kit (для Windows Server 2003). Что примечательно, ничего делать в этой оснастке не надо, достаточно её просто запустить и вы всё сразу увидите:

Данная оснастка собирает полную PKI иерархию в лесу (в моём случае это двухуровневая иерархия CA), считывает с них CDP и AIA списки и проверяет доступность сертификатов CA и списков CRL. Я специально удалил с сервера Base CRL список. И об этом мы бы узнали, скорее всего, только когда клиент не смог бы подключиться к SSL/TLS/IPSec ресурсу.

Если внутри сети особого профита OCSP не получите, то для интернета он будет как нельзя кстати. Ну и для клиентов из интернета ваши LDAP пути для CRL никакого интереса не будут представлять. Т.е. мы имем классические CRL’ы и OCSP респондер. Собственно, статус Ok нам говорит, что с ним всё в порядке.

Вы можете прямо из этой консоли выбрать правой кнопкой каждый пункт и посмотреть фактическое содержимое каждого CRL списка или CRT файла (CRT файлы в AIA требуются нам для построения цепочки сертификатов, т.н. certificate chain). Однако в отношении с OCSP мы видим только общую работоспособность респондера.

Так же общую работоспособность можно проверить через оснастку Online Responder Mangement на каждом OCSP сервере. Но это всё на стороне сервера. А вот продиагностировать клиента (убедиться, что клиент работает в первую очередь с OCSP, а не с классическими CRL списками) здесь не получится и этому будет посвящена следующая часть этой статьи.

Базовая реализация pki

1. У Алисы и Боба есть сертификаты открытого ключа, выданные Кэрол, центром сертификации (CA).
2. Алиса желает выполнить транзакцию с Бобом и отправляет ему свой сертификат открытого ключа.
3. Боб, обеспокоенный тем, что закрытый ключ Алисы мог быть скомпрометирован, создает «запрос OCSP», содержащий серийный номер сертификата Алисы, и отправляет его Кэрол.
4. Ответчик Кэрол OCSP считывает серийный номер сертификата из запроса Боба. Ответчик OCSP использует серийный номер сертификата для поиска статуса отзыва сертификата Алисы. Ответчик OCSP просматривает базу данных CA, которую поддерживает Кэрол. В этом сценарии база данных CA Кэрол – единственное надежное место, где будет записана компрометация сертификата Алисы.
5. Ответчик OCSP Кэрол подтверждает, что сертификат Алисы все еще в порядке, и возвращает Бобу подписанный успешный «ответ OCSP».
6. Боб криптографически проверяет подписанный ответ Кэрол. Боб сохранил открытый ключ Кэрол незадолго до этой транзакции. Боб использует открытый ключ Кэрол, чтобы проверить ответ Кэрол.
7. Боб завершает транзакцию с Алисой.

Детали протокола

Ответчик OCSP (сервер, который обычно запускается издателем сертификата) может вернуть подписанный ответ, означающий, что сертификат, указанный в запросе, является «хорошим», «отозванным» или «неизвестным». Если он не может обработать запрос, он может вернуть код ошибки.

Формат запроса OCSP поддерживает дополнительные расширения. Это дает возможность обширной настройки конкретной схемы PKI.

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

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

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

У респондента OCSP может быть запрошена информация об отзыве серверами проверки делегированного пути (DPV). OCSP сам по себе не выполняет DPV предоставленных сертификатов.

Ключ, которым подписывается ответ, не обязательно должен быть тем же ключом, которым подписан сертификат. Издатель сертификата может делегировать другой орган в качестве ответчика OCSP. В этом случае сертификат респондента (тот, который используется для подписи ответа) должен быть выпущен эмитентом соответствующего сертификата и должен включать определенное расширение, которое отмечает его как подписывающий орган OCSP (точнее, расширенный расширение использования ключа с OID {iso (1) идентифицированная организация (3) dod (6) Интернет (1) безопасность (5) механизмы (5) pkix (7) keyPurpose (3) ocspSigning (9)})

Документация

Как избавиться от проблемы

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

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

Если же вы не имеете желания ждать, тогда отключите уведомления OCSP, для чего в браузере Mozilla введите в адресной строке:

about:config — и нажмите на «Enter». При необходимости кликните на «Я принимаю на себя риск», найдите в списке настроек «», и, дважды кликнув на данную строку, установите значение данного показателя в «false». После этого указанная ошибка не будет отображаться, и вы сможете выполнить вход на ранее недоступный ресурс.

Механизм crl

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

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

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

В нём сообщается, что УЦ «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, ещё не содержащие информацию о скомпрометированных ключах.

Настройка шаблона ca

Итак, для начала нам потребуется установленный в сети Certification Authority под управлением Windows Server 2008 (любой редакции, кроме Web). По умолчанию с добавлением роли  AD CS добавляется и служба Online Respnder. Для этого так же потребуется установить службы IIS, о чём мастер вам сообщит и предложит сделать.

Данный шаблон характеризуется следующими свойствами:

• срок действия сертификата составляет 2 недели
• на вкалдке Request Handlings добавлено право чтения приватного ключа для службы Network Service, поскольку служба OCSP работает от лица Network Service, а не LocalSystem (для LocalSystem отдельных разрешений не требуется)
• шаблон не содержит CDP и AIA расширений
• шаблон помечен как неподлежащий для проверки на отзыв (см. fig.1)

На вкладке Security необходимо для учётной записи компьютера, на котором размещён OCSP выдать право Allow Read и Allow Enroll. Это единственное изменение, которое необходимо выполнить для шаблона. Теперь нужно открыть оснастку Certificate Authority и добавить этот шаблон для выдачи:

правой кнопкой на Certificate Templates –> New –> Certificate Template to Issue –> OSCP Response Signing. Далее нужно создать оснастку Certificates для учётной записи компьютера и запросить сертификат на основе этого шаблона с компьютера, где установлен OCSP Responder.

После запроса сертификата не стоит закрывать оснастку Certificates, а выбрать новый сертификат и в All Tasks выбрать Manage Privete keys. В открывшемся окне Permissions выдайте право Read для учётной записи Network Service:

Подготовка конфигурационных файлов

Необходимо создать конфигурационный файл для OpenSSL. Создадим файл /root/ca/openssl.cnf, скопируем в него следующее содержимое root-config.txt.Раздел [ca] является обязательным. Здесь мы говорим OpenSSL использовать параметры из раздела [CA_default]:

[ ca ]
#man ca
default_ca = CA_default

Раздел [CA_default] содержит ряд значений по умолчанию:

[ CA_default ]
# Directory and file locations.
dir               = /root/ca
certs             = $dir/certs
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# The root key and root certificate.  
 private_key       = $dir/private/ca.key.pem  
 certificate       = $dir/certs/ca.cert.pem

# For certificate revocation lists.  
 crlnumber         = $dir/crlnumber  
 crl               = $dir/crl/ca.crl.pem  
 crl_extensions    = crl_ext  
 default_crl_days  = 30

# SHA-1 is deprecated, so use SHA-2 instead.  
 default_md        = sha256

name_opt          = ca_default  
 cert_opt          = ca_default  
 default_days      = 375  
 preserve          = no  
 policy            = policy_strict

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

[ policy_strict ]
# The root CA should only sign intermediate certificates that match.
# See the POLICY FORMAT section of man ca.
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

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

[ policy_loose ]
# Allow the intermediate CA to sign a more diverse range of certificates.
# See the POLICY FORMAT section of the `ca` man page.
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

Параметры из секции [ req ] применяются когда создаются сертификаты или запросы на подписывание сертификатов.

[ req ]
# Options for the `req` tool (`man req`).
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only

# SHA-1 is deprecated, so use SHA-2 instead.  
default_md          = sha256

# Extension to add when the -x509 option is used.  
x509_extensions     = v3_ca

Секция [ req_distinguished_name ] определяет информацию, которая обычно требуется при запросе на подписывание сертификата. Можно указать некоторые значения по умолчанию.

Поддержка браузера

Информация OCSP в Firefox 89

OCSP широко поддерживается большинством основных браузеров:

Однако Google Chrome – особый случай. Google отключил проверки OCSP по умолчанию в 2021 году, ссылаясь на проблемы с задержкой и конфиденциальностью, и вместо этого использует собственный механизм обновления для отправки отозванных сертификатов в браузер.

Проверка корневого сертификата

# openssl x509 -noout -text -in certs/ca.cert.pem

Вывод показывает:

• Используемый алгоритм Signature Algorithm
• Даты периода действия сертификата Validity
• Длину публичного ключа Public-Key
• Эмитент сертификата Issuer, который является объектом, который подписал сертификат
• Предмет Subject, который относится к самому сертификату.

Эмитент (Issuer) и предмет (Subject) идентичны для самоподписанных сертификатов. Все корневые сертификаты являются самоподписанными.

Signature Algorithm: sha256WithRSAEncryption
Issuer: C=GB, ST=England,
O=Alice Ltd, OU=Alice Ltd Certificate Authority,
CN=Alice Ltd Root CA
Validity
Not Before: Apr 11 12:22:58 2021 GMT
Not After : Apr  6 12:22:58 2035 GMT
Subject: C=GB, ST=England,
O=Alice Ltd, OU=Alice Ltd Certificate Authority,
CN=Alice Ltd Root CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)

Вывод также показывает расширения X509v3, т.к. было применено расширение v3_ca, и опции из секции [ v3_ca ] отражены в выводе.

X509v3 extensions:
X509v3 Subject Key Identifier:
38:58:29:2F:6B:57:79:4F:39:FD:32:35:60:74:92:60:6E:E8:2A:31
X509v3 Authority Key Identifier:
keyid:38:58:29:2F:6B:57:79:4F:39:FD:32:35:60:74:92:60:6E:E8:2A:31
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign

Создание корневого сертификата

Для создания корневого сертификата (ca.cert.pem) используется корневой ключ (ca.key.pem). Следует указать длинный срок годности сертификата, например, 20 лет. После того, как истечет корневой сертификат, все сертификаты, подписанные центром сертификации становятся недействительными.

# cd /root/ca
# openssl req -config openssl.cnf 
-key private/ca.key.pem 
-new -x509 -days 7300 -sha256 -extensions v3_ca 
-out certs/ca.cert.pem
Enter pass phrase for ca.key.pem: secretpassword
You are about to be asked to enter information that will be incorporated
into your certificate request.
-----
Country Name (2 letter code) [XX]:GB
State or Province Name []:England
Locality Name []:
Organization Name []:Alice Ltd
Organizational Unit Name []:Alice Ltd Certificate Authority
Common Name []:Alice Ltd Root CA
Email Address []:
# chmod 444 certs/ca.cert.pem

Создание корневой пары ключей

Выступая в качестве центра сертификации (CA) означает иметь дело с криптографическими парами приватных (частных) ключей и публичными сертификатами. Самой первой криптографической парой создадим корневую пару. Она состоит из корневого ключа (ca.key.pem) и корневого сертификата (ca.cert.pem). Эта пара образует идентичность нашего центра сертификации.

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

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

Создание промежуточного сертификата

Используя промежуточный ключ создадим запрос на подписывание сертификата (CSR — certificate signing request). Сведения должны, как правило, соответствовать корневому центру сертификации. Общие имена (Common Name), однако, должны быть разными. И убедитесь, что используете конфигурационный файл промежуточного центра сертификаци (intermediate/openssl.cnf).

# cd /root/ca
# openssl req -config intermediate/openssl.cnf -new -sha256 
-key intermediate/private/intermediate.key.pem 
-out intermediate/csr/intermediate.csr.pem
Enter pass phrase for intermediate.key.pem: secretpassword
You are about to be asked to enter information that will be incorporated
into your certificate request.
-----
Country Name (2 letter code) [XX]:GB
State or Province Name []:England
Locality Name []:
Organization Name []:Alice Ltd
Organizational Unit Name []:Alice Ltd Certificate Authority
Common Name []:Alice Ltd Intermediate CA
Email Address []:

Чтобы создать промежуточный сертификат используем корневой центр сертификации с расширением v3_intermediate_ca для подписывания промежуточного запроса. Промежуточный сертификат должен быть действителен на меньший период, чем корневой. К примеру, на 10 лет. В этот раз следует использовать конфигурационный файл корневого центра сертификации (/root/ca/openssl.cnf).

# cd /root/ca
# openssl ca -config openssl.cnf -extensions v3_intermediate_ca 
-days 3650 -notext -md sha256 
-in intermediate/csr/intermediate.csr.pem 
-out intermediate/certs/intermediate.cert.pem
Enter pass phrase for ca.key.pem: secretpassword
Sign the certificate? [y/n]: y
# chmod 444 intermediate/certs/intermediate.cert.pem

Для хранения базы данных сертификатов, выданных утилитой ca OpenSSL, используется файл index.txt. Не следует удалять или править вручную этот файл. Сейчас он должен содержать одну строку, которая относится к промежуточному сертификату.

V 250408122707Z 1000 unknown … /CN=Alice Ltd Intermediate CA