Требования к конфигурации

Meaning of Certificate validation failure?

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

Причины ошибки сертификата:

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

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

Реализации

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

Сервер

• Boulder, CA и OCSP ответчик разработан и используется Let’s Encrypt (Go)
• DogTag, Центр сертификации с открытым исходным кодом CA, CRL и OCSP ответчик.
• Ejbca, CA и OCSP ответчик (Java)
• OpenXPKI, CA и OCSP как расширение в конфигурации OpenXPKI.

Проприетарное программное обеспечение:

Службы сертификации CA и OCSP-ответчик, входящие в состав Windows Server.

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

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

Настройка OCSP stapling на Nginx

Отредактируйте файл виртуального хоста и внесите в раздел server {} следующий блок кода:

Если, чтобы настроить SSL-сертификаты на Nginx, вы следовали данной статье, то виртуальный хост будет выглядеть так:

Теперь нужно убедиться, что все работает должным образом; для этого нужно протестировать конфигурации:

Перезапустите nginx:

Затем откройте веб-сайт через IE (в Vista и т.п.) или Firefox 26 + и проверьте журнал ошибок.

Если в файле, указанном в ssl_trusted_certificate, отсутствует сертификат, появится ошибка:

Если же ошибок не обнаружено, переходите к следующему разделу руководства.

OpenSSL: Manually verify a certificate against an OCSP

Published: 07-04-2014 | Author: Remy van Elst | Text only version of this article

Table of Contents

This article shows you how to manually verfify a certificate against an OCSP
server. OCSP stands for the Online Certificate Status Protocol and is one way to
validate a certificate status. It is an alternative to the CRL, certificate
revocation list.

Compared to CRL’s:

• Since an OCSP response contains less information than a typical CRL (certificate revocation list), OCSP can use networks and client resources more efficiently.
• Using OCSP, clients do not need to parse CRLs themselves, saving client-side complexity. However, this is balanced by the practical need to maintain a cache. In practice, such considerations are of little consequence, since most applications rely on third-party libraries for all X.509 functions.
• OCSP discloses to the responder that a particular network host used a particular certificate at a particular time. OCSP does not mandate encryption, so other parties may intercept this information.

You can read more about the OCSP on wikipedia

If you want to verify a certificate against a CRL manually you can read my
article on that here.

We will be using OpenSSL in this article. I’m using the following version:

Get a certificate with an OCSP

First we will need a certificate from a website. I’ll be using Wikipedia as an
example here. We can retreive this with the following openssl command:

Save this output to a file, for example, wikipedia.pem:

Now, check if this certificate has an OCSP URI:

If it does not give any output, the certificate has no OCSP URI. You cannot
valdiate it against an OCSP.

Getting the certificate chain

It is required to send the certificate chain along with the certificate you want
to validate. So, we need to get the certificate chain for our domain,
wikipedia.org. Using the option with , we can see
all the certificates, including the chain:

Results in a boatload of output, but what we are interested in is the following:

As you can see, this is number 1. Number 0 is the certificate for Wikipedia, we
already have that. If your site has more certificates in its chain, you will see
more here. Save them all, in the order OpenSSL sends them (as in, first the one
which directly issued your server certificate, then the one that issues that
certificate and so on, with the root or most-root at the end of the file) to a
file, named .

Sending the OCSP request

We now have all the data we need to do an OCSP request. Using the following
Openssl command we can send an OCSP request and only get the text output:

Results in:

If you want to have a more summarized output, leave out the option. I
most of the time include it to find out problems with an OCSP.

This is how a good certificate status looks:

Revoked certificate

If you have a revoked certificate, you can also test it the same way as stated
above. The response looks like this:

You can test this using the certificate and chain on the Verisign revoked
certificate test page:

Other errors

If we send this request to another OCSP, one who did not issued this
certificate, we should receive an unauthorized error:

The option here shows more information:

Some OCSP’s are configured differently and give out this error:

If we do include the option here we can see that a response is sent,
however, that it has no data in it:

Other OCSP’s give out the «unknown» status:

The options shows us more:

Sources

• https://www.openssl.org/docs/apps/s_client.html
• https://www.openssl.org/docs/apps/ocsp.html
• https://en.wikipedia.org/wiki/Online Certificate Status_Protocol

Tags: articles
, certificate
, crl
, ocsp
, shell
, ssl
, tls

Вспомогательные вопросы при работе с OCSP

Действия, нужные со стороны сервера и клиентов – примерно понятны. Что пригодится админу?

Как определить время кэширования OCSP-ответа

Вы можете вручную посмотреть прикреплённый OCSP-ответ и увидеть срок годности. Например так:

Параметры команды достаточно тривиальны – посылается запрос на , используется TLS 1.2, отправка в самом начале нужна, чтобы соединение после получения информации сразу же прервалось, а ‘ом мы просто выводим только нужный кусок из рулона текста.

Надо ли предварительно подготавливать OCSP-ответы

В различных источниках бытует мнение о том, что OCSP – плохая технология, потому что самый первый клиент будет подключаться, а OCSP-ответа нет. Поэтому предлагаются схемы типа “давайте после старта веб-сервиса сами к себе обратимся, сымитировав самого первого клиента, чтобы этот вопрос был снят”.

Идея неплохая, но есть мнение, что проще ускорить процесс кэширования OCSP-ответа, а также грамотно настроить тайм-ауты. Тайм-ауты OCSP – это время, за которое веб-сервер, получив запрос от клиента на OCSP Stapling, должен сбегать к OCSP responder’у и принести этот ответ. Соответственно, вопросы быстродействия сети, скорости разрешения DNS-имён и поиска рабочего OCSP responder’а из нескольких – весьма актуальны. Не бойтесь выставить тайм-ауты на 10 или даже 15 секунд – это не приведёт к замедлению работы с клиентом, это приведёт к снижению до нуля числа отбоев по причине “извини, братишка, не успел OCSP тебе передать – вот тебе TLS-ответ формата “уж как могу””.

В nginx существует возможность брать OCSP Stapling из файла – это делается через команду и предполагает некий фоновый скрипт, который регулярно (это несложно, зная срок годности OCSP-ответа) ходит наружу и перезаписывает этот файл в случае получения удачного ответа. Применять ли этот метод – решать вам; в больших развёртываниях зачастую проще сделать отдельные системы, прекэширующие все OCSP-ответы для нужных сертификатов и очень быстро доступные для линейки проксирующих и выполняющих SSL termination серверов.

Теперь чуток про безопасность OCSP.

CRL and OCSP URLs in the Client Certificate

When a CA signs a certificate, it will normally encode the CRL and OCSP location/s into the certificate using “CRL Distribution Point” and “Authority Information Access” extensions respectively.

For that, you can configure an external validation.cnf file as follows with the necessary openSSL extension configurations for CRL URLs and OCSP URLs (i.e. Please note that “http://pki.google.com/GIAG2.crl” and “http://clients1.google.com/ocsp” are URLs of a well-known CA. You need to get your own URLs referring to the “Testing CRL & OCSP validation with X509 Authenticator” section of this blog).

crlDistributionPoints = URI:http://pki.google.com/GIAG2.crlauthorityInfoAccess = OCSP;URI: http://clients1.google.com/ocsp

Or you can include the above property under x509_extensions in /usr/lib/ssl/openssl.cnf.

Конфигурационный скрипт для Certification Authority

До установки роли AD CS необходимо создать конфигурационный скрипт, который выполнит послеустановочную настройку CA на основании выбранных параметров. Ниже следует пример такого скрипта:

CAScript.cmd

:: CDPcertutil -setreg CA\CRLPublicationURLs «65:C:\Windows\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n79:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n6:http://%%1/CertEnroll/%%3%%8%%9.crl\n0:file://%%1/CertEnroll/%%3%%8%%9.crl»:: AIAcertutil -setreg CA\CACertPublicationURLs «1:C:\Windows\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n3:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n2:http://%%1/CertEnroll/%%1_%%3%%4.crt\n0:file://%%1/CertEnroll/%%1_%%3%%4.crt\n32:http://%%1/ocsp»:: В случае использования роли OCSP , при обновлении сертификата CA могут быть:: проблемы с проверкой подлинности сертификатов. Чтобы устранить эту проблему:: используется:certutil –setreg CA\UseDefinedCACertInRequest 1:: Включаем наследование Issuer Statement в издаваемых сертификатахcertutil -setreg Policy\EnableRequestExtensionList +»2.5.29.32″:: Задаём срок действия издаваемых сертификатов::certutil -setreg CA\ValidityPeriodUnits 2::certutil -setreg CA\ValidityPeriod «Years»:: Задаём параметры публикации CRL ::certutil -setreg CA\CRLPeriodUnits 1::certutil -setreg CA\CRLPeriod «Weeks»::certutil -setreg CA\CRLDeltaPeriodUnits 1::certutil -setreg CA\CRLDeltaPeriod «Days»:: Меняем параметры CRL Overlapcertutil -setreg CA\CRLOverlapUnits 24certutil -setreg CA\CRLOverlapPeriod «Hours»certutil –setreg CA\CRLDeltaOverlapUnits 12certutil –setreg CA\CRLDeltaOverlapPeriod «Hours»:: включаем полный аудит для сервера CA certutil -setreg CA\AuditFilter 127:: Перезапускаем сервис CA net stop certsvc && net start certsvc:: Публикуем новый CRL в новую локацию.certutil -CRL

CRL или CAC
— списки SSL-сертификатов, отозванных центром выдачи (CA). На 2017 год происходит отказ от использования CRL (САС) в пользу OCSP (Онлайн Протокол Состояния Сертификата).

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

Основные причины аннулирования SSL:

• ключ утерян/украден или скомпрометирован
• неверно указано название компании или другие данные
• сайт прекратил работу
• сменился владелец ресурса
• выдавший сертификат Certification Authority скомпрометирован

Как работают списки CRL?

Список аннулированных сертификатов публикует Certificate Authority (CA), выдавший сертификат:

1) Владелец домена или посетитель сайта, заметивший проблему, обращается в CA и просит аннулировать действующий SSL.

2) CA заносит уникальный серийный номер сертификата в список CAC, который:

• защищён цифровой подписью центра — нельзя изменить
• обновляется минимум раз в сутки — всегда актуален

3) Каждый раз при соединении с ресурсом браузер посетителя проверяет, аннулирован ли SSL-сертификат. Смотрит в загруженных списках CRL или по протоколу OCSP — через запрос к CA. Если находит сертификат в списке CRL или получает от CA ответ, что сертификат отозван — показывает предупреждение об ошибке.

Не все браузеры загружают списки CAC и пользуются OCSP

Firefox
проверяет статус только для сертификатов с расширенной проверкой EV. Пользователи этого браузера не узнают об отзыве SSL DV и OV. Так же как и мобильные пользователи Safari
в iOS. Chrome
определяет статус сертификата для Windows, но не для Linux и Android.

Internet Explorer
и Opera
— самые безопасные в этом отношении браузеры. Они используют OCSP и CRL в зависимости от того, что предлагает CA.

Аннулированный сертификат нельзя восстановить
, только купить новый. Берегите секретный ключ — его утеря или компрометация чаще всего приводит к отзыву SSL-сертификата.

Browser support

There is wide support for OCSP amongst most major browsers:

• Internet Explorer is built on the CryptoAPI of Windows and thus starting with version 7 on Windows Vista (not XP) supports OCSP checking.
• All versions of Mozilla Firefox support OCSP checking. Firefox 3 enables OCSP checking by default.
• Safari on macOS supports OCSP checking. It is enabled by default as of Mac OS X 10.7 (Lion). Prior to that, it has to be manually activated in Keychain preferences.
• Versions of Opera from 8.0 to the current version support OCSP checking.

However, Google Chrome is an outlier. Google disabled OCSP checks by default in 2012, citing latency and privacy issues and instead uses their own update mechanism to send revoked certificates to the browser.

Создание сообщения с усовершенствованной подписью (CAdES-X Long Type 1/XAdES-X Long Type 1)

• Должны быть выполнены все требования для создания подписи CAdES-T/XAdES-T.

• Должна быть доступна запущенная служба актуальных статусов (OCSP-сервер).

• OCSP-сервер должен быть сконфигурирован таким образом, чтобы в поле ThisUpdate OCSP-ответа проставлялось текущее время (например, в режиме работы по БД ЦС для КриптоПро OCSP Server).

• Если соединение с OCSP-сервером осуществляется через прокси-сервер, и этот прокси-сервер отличается от настроенного в Internet Explorer, то его адрес должен быть задан либо в групповых политиках соответствующего клиента, либо передан в качестве аргумента соответствующим функциям КриптоПро ЭЦП SDK.

• Если для соединения с OCSP-сервером требуется аутентификация, то соответствующие параметры должны быть заданы в групповых политиках соответствующего клиента, либо переданы в качестве аргуметов соответствующим функциям КриптоПро ЭЦП SDK.

• Адрес OCSP-сервера должен либо содержаться в расширении AIA (Authority Information Access) сертификата, на ключе которого создаётся подпись, либо должен быть передан в структуре CADES_SIGN_PARA с использованием полей cAdditionalOCSPServices и rgAdditionalOCSPServices, либо должен быть задан в групповой политике КриптоПро OCSP Client Адрес службы OCSP по умолчанию, либо его можно указать в свойствах сертификата УЦ, выдавшего данный сертификат. Для этого сертификат УЦ нужно установить в соответствующее хранилище локального компьютера, после чего указать необходимый адрес в свойствах на вкладке «Протокол OCSP».

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

• Для сертификата службы актуальных статусов должна строиться цепочка, также он должен иметь расширение Признак доверия службе OCSP (id-pkix-ocsp-nocheck — OID 1.3.6.1.5.5.7.48.1.5).

• Должена быть установлена лицензия на КриптоПро OCSP Client.