Истёк SSL-сертификат 1С: как вернуть доступ и настроить автопродление

Сначала запросите сертификат, который сервер отдаёт пользователю. Кластер 1С пока не трогайте. Найдите узел, где завершается HTTPS: Nginx, Apache, Caddy, прокси, балансировщик или панель управления.

openssl s_client -connect 1c.example.ru:443 \
 -servername 1c.example.ru </dev/null 2>/dev/null \
 | openssl x509 -noout -dates

Дата notAfter уже прошла — выпускайте новый сертификат для того же домена. Истёкший сертификат технически не продлевают. Затем перечитайте конфигурацию веб-сервера и попробуйте войти в базу с рабочего места пользователя.

Какой сертификат видит пользователь

Сертификат на диске и сертификат снаружи — не всегда одно и то же. Администратор мог заменить файл, а Nginx продолжил обслуживать другой виртуальный хост. HTTPS также может завершаться на прокси или балансировщике.

Начните с внешнего адреса:

curl -vI https://1c.example.ru

Команда покажет, как устанавливается TLS-соединение, и выведет сведения о сертификате. Точные даты проверяйте через OpenSSL с параметром -servername: так клиент передаёт домен через SNI.

Теперь сравните результат с данными Certbot:

sudo certbot certificates

Certbot выводит домены, даты окончания и пути к файлам. При стандартной установке рабочие данные лежат в /etc/letsencrypt/.

Так вы отделите истёкший сертификат от двух похожих сбоев: неверного виртуального хоста и недоступного HTTPS.

Рабочие ссылки Certbot чаще всего выглядят так:

/etc/letsencrypt/live/1c.example.ru/fullchain.pem
/etc/letsencrypt/live/1c.example.ru/privkey.pem

Каталоги и команды приведены в инструкции IP-Way по продлению SSL через Certbot и systemd timer. Веб-сервер должен ссылаться на каталог live, а не на старую копию сертификата.

В Nginx выведите активную конфигурацию и найдите директивы ssl_certificate и ssl_certificate_key. В Apache проверьте подключённые виртуальные хосты, SSLCertificateFile и SSLCertificateKeyFile.

Путь к конфигурации и команда проверки Apache зависят от дистрибутива. Используйте принятую у вас команду: apache2ctl configtest либо httpd -t.

Перед выпуском проверьте домен и способ подтверждения

Центр сертификации выпустит новый сертификат только после подтверждения контроля над доменом. При HTTP-01 он запросит проверочный файл через порт 80. При DNS-01 — проверит TXT-запись _acme-challenge.

Сверьте активные A- и AAAA-записи с адресами узлов, обслуживающих публикацию. Ошибка в DNS или устаревшая запись отправит проверочный запрос на другой сервер.

Проверьте, слушает ли сервер порт 80:

sudo ss -tulpn | grep ':80'

Слушающий локальный порт ещё не означает, что он доступен из интернета. Запросите адрес из другой сети или с внешнего узла.

Проверочный маршрут начинается так:

http://1c.example.ru/.well-known/acme-challenge/

Если HTTP-01 завершился ошибкой, проверьте внешний доступ, DNS и обработку каталога /.well-known/acme-challenge/. Statuser Cloud перечисляет три частые причины: сервер недоступен снаружи, Nginx ведёт запрос не в тот каталог или домен указывает не туда.

Выпустите сертификат прежним способом

Во время аварии не меняйте способ выпуска без причины. Сначала восстановите прежнюю схему. Иначе придётся одновременно искать ошибку в новой конфигурации и путь к новому ключу.

Посмотрите сертификаты и сохранённые параметры продления:

sudo certbot certificates
sudo ls -la /etc/letsencrypt/renewal/

Если Certbot работает с модулем Nginx, выполните:

sudo certbot --nginx -d 1c.example.ru

Для Apache команда другая:

sudo certbot --apache -d 1c.example.ru

У сертификата может быть несколько имён. Перечислите каждое через -d, но не добавляйте домены, которые не указывают на этот сервер. Certbot должен подтвердить весь запрошенный набор.

Если сертификат выпускали через webroot, оставьте этот способ:

sudo certbot certonly \
 --webroot \
 -w /var/www/1c \
 -d 1c.example.ru

Каталог после -w должен совпадать с корнем, откуда веб-сервер отдаёт /.well-known/acme-challenge/. Берите путь из действующей конфигурации. Путь в команде выше — пример.

В режиме standalone Certbot временно запускает свой веб-сервер. Ему нужен доступный порт 80. До запуска выясните, не занимает ли этот порт Nginx, Apache или другой процесс.

Wildcard-сертификат требует DNS-01

Сертификат *.example.ru нельзя получить через обычную HTTP-проверку. Понадобится TXT-запись _acme-challenge.example.ru. Такой порядок описывают инструкции IP-Way и Pingmap по замене истёкшего сертификата.

Wildcard покрывает поддомены только одного уровня. Имя web.example.ru подходит под *.example.ru, а test.web.example.ru — уже нет. Для вложенного имени выпустите отдельный сертификат или явно включите его в набор имён.

При ручной DNS-проверке Certbot попросит создать TXT-запись. Автопродление потребует плагина DNS-провайдера: он должен менять запись без участия администратора.

После настройки запустите тестовое продление. Оно покажет, сможет ли Certbot повторить DNS-проверку самостоятельно.

Caddy и панели управления требуют другого порядка

Caddy сам получает и продлевает сертификаты. Если домен обслуживает он, начинайте с журнала службы:

sudo journalctl -u caddy

Ищите ошибки получения сертификата, недоступность домена и отказ ACME-проверки. Исправьте DNS или доступ к портам, затем снова запросите сертификат снаружи.

В Plesk обновление Let’s Encrypt находится в одноимённом расширении. В cPanel откройте SSL/TLS Status или установленный модуль Let’s Encrypt. В ISPmanager — карточку сертификата домена.

После выпуска снова проверьте внешний адрес через OpenSSL. Сообщение панели подтверждает только её операцию. Оно не доказывает, что пользователь попадает на нужный виртуальный хост.

Коммерческий сертификат: соберите цепочку и защитите ключ

Коммерческий центр сертификации выдаёт сертификат домена и промежуточный сертификат. Закрытый ключ создают вместе с CSR, затем хранят в защищённом каталоге.

Для Nginx соберите цепочку в нужном порядке:

sudo sh -c 'cat domain.crt intermediate.crt > /etc/nginx/ssl/1c.example.ru-fullchain.pem'
sudo chmod 600 /etc/nginx/ssl/1c.example.ru.key

Первым должен идти сертификат домена, следом — промежуточный. Руководство YouStable по установке SSL приводит тот же состав цепочки и права 600 для закрытого ключа.

Не подставляйте ключ от другого запроса на сертификат. Если ключ и сертификат не совпадут, веб-сервер отклонит конфигурацию или не включит TLS для этого виртуального хоста.

До установки сверьте сертификат и закрытый ключ средствами, которые поддерживают их алгоритм. Если пару проверяет панель управления, убедитесь, что она приняла оба файла без ошибки.

Подключите сертификат без остановки кластера 1С

Сначала проверьте конфигурацию. Перечитывайте её только после успешной проверки.

Для Nginx:

sudo nginx -t
sudo systemctl reload nginx

Для Apache в Debian и Ubuntu:

sudo apache2ctl configtest
sudo systemctl reload apache2

В системах с утилитой и службой httpd:

sudo httpd -t
sudo systemctl reload httpd

Эти команды проверки Nginx и Apache приводит руководство IP-Way. Получили ошибку — не выполняйте reload. Исправьте путь, права доступа или цепочку сертификатов и повторите проверку.

Сначала перечитайте веб-сервер, который обслуживает публикацию. Кластер 1С перезапускайте лишь тогда, когда отдельная диагностика указывает на сбой его служб.

Если проблема затронула платформу, выберите процесс, который требуется перезапустить. Остановка всего кластера продлит простой, но не исправит TLS и веб-публикацию.

При работе через Apache отдельно сверьте конфигурацию веб-сервера и публикации базы. Сертификат может быть исправен, а нужный виртуальный хост — не обслуживать публикацию.

Проверьте вход, а не только команду reload

После перечитывания ещё раз запросите внешний сертификат:

openssl s_client -connect 1c.example.ru:443 \
 -servername 1c.example.ru </dev/null 2>/dev/null \
 | openssl x509 -noout -subject -issuer -dates

Затем отправьте HTTPS-запрос:

curl -vI https://1c.example.ru

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

Инцидент закрыт, когда пользователь вошёл в базу под своей учётной записью. Успешный nginx -t говорит лишь о правильном синтаксисе. Доступность базы он не проверяет.

То же правило действует для автоматических обработчиков: перезапуск считается успешным только после прикладной проверки. Ответ команды и результат для пользователя — две разные проверки.

Конфигурацию TLS можно проверить сервисом SSL Labs от Qualys. Он покажет цепочку, протоколы и параметры шифрования. Войти в 1С вместо пользователя сервис не сможет.

Докажите, что Certbot обновит сертификат сам

Таймер подтверждает расписание, но не успешное продление. Сначала найдите его:

systemctl list-timers | grep certbot

Имя зависит от способа установки: certbot.timer или snap.certbot.renew.timer. Если пакетный certbot.timer установлен, но выключен, включите его:

sudo systemctl enable --now certbot.timer

Теперь проверьте сохранённую схему продления:

sudo certbot renew --dry-run

Команда проверит параметры, подтверждение домена и действия после выпуска. Рабочий сертификат она не заменит. IP-Way и Statuser Cloud рекомендуют renew --dry-run именно для такой проверки.

Certbot проверяет сертификаты дважды в день. Новый сертификат он запрашивает, когда до окончания остаётся меньше 30 дней. Эти интервалы приводят руководства YouStable и Statuser Cloud.

Тест завершился ошибкой — откройте журнал:

sudo less /var/log/letsencrypt/letsencrypt.log

Проверьте внешний доступ к порту 80, маршрут /.well-known/acme-challenge/ и DNS. При DNS-01 проверьте плагин и права API-ключа DNS-провайдера.

После исправления снова выполните renew --dry-run. Так вы проверите всю сохранённую схему до очередного автоматического запуска.

Не используйте --force-renewal для регулярных тестов. Этот параметр обходит 30-дневный порог и запрашивает новый сертификат. Pingmap указывает лимит Let’s Encrypt: пять выпусков для одного набора имён за неделю.

Рабочий порядок при следующем истечении

Сохраните этот порядок рядом с регламентом веб-публикации:

1. Запросите внешний сертификат через OpenSSL.
2. Сравните его с выводом certbot certificates.
3. Проверьте DNS и доступность HTTP-01 либо DNS-01.
4. Выпустите сертификат прежним способом.
5. Выполните nginx -t, apache2ctl configtest или принятую в системе проверку Apache.
6. Перечитайте веб-сервер.
7. Проверьте внешний HTTPS и вход пользователя в базу.
8. Запустите certbot renew --dry-run.
9. Настройте предупреждения за 30, 7 и 1 день до окончания.

После работ должны остаться три проверяемых следа: таймер запускается, renew --dry-run проходит, пользователь входит в базу. Провален хотя бы один пункт — вы устранили сбой лишь до следующего истечения.