SSL-сертификат истекает: что делать до блокировки браузером

Письмо хостинга "SSL истекает через 7 дней" ушло в спам, а в понедельник покупатели видят красный экран "Подключение не защищено" и не могут оплатить заказ. За один проход вы узнаете, сколько дней осталось до блокировки браузером. Продлите сертификат на своём стеке (Let's Encrypt, панель хостинга или платный УЦ) и поставите алерт, чтобы ситуация не повторилась.

SSL-сертификат – это "паспорт" HTTPS: браузер доверяет сайту, пока не истечёт дата notAfter. Let's Encrypt живёт 90 дней, certbot обычно продлевает за 30 дней до конца, но автопродление часто ломается (закрыт порт 80, autorenew = False, nginx не перезагрузили). Сначала зафиксируйте срок, потом продлите через панель хостинга или certbot, после – проверьте живой endpoint снаружи и включите мониторинг.

Речь про сайт на своём хостинге, в том числе "1С-Битрикс: Управление сайтом" на BitrixVM или VPS. Это не CRM Bitrix24 – смотрите свой домен витрины.

Типичная сцена: письмо хостинга отложили на понедельник, в субботу Chrome показывает NET::ERR_CERT_DATE_INVALID, certbot пишет "skipped – not due", хотя срок уже вчера. На практике, например, виноваты autorenew = False и отсутствие reload nginx после подмены fullchain.pem.

Узнайте, сколько дней осталось – когда бить тревогу

Для Let's Encrypt (90 дней) окно renew открывается примерно за 30 дней – это норма. Для платных cert на 200+ дней те же пороги – календарь действий, не повод для паники за 60 дней.

Сделайте: завести напоминания 30/14/7/1, а не одно письмо в почту на том же домене. Не делайте: надеяться на "само продлится" без проверки cron или systemd timer.

Проверьте срок и цепочку за две минуты

Быстрый чек перед продлением: понять "скоро" или "уже истёк", и отличить просрочку от битой цепочки. Полный разбор notAfter, issuer и SAN – в отдельной инструкции как проверить срок действия SSL; здесь только минимум для решения.

1. Откройте сайт в Chrome → замок → "Сертификат" → поле "Действителен до" (notAfter).
2. Вставьте домен в онлайн-проверку SSL – сравните дату с браузером.
3. Если браузер пишет NET::ERR_CERT_DATE_INVALID – срок точно вышел, идите в emergency-блок.
4. Если дата жива, но ошибка AUTHORITY_INVALID – проблема цепочки, не срочное продление "на всякий случай".
5. Запишите: домен, notAfter, дни до конца, issuer – пригодится в тикет хостингу.

Сделайте: сверять внешний checker и браузер. Не делайте: дублировать из B09 полный openssl-how-to – там все команды и таблица полей.

Продлите сертификат пошагово: LE, хостинг, платный

Выберите сценарий по тому, где живёт сертификат. Один сайт – один сценарий, не мешайте файлы от разных УЦ.

Сценарий A: BitrixVM и Let's Encrypt через меню

1. SSH → меню BitrixVM → 9 (Configure LE) → 2 (new certificate) → 1 (Get LE certificate).
2. Email для LE и домены (основной + www при необходимости).
3. Автоперевыпуск ~за 20 дней, cron суббота 02:00 – см. курс BitrixVM.
4. Проверьте сайт с телефона через LTE, не только с сервера.

Сценарий B: VPS с certbot (nginx/apache)

1. Проверка без риска: sudo certbot renew --dry-run.
2. Если OK: sudo certbot renew и убедитесь, что deploy-hook делает systemctl reload nginx.
3. Файл для nginx – fullchain.pem, не одиночный cert.pem.
4. Не крутите renew в цикле при ошибке – лимит LE: 5 неудачных проверок на hostname в час.

На VPS перед renew проверьте порт 80 для HTTP-01. Стек можно держать у Beget или другого провайдера – правила те же.

Сценарий C: shared-хостинг

Панель SSL → "Продлить" / Let's Encrypt. Кнопка серая – тикет с notAfter из checker.

Сценарий D: платный SSL

Продление = новый заказ; кнопка в кабинете Рег.ру активна за 30 дней до конца (справка). Файлы в BitrixVM: own certificate, /home/bitrix/ssl/.

Сделайте: после любого сценария – внешний SSL checker. Не делайте: считать зелёную галочку в панели хостинга доказательством для всех клиентов.

Срочно исправьте, если браузер уже блокирует

Симптомы: NET::ERR_CERT_DATE_INVALID, curl exit 60, корзина не открывается. HSTS на iPhone часто не даёт обойти предупреждение. Это не HTTP-down: снаружи может быть 200, но клиенты заблокированы – см. проверку работоспособности сайта.

1. Убедитесь, что порт 80 слушает nginx/apache – для истёкшего LE снова нужен HTTP-01 на :80.
2. Проверьте /etc/letsencrypt/renewal/*.conf: если autorenew = False, certbot пропустит renew даже при expired cert.
3. Выпустите принудительно: sudo certbot renew --force-renewal --cert-name ваш-домен.ru.
4. Перезагрузите веб-сервер: sudo systemctl reload nginx.
5. Сверьте публичный endpoint (checker, телефон через LTE) с файлом на диске – после failed renew symlink live/ иногда откатывается на старый expired fullchain.

Сделайте: чинить в первую очередь, мониторинг – после зелёного замка. Не делайте: отключать HTTPS "временно" на боевой витрине – mixed content и потеря доверия хуже часа простоя.

Устраните ошибки цепочки и mixed content после обновления

Бывает: renew "успешен", а браузер всё ещё ругается. Типичные причины:

• В nginx указан cert.pem вместо fullchain.pem – incomplete chain.
• Nginx не перезагружали – клиенты видят старый сертификат из памяти worker.
• CDN (Cloudflare и др.): edge-сертификат жив, origin на вашем сервере истёк – ошибка 526.
• В БД Битрикс остались ссылки http:// на картинки и скрипты – mixed content после перехода на новый cert.

Mixed content: консоль браузера → http-ресурсы → URL сервера в настройках Битрикс на https, при необходимости search-replace в БД. CDN: режим Full (strict) только после живого origin-cert.

Сделайте: после продления – checker снаружи + одна тестовая покупка. Не делайте: менять CDN и сертификат одновременно без фиксации, что именно сломалось.

Настройте алерт за 14–30 дней до истечения

Ручной календарь при 90-дневных LE проигрывает выходным и спаму. Паттерн: внешняя проверка SSL + Telegram/email до блокировки браузером.

1. Создайте аккаунт BX Pulse и добавьте URL витрины.
2. Пороги: warning < 14 дней, critical < 3 дней или ошибка handshake.
3. Telegram + тестовое уведомление.
4. Warning раз в квартал – health-check автопродления.

Общий onboarding (модуль, heartbeat) – в гайде мониторинг сайта на Битрикс. DIY: cron с openssl x509 -checkend.

Сделайте: алерт на канал, который не зависит от почты на том же домене. Не делайте: единственное напоминание "письмо от хостинга".

Что дальше: закрепите результат

1. Запишите notAfter, issuer и сценарий продления, который сработал.
2. Проверьте autorenew / cron BitrixVM или certbot timer – не только разовый renew.
3. Добавьте сайт в мониторинг с порогами 14/3 дня.
4. После renew – внешний checker, не только галочка в панели.
5. Если снова увидите DATE_INVALID – откройте этот чеклист с emergency-блока, не ждите понедельника.

Итог: дедлайн зафиксирован, cert продлён, endpoint проверен снаружи, алерт включён. Проверка срока – в отдельной инструкции; здесь – действия при истечении.

Материал проверен. Автор: Максим Мольков, основатель BX Pulse, разработчик 1С-Битрикс.
Источники: документация Let's Encrypt (rate limits, integration guide), курс 1С-Битрикс BitrixVM LE (dev.1c-bitrix.ru), справка Рег.ру по продлению SSL (help.reg.ru), DigitalOcean certbot renew (docs.digitalocean.com).