Проверка SSL-сертификатов на предмет отзыва

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

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

Существует 2 альтернативных способа проверить, находится ли SSL-сертификат в списках отзыва:

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

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

CRL


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

echo -n | openssl s_client -connect habr.com:443 -servername habr.com 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/habr.com.crt

Спасибо legioner за подсказку добавить параметр -servername — он необходим для правильного выбора сертификата, если на один IP-адрес их установлено несколько (SNI).

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

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

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

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

wget http://crl.comodoca.com/COMODORSADomainValidationSecureServerCA.crl

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

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

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

openssl crl -inform DER -text -in COMODORSADomainValidationSecureServerCA.crl | grep "90E58B0601C3AD98F07AEE092041C437"

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

OCSP


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

echo -n | openssl s_client -connect habr.com:443 -showcerts

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

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

Определим OCSP-сервер:

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

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

openssl ocsp -url http://ocsp.comodoca.com -issuer /tmp/intermediate.crt -cert /tmp/habr.com.crt -text

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

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

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

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

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


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

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

wget https://raw.githubusercontent.com/o-pod/security/master/ssl-check-revoc.sh

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

chmod a+x ssl-check-revoc.sh

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

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

Zabbix


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

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

ExternalScripts=/etc/zabbix/externalscripts

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

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

Заходим в веб-интерфейс и создаём шаблон (Configuration >> Templates >> Create template). В качестве имени шаблона указываем «Template SSL Checking». Затем внутри шаблона создаём элемент данных (Item) «SSL Certificate in Revocation List», в качестве ключа указываем «ssl-check-revoc.sh[{HOST.NAME}]», с типом проверки «External check». Интервал проверок можно установить на своё усмотрение в зависимости от критичности проекта.



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

1. Для сигнализации отзыва сертификата «Certificate for domain {HOST.NAME} is in revocation list»
Expression: "{Template Custom SSL Checking:ssl-check-revoc.sh[{HOST.NAME}].last()}=1"



2. Для сигнализации об ошибке на случай, если что-то пойдёт не так (например возникнут проблемы с CLR-сервером и т.п.) «Error to check certificate for domain {HOST.NAME}»
Expression: "{Template Custom SSL Checking:ssl-check-revoc.sh[{HOST.NAME}].last()}=2"



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

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



И всё! Можно спать спокойно: если SSL-сертификат вашего домена по какой-либо причине попадёт в список отозванных, Zabbix сразу же вам сообщит.
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 15

    +1
    Забыли указать, что для Let's Encrypt этот шаблон и проверки не подходят.
      –1
      Как правило, бесплатные сертификаты Let's Encrypt ставятся на низкобюджетные сайты, где день-два простоя ничего не решают. Сомневаюсь, что владельцы таких сайтов будут тратить силы и деньги на обеспечение безопасности и мониторинг.
      0
      Интересно, а что будет, если скомпрометируется и попадёт в списки отзывов сертификат удостоверяющего центра, выдавшего SSL-сертификаты для многих тысяч сайтов?
        0
        Можно сказать ничего не будет. Браузеры по-умолчанию не выполняют проверку отзыва сертификата.
        Если вдруг приложение (можно включить для браузера) будет делать корректную проверку отзыва — то все выданные им сертификаты не будут проходить проверку.
          0
          То есть если я, к примеру, выкраду ключ COMODO RSA Domain Validation Secure Server CA (именно им, в частности, подписан сертификат habr.com), то я до 2029 года смогу развлекать себя любого рода MITMом, и никто ничего сделать не сможет?
          Например, подниму публичный WiFi и буду пропускать через себя трафик https://www.sberbank.ru творчески его осмысливая и подправляя. Ага?
            0

            В случае компрометации ключа CA, CA сертификат добавляется браузерами в черный список, владельцам сайтов приходит веселые имейлы, и "CA-Browser Forum" начинает расследование в деятельность CA чей ключ бы скомпроментирован.

        0
        Ну, будет сайтопокалипсис для тех, у кого включены проверки OCSP или CRL… Издержки централизации.
          0
          А у кого выключены, тех можно будет окучивать через MITM?
        0
        Автору — спасибо. Пойдет в копилку.
        Оффтоп. В моей организации батальон бухгалтеров работают с разными государственными структурами, отправляют документы. Недавно как раз столкнулись с тем, что в одной из структур почему-то был отозван удостоверяющий сертификат и CRL, и пока не зашли на сайт и не увидели что там уже совсем другие файлы, не могли понять почему только что (пару недель назад) установленные комплекты ПО, ключей и сертификатов не принимаются. Такое бывает раз в жизни, наверное, но знай мы заранее, не потеряли бы полдня нервов и 2 бутылки часов.
        А то ведь сразу начинается — «мне срочно надо, чтоб за 10 минут, и чтоб у всех тоже работало».
        На Zabbix можно бы и вкинуть проверку ))
          0
          Сделали бы вы шаблон для заббикса с этими айтемами и триггерами и с ллд, цены бы вам не было. Ну и шаблон на share.zabbix.com залить.
            0
            добавьте в вызов openssl s_client параметр -servername для выбора правильного virtualhost
             openssl s_client -connect ${domain}:443 -servername ${domain}
              0
              Спасибо, очень ценное замечание! Действительно, если на один IP установлено несколько сертификатов (SNI), то необходимо указывать опцию -servername для конкретизации домена. В противном случае сервер отправляет сертификат для дефолтного домена.
              Подправил.
              (legioner, к сожалению, моя карма не достаточно высокая, чтоб плюсануть вам)

            Only users with full accounts can post comments. Log in, please.