GlobalSign начал отзывать SSL-сертификаты у российских компаний, которые попали под санкции. В первую очередь речь идёт про EV-сертификаты и организации, где проверяется не только домен, но и сама компания.
У меня на krivoshein.site сертификат GlobalSign сейчас работает нормально. Сайт не под санкциями, сертификат валиден, браузер цепочку видит. Но сама новость важная: если у вас бизнес, банк, крупный сервис, госсвязанные структуры или просто сайт с платным корпоративным сертификатом, лучше не ждать, пока браузер сам объяснит клиентам, что всё сломалось.
Что произошло
По сообщениям СМИ и профильных площадок, удостоверяющий центр GlobalSign начал принудительно отзывать SSL-сертификаты, ранее выданные российским компаниям, подпадающим под санкции Евросоюза.
В письме партнёрам, на которое ссылаются публикации, говорится, что отзыв сертификатов начался 13 июня 2026 года в 04:10 по московскому времени и будет проходить поэтапно.
Причина указана не в стиле «мы передумали», а через требования CA/Browser Forum. Это консорциум, где участвуют удостоверяющие центры и разработчики браузеров. Именно такие правила потом превращаются в реальную жизнь: сайт либо открывается с нормальным замком, либо пользователь видит страшную ошибку TLS.
Почему это важно на практике
SSL-сертификат это не декоративный замочек в адресной строке. Это часть цепочки доверия между сайтом, браузером и пользователем. Если сертификат отозвали, браузер может начать показывать ошибку безопасности, а пользователи просто не попадут на сайт.
Для обычного блога это неприятно. Для интернет-банка, личного кабинета, платёжного сервиса, CRM, сайта с заявками или корпоративного портала это уже авария. Не «потом посмотрим», а именно авария.
Особенно неприятно то, что сертификат может быть ещё не просрочен по дате. Формально срок действия до 2027 года, например, а по факту он уже отозван. Владелец сайта смотрит на дату и думает, что всё хорошо. Браузер смотрит глубже и говорит: нет, дружище, этот билет уже аннулирован.
Что такое отзыв сертификата
У сертификата есть несколько состояний. Он может быть действующим, просроченным, неправильно выпущенным, неподходящим для домена или отозванным. Отозванный сертификат это сертификат, которому удостоверяющий центр больше не доверяет до окончания его обычного срока действия.
Причины бывают разные:
- скомпрометирован приватный ключ;
- сертификат выпустили с ошибкой;
- организация больше не проходит проверку;
- изменились требования CA/Browser Forum;
- появились юридические ограничения, включая санкционные риски.
В текущей истории важен именно организационный и юридический слой. Это не значит, что все сайты с GlobalSign завтра упадут. Но это значит, что владельцам сайтов на платных OV и EV-сертификатах пора проверить, на кого оформлен сертификат и нет ли у этой организации проблем с санкционными списками.
Кого это может затронуть
В первую очередь под ударом компании, которые одновременно подходят под три условия:
- используют сертификаты GlobalSign;
- сертификаты выпущены на организацию, а не просто на домен;
- сама организация находится под санкциями или связана с санкционными структурами.
Больше всего вопросов к EV-сертификатам. Это Extended Validation, где удостоверяющий центр проверяет юридическое лицо особенно подробно. Раньше такой сертификат считался признаком солидности. Сейчас он может стать ещё и точкой отказа, если юридическая часть внезапно перестала проходить проверку.
С обычными DV-сертификатами ситуация проще. Там подтверждается контроль над доменом, а не статус компании. Но это не значит, что DV-сертификаты вообще бессмертные. У любого публичного центра сертификации есть правила, санкционная политика, аудит и зависимость от браузеров.
Почему нельзя полагаться только на один удостоверяющий центр
Главная мысль простая: сертификаты это инфраструктура. А инфраструктуру нельзя строить по принципу «поставил один раз и забыл на год». Особенно если сайт важный.
Когда всё хорошо, кажется, что GlobalSign, DigiCert, Sectigo, Let’s Encrypt или любой другой центр сертификации это просто разные наклейки на одном и том же HTTPS. Но когда начинаются санкции, новые правила, отзыв сертификатов или сбои промежуточных центров, выясняется, что выбор CA тоже часть архитектуры.
Я не юрист и не санкционный комплаенс-специалист. Но как администратор сайтов и серверов скажу грубо и по делу: если ваш сайт критичен для бизнеса, у вас должен быть план замены сертификата. Не философский план в духе «ну что-нибудь придумаем», а конкретный: где выпускаем, как ставим, как проверяем, кто отвечает.
Как проверить свой сертификат
Начать можно прямо с браузера. Откройте сайт, нажмите на значок замка или настройки сертификата и посмотрите, кем он выдан, на какой домен, на какие даты и на какую организацию.
Но лучше проверить ещё и из консоли. На Linux это делается быстро:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuer -subject -dates
Пример вывода:
issuer=C = BE, O = GlobalSign nv-sa, CN = GlobalSign GCC R6 AlphaSSL CA 2025 subject=CN = example.com notBefore=Dec 7 14:31:37 2025 GMT notAfter=Jan 8 14:31:36 2027 GMT
Чтобы посмотреть всю цепочку сертификатов:
openssl s_client -connect example.com:443 -servername example.com -showcerts
Для быстрой проверки HTTP-ответа через HTTPS:
curl -I https://example.com/
Если хочется увидеть больше деталей TLS-соединения:
curl -vI https://example.com/
Если сертификат уже отозван, не всегда curl сразу покажет это так же строго, как браузер. Проверка отзыва зависит от OCSP, CRL, настроек клиента и политики браузера. Поэтому одной команды мало. Нужна проверка в браузерах, внешних SSL-чекерах и мониторинге.
Как проверить сайт через SSL Labs
Для внешней проверки удобно использовать SSL Labs. Он показывает цепочку сертификатов, срок действия, протоколы, шифры, ошибки конфигурации и общую оценку TLS.
Проверять лучше не только главный домен, но и важные поддомены:
- www.example.com;
- api.example.com;
- lk.example.com;
- mail.example.com, если там веб-интерфейс;
- любые клиентские кабинеты и платёжные страницы.
На практике часто бывает так: главный сайт уже перевели на новый сертификат, а забытый поддомен с личным кабинетом продолжает жить на старом. А потом именно туда приходит клиент и получает ошибку. Сервер, конечно, ни в чём не виноват. Он просто тихо делает то, что ему когда-то настроили.
Что делать владельцу сайта
1. Проверить, какой сертификат стоит сейчас
Сначала нужно понять, есть ли проблема вообще. Если у вас обычный сайт на Let’s Encrypt, вы не под санкциями и сертификат выпускается автоматически, паниковать не надо. Но проверить всё равно полезно.
Проверьте:
- центр сертификации;
- тип сертификата: DV, OV или EV;
- дату окончания;
- цепочку промежуточных сертификатов;
- на какую организацию оформлен сертификат;
- нет ли ошибок в браузерах Chrome, Firefox, Edge и Safari.
2. Подготовить запасной вариант
Если сертификат оформлен на организацию из зоны риска, нужно заранее подготовить замену. Самый простой вариант для большинства обычных сайтов это DV-сертификат от Let’s Encrypt, ZeroSSL или другого доступного центра сертификации.
Для WordPress, корпоративного сайта, блога, лендинга или каталога товаров DV-сертификата часто достаточно. Он подтверждает домен и даёт нормальный HTTPS. Клиенту важнее, чтобы сайт открывался без ошибки, чем чтобы в сертификате красовалось длинное юридическое имя.
3. Не менять сертификат вслепую на продакшене
Вот тут аккуратно. Сертификат это не та штука, которую стоит менять ночью одной рукой, второй держа чай, а третьей отвечая клиенту в мессенджере. Особенно если на сервере Nginx, несколько сайтов и общий конфиг.
Перед заменой сделайте бэкап конфигурации:
sudo cp -a /etc/nginx /etc/nginx.backup.$(date +%F-%H%M%S)
Проверьте текущие сертификаты:
sudo find /etc -type f \( -name "*.crt" -o -name "*.pem" \) 2>/dev/null | grep -Ei "ssl|letsencrypt|cert|nginx"
Проверьте конфиги Nginx, где используются сертификаты:
sudo grep -R "ssl_certificate" -n /etc/nginx 2>/dev/null
После любых изменений обязательно:
sudo nginx -t sudo systemctl reload nginx
Если nginx -t ругается, reload делать нельзя. Сначала исправляем конфиг. Nginx в этом смысле честный: если говорит, что конфиг плохой, лучше поверить. Он не капризничает, он спасает вам утро.
Пример замены на Let’s Encrypt через Certbot
Для обычного сервера с Nginx вариант может выглядеть так. Команды примерные, потому что структура сервера, панель управления и пути могут отличаться.
Установка Certbot в Ubuntu или Debian:
sudo apt update sudo apt install certbot python3-certbot-nginx
Выпуск сертификата для домена:
sudo certbot --nginx -d example.com -d www.example.com
Проверка автоматического продления:
sudo certbot renew --dry-run
Проверка сертификата после выпуска:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuer -subject -dates
Если у вас WordOps, Hestia, ISPmanager, Plesk или другая панель, лучше сначала смотреть их штатный механизм выпуска сертификатов. Панели любят сами управлять Nginx-конфигами. Если руками править поверх панели, можно получить прекрасный зоопарк, который потом будет кусаться при каждом обновлении.
Что делать крупным компаниям
Крупным компаниям с личными кабинетами, платёжными системами, API и мобильными приложениями нужно смотреть шире, чем один сертификат на главном домене.
Минимальный чек-лист:
- составить список всех публичных доменов и поддоменов;
- проверить, где используются GlobalSign, DigiCert, Sectigo и другие платные CA;
- отдельно проверить EV и OV-сертификаты;
- понять, на какие юрлица они оформлены;
- проверить мобильные приложения и API endpoints;
- проверить pinning сертификатов, если он где-то используется;
- подготовить аварийный план перевыпуска;
- настроить мониторинг срока действия и ошибок TLS.
Если в мобильном приложении жёстко пришит старый сертификат или цепочка, замена на сервере может не решить проблему, а создать новую. Поэтому сначала инвентаризация, потом тестовый контур, потом продакшен. Да, скучно. Зато потом не будет совещания в стиле «почему у всех всё красное».
Где обычно ломается
Забыли промежуточный сертификат
Сертификат домена может быть правильным, но цепочка неполная. На одном устройстве сайт открывается, на другом браузер ругается. Часто причина в том, что сервер отдаёт не fullchain, а только сертификат домена.
Для Nginx обычно нужен fullchain:
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
Поменяли сертификат не на том server block
На сервере может быть несколько конфигов Nginx. Вы поменяли один, а домен реально обслуживается другим. Проверяется это просто: grep по конфигам и внимательный взгляд на server_name.
sudo grep -R "server_name" -n /etc/nginx/sites-enabled /etc/nginx/conf.d 2>/dev/null
Забыли про www
Сертификат выпустили на example.com, а пользователи ходят на www.example.com. Или наоборот. В итоге один адрес работает, второй показывает ошибку. Это классика, как забыть закрыть кавычку в конфиге и потом долго смотреть в стену.
Не проверили автопродление
Выпустить сертификат один раз мало. Нужно убедиться, что он продлевается автоматически. Особенно если сайт живёт на VPS без панели управления.
systemctl list-timers | grep certbot sudo certbot renew --dry-run
Сломали доступ к ACME challenge
Let’s Encrypt и другие ACME-сервисы должны подтвердить владение доменом. Если у вас закрыт путь .well-known, странный редирект, агрессивный firewall или Cloudflare настроен криво, выпуск может не пройти.
/.well-known/acme-challenge/
Перед разбором лучше временно упростить конфигурацию, проверить DNS, доступность сайта снаружи и логи Nginx.
Что я бы сделал на своём сайте
На своём сайте я бы не драматизировал, но проверил бы всё сразу. У меня krivoshein.site сейчас открывается с сертификатом GlobalSign, и браузер показывает нормальную цепочку. Но если завтра возникнет риск, я спокойно переведу сайт на другой сертификат.
Для личного сайта, блога на WordPress или небольшого бизнеса чаще всего достаточно нормального DV-сертификата с автоматическим продлением. Важнее не бренд удостоверяющего центра, а стабильность, автоматизация и понятный план восстановления.
Платный EV-сертификат имеет смысл только там, где он реально нужен по требованиям бизнеса, комплаенса или внутренней политики. Покупать его просто потому, что «солидно выглядит», сейчас спорная идея. Браузеры давно не показывают EV так эффектно, как раньше, а головной боли стало больше.
Вывод
История с GlobalSign это не повод срочно бежать и менять все сертификаты подряд. Но это хороший повод перестать относиться к TLS как к вечному фоновому шуму.
Если ваш сайт не связан с санкционными юрлицами, скорее всего, прямо сейчас ничего страшного не происходит. Но проверить сертификаты, цепочки, поддомены и автопродление всё равно стоит. Это занимает меньше времени, чем потом объяснять клиентам, почему сайт встречает их ошибкой безопасности.
Если же сертификат оформлен на компанию из зоны риска, лучше действовать заранее: подготовить альтернативный CA, протестировать выпуск, проверить Nginx или панель управления, настроить мониторинг и иметь понятный план переключения. HTTPS должен быть скучным и предсказуемым. Когда он становится новостью, обычно кому-то уже не смешно.
