SSL-сертификат сайта протух в пятницу вечером: как забыть об этом навсегда

Пятница, 18:40, у клиента падает 1С-веб-клиент, бухгалтер не может закрыть период. Причина — сертификат протух три часа назад. Я это видел раз пятнадцать за последние годы, и каждый раз история одна и та же: кто-то когда-то поставил платный сертификат на год, поставил себе напоминание в календаре — и благополучно про него забыл или уволился.

Почему сертификаты вообще протухают именно в пятницу

Тут нет мистики, чистая статистика. Сертификаты выпускают по будням, в рабочее время, когда админ или директор сидит и оформляет продление. Год спустя дата истечения падает на тот же день недели плюс-минус — и если это была пятница, то и умрёт он тоже в пятницу. А дальше — либо вечер пятницы, либо суббота, когда все уже мысленно в отпуске.

У меня в практике был клиент — торговая компания, 30 рабочих мест, 1С публикована через веб-сервер Apache с сертификатом от одного из платных удостоверяющих центров. Сертификат брали на год, оплачивали через бухгалтерию по счету, отслеживал это IT-шник, который через восемь месяцев уволился. Календарь остался в его личном Outlook. Итог немного предсказуем.

В пятницу в 19:00 у клиента отвалился удалённый доступ к базе для двух менеджеров, которые как раз добивали отгрузки перед выходными. Мне позвонили в 19:15. Хорошо, что я вообще был на телефоне.

Что происходит технически, когда сертификат протухает

Браузер или клиент 1С видит, что срок действия сертификата истёк, и отказывается устанавливать защищённое соединение. Это не косметическая проблема — HTTPS в принципе не поднимается. Пользователь видит красный экран с предупреждением про NET::ERR_CERT_DATE_INVALID, а тонкий клиент 1С через веб-сервисы просто вываливается с ошибкой соединения, без внятного текста.

Дальше начинается паника, потому что визуально это выглядит как взлом или крупная авария. Звонят мне, я захожу, вижу дату истечения в консоли — и понимаю, что проблема решается за 10 минут, но настроение у клиента уже испорчено. Причём чем крупнее компания, тем больнее: если это медклиника с записью пациентов через личный кабинет на сайте, простой в пятницу вечером — это реальные потерянные записи и злые администраторы на ресепшене.

Отдельная засада — цепочка сертификатов. Если сертификат выпущен через промежуточный УЦ, а на сервере не обновили полную цепочку, ошибка может выглядеть иначе и сбивать с толку даже опытного админа. Я обычно первым делом смотрю через openssl s_client, что реально отдаёт сервер, а не верю картинке в браузере.

Почему ручное продление — это мина замедленного действия

Ручное продление держится на человеке. А человек болеет, увольняется, уходит в отпуск, забывает. Даже если у вас есть регламент и напоминание в календаре за месяц — часто это напоминание видит только один сотрудник, и если он в отпуске, письмо просто лежит непрочитанным.

Я насчитал у своих клиентов минимум четыре разных сценария провала: уволился ответственный и никто не подхватил задачу; сертификат продлили, но забыли применить новый файл на сервере (да, такое бывает — купили, а поставить забыли); истёк срок домена, и УЦ отказался перевыпускать сертификат, потому что не смог подтвердить владение доменом; и просто банальное «было много дел, отложили на понедельник, а сервер упал в пятницу».

Ещё момент — платные сертификаты часто берут на год, а то и на два, чтобы «не дёргаться». Это ложная экономия времени. Чем реже событие, тем больше шансов, что про него забудут именно к моменту, когда оно наступит. Психологически день, который случается раз в 730 дней, выпадает из привычного ритма работы почти гарантированно.

Let's Encrypt и автоматизация — как это работает по-человечески

Let's Encrypt — бесплатный удостоверяющий центр, который выпускает сертификаты на 90 дней. На первый взгляд это звучит хуже платного годового — чаще продлевать. Но фокус в том, что продление автоматизируется полностью, без участия человека, и короткий срок жизни сертификата — это даже плюс: если что-то скомпрометировано, окно риска меньше.

Механика простая. На сервере ставится клиент — обычно certbot, — который умеет подтверждать владение доменом (через HTTP-челлендж на порту 80 или DNS-запись) и автоматически перевыпускать сертификат. Ставится cron-задача или systemd-таймер, который раз в сутки проверяет: если до истечения сертификата осталось меньше 30 дней, certbot тихо продлевает его и перезапускает веб-сервер, чтобы новый сертификат подхватился.

Для 1С это чуть тоньше, чем для обычного сайта на Apache или nginx: если публикация идёт через штатный веб-сервер платформы, надо не забыть про хук, который после продления сертификата перечитывает конфигурацию именно этого сервиса, а не просто nginx. Я обычно прописываю deploy-hook прямо в конфиге certbot — команда перезапуска нужного сервиса выполняется автоматически сразу после успешного продления, без моего участия и без звонков в пятницу вечером.

Как я это настраиваю у клиентов на практике

Первым делом смотрю, что стоит на сервере — Apache, nginx или встроенный веб-сервер 1С (обычно поверх того же Apache или IIS, если это Windows). От этого зависит, каким плагином certbot дёргать: nginx умеет сам переписывать конфиг и подключать сертификат, для Apache то же самое, а для голого TCP или кастомных портов беру DNS-челлендж или standalone-режим с временной остановкой сервиса на секунду.

Дальше — обязательно тестовый прогон в режиме dry-run, чтобы убедиться, что продление реально проходит без ошибок, а не просто «наверное сработает». После этого настраиваю systemd-таймер (в современных дистрибутивах certbot уже сам ставит его при установке через apt, но я всегда проверяю руками, что таймер активен и не в failed-статусе). И обязательно — уведомление в Telegram или на почту при успешном и при неудачном продлении, чтобы если что-то пошло не так, я узнал об этом за месяц до реальной даты истечения, а не в момент падения.

На Windows-серверах, где часто сидит 1С, история чуть сложнее — там нет нативного certbot, приходится использовать win-acme или разворачивать реверс-прокси на Linux перед 1С-сервером именно ради нормальной автоматизации. Я в паре случаев так и делал: ставил лёгкий nginx на отдельной VM как терминатор SSL перед публикацией 1С, и вся головная боль с сертификатами уходила с Windows-сервера полностью.

Что делать, если у вас уже стоит платный сертификат

Не обязательно рвать текущий сертификат немедленно. Можно спокойно доработать до конца оплаченного периода, а параллельно поднять Let's Encrypt на тестовом поддомене или в тестовом окружении, чтобы отработать всю схему без риска для продакшена. Когда убедились, что автоматика работает, — переключаетесь на боевом домене и просто не продлеваете платный сертификат в следующий раз.

Единственный случай, когда я всё же рекомендую платный сертификат, — если клиенту принципиально нужна юридическая ответственность удостоверяющего центра (OV или EV сертификаты для финансовых организаций, например) или если политика безопасности компании прямо это требует. Для обычного корпоративного сайта, интернет-магазина или веб-публикации 1С такой необходимости почти никогда нет — шифрование у Let's Encrypt точно такое же, разница только в договорных обязательствах УЦ.

И да, часто спрашивают: а это точно надёжно, это же бесплатно? Отвечаю всегда одинаково: Let's Encrypt — это некоммерческий проект, который поддерживают Mozilla, Google, Cisco и десятки других крупных игроков, и сегодня на нём висит больше половины сертификатов в интернете. Бесплатно не значит несерьёзно.

Что в итоге получает клиент

После настройки автоматического продления я обычно захожу к клиенту раз в квартал — просто проверить, что таймер жив и уведомления приходят. За всё время ни разу не было повторного инцидента с протухшим сертификатом у тех, кому это настроил. Экономия не только нервов, но и денег — платный сертификат на 1-2 домена стоит от 2000 до 15000 рублей в год в зависимости от типа, а Let's Encrypt бесплатен всегда.

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

Мораль простая: если у вас в компании до сих пор ручное продление сертификата висит на чьей-то персональной ответственности — это не вопрос «если», это вопрос «когда» рванёт. И почти всегда рванёт в самый неудобный момент, потому что удобных моментов для таких вещей просто не бывает.

Частые вопросы

А если у меня 1С опубликована через IIS на Windows, Let's Encrypt вообще подойдёт?
Да, но потребуется отдельный клиент — например win-acme (wacs.exe), который умеет работать с IIS напрямую и тоже ставится с автоматическим планировщиком задач. Я в таких случаях либо настраиваю win-acme прямо на сервере, либо выношу терминацию SSL на отдельный Linux-прокси перед IIS — второй вариант обычно проще в поддержке.

Не упадёт ли сайт на те несколько секунд, пока сертификат продлевается?
При правильной настройке — нет, продление идёт в фоне, и старый сертификат продолжает работать до момента подмены файла и перезапуска веб-сервера, который занимает доли секунды. Единственный риск — если хук перезапуска настроен криво и роняет сервис вместо мягкой перезагрузки конфигурации, поэтому это всегда стоит проверять на тестовом окружении.

У меня сертификат на несколько поддоменов сразу, Let's Encrypt так умеет?
Умеет, через wildcard-сертификаты или через перечисление всех поддоменов в одном запросе. Для wildcard нужен DNS-челлендж — то есть скрипт должен уметь автоматически добавлять TXT-запись в вашей DNS-зоне через API регистратора, это чуть сложнее в настройке, но тоже полностью автоматизируется.

Сколько времени занимает такая настройка у вас на практике?
На стандартной связке Linux плюс nginx или Apache — обычно час-полтора, включая тестовый прогон и настройку уведомлений. С Windows и 1С-веб-сервером может уйти до полудня, особенно если приходится разбираться с нестандартной публикацией или несколькими базами на одном сервере.