Как продлить (обновить) SSL-сертификат
Продление (обновление) SSL/TLS сертификата — это регулярная задача сопровождения, которая позволяет сайту продолжать работать по HTTPS без предупреждений браузера и без простоя. Большинство “SSL-проблем” возникают не при установке, а когда сертификат истекает и его вовремя не обновили. Браузеры очень строгие: просроченный сертификат показывает пользователю большой экран с предупреждением, снижает доверие и часто бьёт по конверсии. Поэтому правильный подход — рассматривать сертификат как живую часть инфраструктуры: её нужно контролировать, обновлять заранее и проверять после изменений.
Процесс обновления зависит от источника сертификата. Сертификаты Let’s Encrypt обычно действуют 90 дней и рассчитаны на автоматизацию через ACME-клиент (например, certbot). Коммерческие DV/OV/EV сертификаты зачастую имеют более длинный срок (часто год, в зависимости от политики), но их продление обычно означает перевыпуск с новой валидацией. Однако в любом варианте с точки зрения сервера вы почти всегда “ставите новый сертификат” и делаете reload сервисов, чтобы обновлённые файлы реально начали использоваться.
В CloudHosting можно упростить сопровождение, выбирая правильную модель сервиса. Если нужен определённый тип сертификата (DV/OV/EV, wildcard, multi-domain), смотрите SSL сертификаты. Если вы хотите более простой сценарий для типовых сайтов, часто выбирают хостинг. Если нужна полная свобода, несколько приложений, reverse proxy и нестандартные процессы валидации, лучше подойдут виртуальные серверы.
1) Сначала определите, что именно вы продлеваете
Перед любыми действиями выясните, Let’s Encrypt это или коммерческий CA. Проще всего посмотреть Issuer и даты действия. Let’s Encrypt обычно продлевается автоматически при условии, что ACME-клиент запускается по расписанию и метод проверки домена не сломан. В случае коммерческих сертификатов продление чаще всего означает перевыпуск: вы получаете новый сертификат с новыми датами и затем устанавливаете его на сервер.
Не оставляйте на последний день. Для OV/EV начинайте процесс минимум за 2–3 недели: проверка организации и документы могут занять время. Даже при Let’s Encrypt полезно периодически убеждаться, что продление работает: изменения DNS, фаервола или прокси могут тихо сломать ACME и привести к истечению сертификата позже.
2) Проверьте срок и убедитесь, какие имена должны быть покрыты
Во время обновления часто всплывают “дыры” по именам. Сертификат может покрывать только www, а пользователи заходят и на корень домена, или появился новый поддомен (api, shop, portal). В итоге HTTPS работает только частично, а на части адресов возникает name mismatch. Перед обновлением составьте список нужных hostname и убедитесь, что в новом сертификате они все будут в SAN.
openssl s_client -connect example.ru:443 -servername example.ru 2>/dev/null | openssl x509 -noout -dates -ext subjectAltName
Если вы меняете набор имён, это по сути перевыпуск. Для Let’s Encrypt это обычно означает повторно запустить certbot с дополнительными -d. У коммерческих CA это может быть перевыпуск в рамках заказа или новый заказ — зависит от условий поставщика.
3) Let’s Encrypt: автоматизация, проверка и reload
Let’s Encrypt построен вокруг автоматизации. Обычно certbot запускается cron’ом или systemd timer’ом и обновляет сертификат, когда срок подходит. Ваша задача — убедиться в трёх вещах: расписание реально работает, метод проверки домена (HTTP-01 или DNS-01) не сломан, и после обновления происходит reload веб-сервера. Если хотя бы одно звено выпадает, сертификат может истечь незаметно до момента, когда пользователи начнут жаловаться.
certbot renew --dry-run certbot renew
HTTP-01 требует доступный порт 80 и корректную маршрутизацию /.well-known/acme-challenge/ к вашему серверу. Если вы используете строгие редиректы или reverse proxy, убедитесь, что challenge путь остаётся доступным. DNS-01 требует публикации TXT записи в DNS; он обязателен для wildcard и полезен, когда порт 80 открыть нельзя. При DNS-01 важно учитывать время распространения DNS и корректность инструментов, которыми вы добавляете TXT.
После обновления часто нужен reload, чтобы Nginx/Apache начал использовать новый сертификат. Хорошая практика — deploy hook, который делает reload только тогда, когда сертификат действительно обновился. Это делает процесс предсказуемым. В инфраструктуре с балансировщиком важно обновить все ноды: если часть серверов останется со старым сертификатом, пользователи будут получать “случайные” ошибки в зависимости от того, на какую ноду их отправил балансировщик.
4) Коммерческие сертификаты: CSR, ключи и обновление цепочки
Коммерческое обновление чаще всего включает генерацию CSR, прохождение валидации и получение нового сертификата и промежуточных сертификатов. Даже если можно повторно использовать старый CSR, периодически полезно генерировать новый приватный ключ, чтобы уменьшать риск, связанный с долгоживущими ключевыми парами. После получения сертификата установите его на сервер, убедитесь, что отдаётся полная цепочка, и выполните reload сервиса.
openssl req -new -newkey rsa:2048 -nodes -keyout example.ru.key -out example.ru.csr
Очень частая ошибка после обновления — цепочка. CA иногда меняют intermediate, и сервер обязан отдавать полную цепочку, а не только “leaf”. Если после обновления часть клиентов начала видеть “untrusted”, причина часто именно в неполной цепочке или неправильном порядке. Поэтому после каждого обновления проверяйте, что сервер реально отдаёт клиенту.
5) Проверка после обновления: убедитесь, что новый сертификат активен
После обновления проверьте минимум три вещи: даты действия изменились, сертификат покрывает нужные имена, соединение чистое (нет ошибок цепочки, нет “wrong certificate”, не появилось mixed content). Проверяйте из нескольких точек. Если используется CDN или reverse proxy, легко получить ситуацию, когда на edge сертификат новый, а на origin старый (или наоборот). При балансировке нагрузки важно обновить все узлы.
openssl s_client -connect example.ru:443 -servername example.ru | openssl x509 -noout -dates -subject curl -I https://example.ru
Если у вас включён HSTS, дисциплина обновления становится критичной: браузер не позволит перейти на HTTP, и даже короткий период истечения сертификата превращается в заметный простой. Поэтому HSTS включают только после того, как автоматизация продления и мониторинг доказали стабильность, и вводят его постепенно с небольшим max-age.
6) Почему обновление не удаётся: повторяющиеся причины
Причины отказов обычно повторяются. Для Let’s Encrypt это: закрыли порт 80, DNS указывает на другой IP, изменился webroot, reverse proxy блокирует ACME challenge. Для DNS-01: неверные TXT и недостаточное время propagation. Для коммерческих: не завершили валидацию, задержки документов OV/EV, забыли обновить intermediate цепочку. Важно фиксировать эти причины в виде чек-листа, чтобы следующий цикл обновления проходил быстрее.
Ещё один классический случай — забыли про www или новый поддомен. Сертификат обновили, но пользователи заходят на имя, которого нет в SAN, и получают ошибку. Используйте обновление как повод пересмотреть карту доменов и редиректы: выбрать каноническое имя и перенаправлять альтернативы, чтобы поведение было единым.
7) Практика сопровождения: мониторинг и оповещения
Даже при автоматизации нужен мониторинг. Минимальный уровень — проверка срока действия и предупреждение за 14–30 дней до истечения. Это защищает от “тихих” поломок, когда cron перестал работать или изменились условия валидации. Дополнительно можно мониторить логи ACME, успешность reload и периодические HTTPS проверки, которые быстро показывают регрессии после обновлений или инфраструктурных изменений.
Стабильный HTTPS надолго: сделайте обновление процессом
Продление SSL — идеальный момент, чтобы превратить задачу в устойчивый процесс: проверить покрытие имён, автоматизировать обновление, обеспечить единообразную TLS-конфигурацию и тестировать после изменений. Когда это сделано, обновление превращается в рутину, а не в пожар. На практике это значит меньше инцидентов, больше доверия пользователей и стабильный HTTPS независимо от того, используете ли вы Let’s Encrypt или коммерческий CA.
В сложной инфраструктуре помните, что сертификаты могут жить на нескольких уровнях: CDN edge, балансировщик, reverse proxy, origin-серверы. Во время обновления убедитесь, что обновлены все уровни и они согласованы. Чёткий workflow с ответственными, проверками и оповещениями — самый надёжный способ гарантировать, что HTTPS никогда не прервёт критические процессы бизнеса.