Никто не знает, где в компании SSL-сертификаты и когда они истекают: аудит сертификатов за один день и шаблон реестра

ИТ-директор производственно-торговой компании (140 сотрудников, две площадки, 6 серверов, сайт + B2B-портал + 1С через веб): «После истории с GlobalSign собственник спросил: „У нас-то всё в порядке?“ Я честно ответил, что про сайт знаю, а про остальное — не уверен. Начал считать: сайт, портал, почта, VPN, RDG для бухгалтерии, публикация 1С, телефония, камеры, Wi-Fi… Оказалось, что сертификатов у нас больше двадцати, три из них истекают в ближайший месяц, а кто продлевает половину — никто не помнит».

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

Картина типичная. По опросу компании «Актив» (Рутокен), актуальный реестр публичных точек с сертификатами ведут только 35% ИТ-специалистов. Остальные узнают о проблеме от пользователей — обычно в понедельник утром или, как в июне 2026 года с GlobalSign, в 4:10 в субботу.

Ниже — план аудита, который укладывается в один рабочий день для компании до 200 человек: где искать, как найти за час, как оценить риск и что делать с находками. В конце — бесплатный шаблон реестра в Excel с формулами.

Зачем аудит SSL-сертификатов нужен именно сейчас

За лето 2026 года изменились три вещи, из-за которых старый подход «сертификат продлевает хостинг, остальное как-нибудь» перестал работать. Полная хронология и оценка рисков для бизнеса — в статье «Сертификатный кризис 2026: что делать бизнесу»; здесь — только то, что влияет на аудит.

Во-первых, сертификаты стали отзывать досрочно. Раньше сертификат обычно «умирал» по расписанию — за 30 дней приходило письмо, и можно было спокойно перевыпустить. Летом GlobalSign, HARICA и TrustAsia отзывали сертификаты отдельных российских организаций с учётом применимого законодательства и собственных политик. Дата 4 мая 2026 года относится к технической редакции EV Guidelines 2.0.2, а не к новому общему санкционному правилу CA/Browser Forum для всех УЦ и всех TLS-сертификатов. Подробное объяснение с первоисточниками — в основной статье цикла. Мониторинг одной доступности сайта отзыв не ловит: сервер может отвечать, хотя клиент больше не принимает его сертификат.

Во-вторых, сокращаются сроки жизни. С 15 марта 2026 года публичный сертификат выдаётся максимум на 200 дней, с марта 2027-го — на 100, с марта 2029-го — на 47. Let’s Encrypt уже переходит на ещё более короткие сертификаты и с июня 2025 года не присылает письма об истечении. Ручное продление «по календарю» перестаёт быть возможным в принципе.

В-третьих, появился новый класс зависимостей. Часть контрагентов — банки, госсервисы и ряд других площадок — перешла на сертификаты НУЦ Минцифры, которым по умолчанию не доверяют Chrome, Safari и большинство программ. Теперь на вашей стороне тоже есть что проверять: доверяют ли ваши рабочие станции, серверы и интеграции этим сертификатам.

Аудит нужен, чтобы ответить на четыре вопроса: что у нас есть, когда и от кого это зависит, что случится при отзыве и кто за это отвечает.

Где живут сертификаты: 12 мест

Большинство компаний помнят про первый пункт и забывают про остальные одиннадцать.

1. Публичный сайт и все поддомены. Не только site.ru и www, но и lk., api., crm., test., old. — всё, что когда-либо выпускалось. Забытые поддомены с истёкшими сертификатами — самая частая находка аудита.
2. Личные кабинеты, B2B-порталы, API для партнёров. Отдельные сертификаты, часто на отдельных серверах или у подрядчика-разработчика.
3. Корпоративная почта. Exchange, Zimbra, Postfix/Dovecot, Communigate: сертификаты для веб-почты (OWA), мобильных клиентов (ActiveSync), Outlook (MAPI/Autodiscover) и для приёма почты по SMTP с TLS. Outlook на телефонах может показать «небезопасное подключение»; серверная доставка блокируется, когда другая сторона требует проверенный TLS, например через MTA-STS enforce или DANE.
4. VPN-шлюз. Fortinet, Check Point, Cisco, UserGate, OpenVPN и HTTPS-порталы управления WireGuard — сертификат веб-интерфейса или шлюза проверяют клиенты на ноутбуках удалённых сотрудников. Сам протокол WireGuard X.509-сертификаты не использует.
5. Шлюз удалённых рабочих столов (RD Gateway) и RDP-серверы. Бухгалтерия, работающая в 1С через RDP, зависит от сертификата RDG.
6. Публикация 1С по HTTPS. Веб-клиент и мобильные клиенты 1С на IIS или Apache — свой сертификат, который никто не мониторит, потому что «это не сайт».
7. CRM, helpdesk, вики, Bitrix24 в коробке, корпоративный портал. Как правило, на внутреннем домене с самоподписанным сертификатом, к предупреждению которого все привыкли — а значит, привыкнут и к предупреждению на фишинговом сайте.
8. IP-телефония. Веб-интерфейс АТС, SIP-TLS, WebRTC-софтфоны.
9. Видеонаблюдение, СКУД, принтеры, ИБП, коммутаторы. Веб-интерфейсы устройств. Обычно самоподписанные и просроченные много лет назад; риск невысокий, но в реестре они должны быть — хотя бы чтобы осознанно решить их не трогать.
10. Wi-Fi с аутентификацией по 802.1X (RADIUS/EAP). Сертификат RADIUS-сервера проверяют все ноутбуки и телефоны; при его истечении сотрудники «внезапно» не могут подключиться к корпоративному Wi-Fi.
11. Внутренний центр сертификации (AD CS) и корневые сертификаты на рабочих станциях. Сюда же — установленные через групповые политики корни НУЦ Минцифры: какой версии, на каких машинах.
12. Интеграции и приложения. Ваши серверы, обращающиеся к API банков, ЭДО, маркетплейсов, служб доставки, платёжных шлюзов, СМС-провайдеров; ваши мобильные приложения с зашитыми сертификатами (pinning); подпись кода, если вы распространяете ПО.

Отдельная категория — то, что зависит не от ваших сертификатов, а от чужих: если банк-клиент, ЭДО или личный кабинет маркетплейса перешёл на НУЦ, ваши серверы и рабочие станции должны этому доверять. Проверять нужно в обе стороны.

Как найти всё за час

Снаружи: журналы Certificate Transparency

Публично доверенные TLS-сертификаты для сайтов регистрируются в журналах Certificate Transparency (CT) в соответствии с требованиями браузерных программ. Это самый быстрый способ увидеть такие сертификаты на ваши домены, включая те, о которых вы забыли — и те, которые кто-то выпустил без вашего ведома. Внутренние, самоподписанные и часть сертификатов из отдельных российских контуров нужно искать другими способами.

Международные УЦ (Let’s Encrypt, GlobalSign, HARICA, ZeroSSL, TrustAsia):

• crt.sh — введите %.site.ru, чтобы получить все поддомены. Столбцы «Not After» (истекает) и «Issuer» (издатель) — то, что нужно для реестра. Сервис периодически перегружен; если отдаёт ошибку 502, повторите позже.

Российские УЦ (НУЦ Минцифры, ТЦИ) в международные журналы не пишут — у них свои три CT-лога (Яндекс, VK, Минцифры). Для них:

• precert.ru — поиск по домену, показывает издателя, серийный номер, срок и все имена в сертификате.
• crtlogs.ru (запущен в августе 2026) и ct.tlscc.ru (ТЦИ).

precert.ru по домену online.sberbank.ru: видны все выпущенные НУЦ сертификаты, издатель Russian Trusted Sub CA, сроки и полный список имён (SAN). То же самое сделайте для своих доменов.

Что искать в результатах: сертификаты, о которых вы не знали; издателя GlobalSign или другой УЦ с санкционным риском; сертификаты, истекающие в ближайшие 60 дней; wildcard-сертификаты (*.site.ru), которые скопированы на десяток серверов и подрядчикам, а числятся за одним.

Снаружи: прямая проверка каждого адреса

Для каждого публичного хоста из реестра — одна команда с любого компьютера вне вашей сети (из корпоративной сети вы можете увидеть не то, что видят клиенты, если стоит шлюз с проверкой TLS). Учтите, что у мобильных операторов исходящий порт 25 обычно закрыт — SMTP проверяйте с VPS или по портам 465/587:

echo | openssl s_client -connect site.ru:443 -servername site.ru 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Для почты и других протоколов с STARTTLS:

echo | openssl s_client -connect mail.site.ru:25  -starttls smtp 2>/dev/null | openssl x509 -noout -issuer -dates
echo | openssl s_client -connect mail.site.ru:993 2>/dev/null | openssl x509 -noout -issuer -dates
echo | openssl s_client -connect vpn.site.ru:443 -servername vpn.site.ru 2>/dev/null | openssl x509 -noout -issuer -dates

Полную проверку цепочки и совпадения имени даёт отдельная команда:

echo | openssl s_client -connect site.ru:443 -servername site.ru -verify_hostname site.ru -verify_return_error 2>&1 | grep 'Verify return'

Ожидаемый результат — Verify return code: 0 (ok). Любой другой код — сертификат либо не доверен на этой машине, либо цепочка неполная (сервер не отдаёт промежуточный сертификат — типичная ошибка при установке сертификата НУЦ), либо имя не совпадает.

Статус отзыва. Отозванный сертификат выглядит действующим по датам — проверять нужно отдельно. Сначала посмотрите расширения Authority Information Access и CRL Distribution Points: конкретный издатель может публиковать OCSP, CRL, оба механизма или ни одного. Для сайтов на международных УЦ удобен SSL Labs; для НУЦ он покажет недоверенный корень, а проблемы с российским сертификатом дополнительно проверяет Яндекс Вебмастер. Если в AIA указан OCSP, запрос из командной строки выглядит так:

openssl s_client -connect site.ru:443 -servername site.ru -showcerts 2>/dev/null </dev/null > chain.pem
awk '/BEGIN/{i++} i==1' chain.pem > leaf.pem      # сертификат сайта
awk '/BEGIN/{i++} i==2' chain.pem > inter.pem     # промежуточный
openssl x509 -in leaf.pem -noout -ocsp_uri
openssl x509 -in leaf.pem -noout -text | grep -A4 -E 'Authority Information Access|CRL Distribution Points'
openssl ocsp -issuer inter.pem -cert leaf.pem -url <URI из команды -ocsp_uri> -resp_text | grep -E 'good|revoked'

Если OCSP нет, используйте CRL из CRL Distribution Points и процедуру конкретного УЦ. Для регулярной проверки оба варианта удобнее автоматизировать мониторингом (см. ниже), чем выполнять руками.

Изнутри: рабочие станции и серверы Windows

Что стоит в хранилищах серверов (свои сертификаты сервисов):

Get-ChildItem Cert:\LocalMachine\My |
  Select-Object Subject, Issuer, NotAfter, Thumbprint, @{n='Days';e={($_.NotAfter - (Get-Date)).Days}} |
  Sort-Object NotAfter | Format-Table -AutoSize

Выполните на каждом сервере: веб, почта, RDG, 1С, AD CS. Для Exchange отдельно: Get-ExchangeCertificate | Format-List Subject, Services, NotAfter, Issuer — поле Services покажет, какие роли (IIS, SMTP, IMAP, POP) привязаны к сертификату.

Что стоит в доверенных корнях (в том числе корни НУЦ):

Get-ChildItem Cert:\LocalMachine\Root, Cert:\LocalMachine\CA |
  Where-Object Subject -like "*Russian Trusted*" | Format-Table Subject, NotAfter, Thumbprint

В домене это удобно собрать со всех машин одним скриптом через Invoke-Command или средствами RMM. Результат — вторая половина реестра: «кто чему доверяет».

Изнутри: сканирование сети

Устройства и сервисы, о которых никто не помнит, находит сканер:

nmap -sV -p 443,8443,993,995,465,587,636,3389,5061,8006,10443 --script ssl-cert --open 10.0.0.0/24 \
  -oN certs-scan.txt

ssl-cert выведет subject, issuer и срок действия каждого найденного сертификата. Запускайте в нерабочее время и предупредите ответственного за ИБ; на медленных сетях ограничьте диапазон.

Linux-серверы: sudo find /etc \( -name "*.crt" -o -name "*.pem" \) -print0 2>/dev/null | xargs -0 -I{} sh -c 'echo {}; openssl x509 -in "{}" -noout -enddate 2>/dev/null', плюс certbot certificates там, где продлением занимается Certbot.

Изнутри: спросить людей

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

Как заполнить реестр

Для каждой найденной точки — одна строка. Минимальный набор колонок (он же в шаблоне):

Шаблон реестра в Excel — в блоке «Материалы к статье» ниже. В нём формулы «дней до истечения», автоматический статус (OK / скоро истекает / истёк), сводка по рискам и второй лист «Где искать» с командами из этой статьи.

Как оценить риск каждой строки

Три вопроса на каждую запись.

Кто издатель и что с ним будет?

Есть ли санкционная экспозиция? Проверьте заявителя и администратора домена, бенефициаров, владение и контроль с учётом права, применимого к конкретному УЦ. Госучастие или связь с материнской либо дочерней структурой под ограничениями требуют отдельной оценки. Общий подрядчик, сервер или IP сами по себе не означают, что сертификат будет отозван.

Что случится при отзыве и сколько стоит час простоя? Для публичного сайта — риск недоступности, потери заявок, обхода и HTTPS-обработки поисковым роботом; для B2B-портала — остановка заказов дилеров; для почты — предупреждения клиентов и возможная недоставка при обязательной TLS-политике; для VPN и RDG — остановка удалённой работы и бухгалтерии; для интеграции с банком — неисполненные платежи. Присвойте каждой строке приоритет: A (простой критичен, экспозиция есть или срок < 60 дней), B (важно, но есть время), C (внутренние устройства, можно отложить).

Что делать с находками

Найдены сертификаты с истечением < 30 дней и неясным способом продления. Продлить сейчас и зафиксировать в реестре, кто и как. Если это Let’s Encrypt через certbot — проверить таймер (systemctl list-timers | grep certbot) и сделать certbot renew --dry-run.

Найден GlobalSign у компании с подтверждённой экспозицией по применимому праву. Не ждать решения при следующей проверке: получить сертификат НУЦ (OV, три рабочих дня, пошаговая инструкция по Госуслугам), проверить возможность выпуска у альтернативного международного УЦ, написать сценарий переключения за час и испытать его на тестовом поддомене.

Найдены забытые поддомены с истёкшими сертификатами. Либо закрыть (удалить DNS-запись, остановить сервис), либо привести в порядок. Оставлять «как есть» нельзя: истёкший сертификат на old.site.ru — это и репутационная дыра, и потенциальная точка входа.

Найдены интеграции с банками/ЭДО, перешедшими на НУЦ. Убедиться, что на серверах, откуда идут эти запросы, установлены корни НУЦ (для Windows — в Trusted Root и Intermediate; для Linux — в системное хранилище; для Java-приложений — в cacerts через keytool). Проверить: curl -vI https://<api-банка> с этого сервера. Для рабочих станций в домене корни раскатываются централизованно — инструкция по GPO, Firefox, Linux и антивирусу.

Найдены самоподписанные сертификаты на внутренних сервисах, к которым все привыкли. Развернуть внутренний CA (AD CS или step-ca) и раздать корень через GPO — один раз, и предупреждений больше не будет. Заодно сотрудники отвыкнут нажимать «продолжить».

Найдено мобильное приложение или интеграция с собственным trust store либо pinning. Зафиксировать в реестре, какие корни и ключи принимает клиент. Домен нельзя переводить без проверки; релиз приложения понадобится, если новый корень не доверен либо новая цепочка не совпадает с настроенным pin.

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

Мониторинг: чтобы аудит не пришлось повторять

Реестр без мониторинга устаревает через месяц. Минимальный набор, который закрывает 90% рисков и не стоит денег:

• Проверка срока и цепочки каждого публичного хоста раз в сутки: Uptime Kuma (есть встроенная проверка сертификата с порогом в днях), Zabbix (шаблон Website certificate by Zabbix agent 2), Prometheus blackbox exporter, или cron-скрипт с openssl s_client и отправкой в Telegram. Пороги: 30 и 14 дней, плюс отдельный алерт, если сертификат сменился (изменился серийный номер) — это ловит и внезапную замену на НУЦ у партнёра, и подмену.
• Проверка статуса отзыва раз в сутки — через OCSP или CRL, который публикует конкретный издатель, либо через сервис мониторинга с поддержкой его механизма отзыва. Именно это отличает «мониторинг сертификатов» от одной проверки доступности.
• Подписка на CT-логи по своим доменам: уведомление о каждом новом сертификате на *.site.ru — бесплатно через Atom-ленту crt.sh (crt.sh/atom?q=%25.site.ru), Facebook CT Monitoring или Cloudflare CT Monitoring (если DNS-зона в Cloudflare); для российских логов — периодический запрос к precert.ru.
• Строка в реестре для корней НУЦ на рабочих станциях с датой проверки раз в квартал: Минцифры публикует новые выпускающие сертификаты без громких анонсов (последние — Sub CA 2024 и ГОСТ 2025).

План на один день

Для компании до 50 человек это укладывается в полдня; для 200 человек с филиалами — в день-полтора. Дороже всего обходится не аудит, а его отсутствие: сутки простоя B2B-портала или почты стоят больше, чем день работы специалиста.

Не хотите делать сами

Визард-АйТи проводит аудит сертификатов как отдельную услугу: за один-два дня собираем реестр по всем 12 точкам, оцениваем санкционную экспозицию, закрываем срочные риски, настраиваем мониторинг и передаём реестр с ответственными. Для клиентов на ИТ-аутсорсинге реестр и мониторинг входят в сопровождение. Скачайте шаблон и заполните сами — или напишите нам, если хотите, чтобы через два дня он был заполнен.

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

• Сертификатный кризис 2026: что произошло с SSL-сертификатами в России и что делать бизнесу
• Нужен ли вашей компании сертификат Минцифры? Матрица решения
• Как получить TLS-сертификат НУЦ Минцифры через Госуслуги
• Массовая установка сертификатов НУЦ в домене через GPO