Как установить бесплатный SSL-сертификат на сайт

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

На виртуальном хостинге проще всего включить сертификат в панели. На VPS нужен ACME-клиент, корректный домен, настроенный веб-сервер и автоматическое продление. После выпуска важно проверить не только наличие сертификата, но и весь сайт: редиректы, изображения, формы и обновление срока.

Здесь под SSL понимается привычное название услуги; современные защищённые соединения используют TLS. Примеры с example.com и Nginx предназначены для вашего сервера и требуют подстановки реальных имён. Если домен ещё не направлен на площадку, сначала выполните подключение домена к хостингу.

Что даёт сертификат и чего он не делает

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

Он не исправляет уязвимости CMS, не удаляет вредоносные файлы и не гарантирует добросовестность владельца сайта. Значок защищённого соединения означает свойства канала, а не проверку качества содержимого.

Бесплатный сертификат с проверкой домена может быть подходящим для блога, сайта услуг, магазина или приложения. Организационные требования, специальные типы проверки и условия поддержки нужно оценивать отдельно. Покупать платный сертификат только ради самого факта шифрования обычного сайта обычно не требуется.

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

Что подготовить перед выпуском

Составьте список имён: основной домен, www и используемые поддомены. Сертификат выдаётся на конкретный набор имён. Наличие сертификата для example.com не означает автоматическое покрытие любого поддомена.

Проверьте A и AAAA, доступность площадки и правильный виртуальный хост. Если IPv4 направлен на новый сервер, а IPv6 остался на старом, проверка владения может завершаться непредсказуемо.

Уточните, где завершается TLS: на хостинге, вашем Nginx, CDN или обратном прокси. При наличии прокси может потребоваться сертификат и на внешнем узле, и на origin. Шифрование только между посетителем и прокси не означает автоматически защищённый второй участок.

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

Как центр сертификации проверяет домен

ACME-клиент подтверждает, что вы управляете доменным именем. Основные варианты — HTTP-01 и DNS-01. Их устройство и ограничения описаны в документации Let's Encrypt.

HTTP-01 использует специальный адрес на домене. Сервер должен отдавать проверочный файл по ожидаемому пути. На результат влияют DNS, сетевой доступ, виртуальный хост, прокси и правила ограничения запросов.

DNS-01 использует TXT-запись в DNS-зоне. Такой сценарий позволяет подтвердить владение без направления веб-трафика на новую площадку и применяется для wildcard-сертификатов. Для автоматизации обычно нужен поддерживаемый DNS-плагин и ограниченные права API.

Ручная DNS-проверка подходит для отдельных задач, но не создаёт автоматическое продление сама по себе. Если TXT приходится менять вручную, нужно заранее продумать повторное подтверждение или перейти на автоматизируемый способ.

Вариант 1. Включить сертификат в панели хостинга

Откройте настройки нужного сайта и раздел SSL/HTTPS. Выберите бесплатный сертификат, отметьте нужные имена и запустите выпуск. Названия пунктов зависят от провайдера, но логика обычно такая:

Домен добавлен к сайту и указывает на площадку.
Проверены основной адрес и www.
Выбран бесплатный сертификат.
Выпуск завершился успешно.
Сертификат назначен этому сайту.
Проверено продление и уведомления об ошибках.

Не включайте принудительный HTTPS до подтверждения, что защищённый адрес уже открывается. Иначе все посетители могут начать получать предупреждение или цикл перенаправлений.

После установки откройте сайт в новом окне и проверьте сведения о сертификате: доменные имена, срок и отсутствие ошибок доверия. Затем пройдите внутренние страницы и форму. Сертификат для главной не является отдельным от сертификата для статьи на том же имени, но разные поддомены могут обслуживаться другими настройками.

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

Вариант 2. Certbot на VPS с Nginx

Для собственного сервера популярный вариант — Certbot. Способ установки зависит от ОС и выбранного пакета. Используйте актуальную инструкцию проекта для своей системы; не смешивайте несколько способов установки одного клиента без необходимости.

Пример предполагает, что Nginx уже обслуживает example.com, домен направлен на сервер, нужные порты доступны, а плагин Nginx установлен. Сначала проверьте конфигурацию:

sudo nginx -t

Затем можно запросить сертификат для нужных имён:

sudo certbot --nginx -d example.com -d www.example.com

Указывайте www только если это имя настроено и вы им управляете. Команда может изменять конфигурацию Nginx, поэтому предварительная копия и последующая проверка обязательны.

После завершения снова выполните nginx -t и посмотрите изменения виртуального хоста. Если конфигурация управляется системой развёртывания или панелью, автоматическое редактирование может конфликтовать с ней. В таком случае лучше использовать согласованный сценарий получения и установки сертификата.

Получение через webroot без автоматической правки Nginx

Ниже — практический пример для Ubuntu 24.04 LTS и Nginx. Наш учебный сайт использует имя lab.hostfera.ru, каталог /srv/hostfera-lab/web/public/ и файл /etc/nginx/sites-available/hostfera-lab.conf. Подставьте свои значения. Если веб-сервер ещё не установлен, сначала выполните урок по установке Nginx на Ubuntu.

При webroot Certbot создаёт временные проверочные файлы в корне уже работающего сайта. Редактированием конфигурации Nginx управляем отдельно: получение сертификата и включение HTTPS — два последовательных действия.

Проверяем имя и HTTP-01

До запроса сертификата убедитесь, что A-запись ведёт на нужный IPv4, а существующая AAAA-запись соответствует работающему IPv6. Для HTTP-01 должен быть доступен порт 80 снаружи.

В HTTP-блоке Nginx предусмотрите путь проверки:

root /srv/hostfera-lab/web/public;

location ^~ /.well-known/acme-challenge/ {
    try_files $uri =404;
}

Префикс ^~ важен, если ниже есть регулярное выражение, запрещающее скрытые пути. Он помогает сохранить доступ к ACME-каталогу. После изменения проверьте sudo nginx -t и примените конфигурацию через sudo systemctl reload nginx.

Создайте тестовый файл, если файл с таким именем ещё не используется вашим проектом:

sudo install -d -m 755 /srv/hostfera-lab/web/public/.well-known/acme-challenge
printf 'hostfera-acme-check\n' | sudo tee /srv/hostfera-lab/web/public/.well-known/acme-challenge/hostfera-acme-check
curl -sS http://lab.hostfera.ru/.well-known/acme-challenge/hostfera-acme-check

В ответе ожидается строка hostfera-acme-check. Сам файл на диске не доказывает, что центр сертификации сможет его прочитать: проверьте URL также с другого компьютера или сети. После проверки удалите именно созданный тестовый файл:

sudo rm -- /srv/hostfera-lab/web/public/.well-known/acme-challenge/hostfera-acme-check

Проверка адреса lab.hostfera.ru и чтение тестового файла HTTP-01 — Домен разрешается в IP стенда, проверочный файл доступен по HTTP.

Получаем сертификат

В нашем примере клиент установлен пакетом Ubuntu. Не смешивайте несколько способов установки Certbot для одного сценария без необходимости:

sudo apt update
sudo apt install certbot

Запросите сертификат только для имени, которое подготовили:

sudo certbot certonly --webroot \
  -w /srv/hostfera-lab/web/public \
  -d lab.hostfera.ru \
  --cert-name lab.hostfera.ru

При первой регистрации клиент может задать вопросы об учётной записи и условиях сервиса. Следуйте сообщениям установленной версии. Не добавляйте www, если этого имени нет в DNS или оно не должно обслуживаться вашим сервером.

После успешного выпуска для выбранного имени ожидаются пути:

/etc/letsencrypt/live/lab.hostfera.ru/fullchain.pem
/etc/letsencrypt/live/lab.hostfera.ru/privkey.pem

fullchain.pem содержит сертификат и промежуточную цепочку. privkey.pem — приватный ключ: он остаётся вне публичного каталога с ограниченными правами. Если клиент использовал другое имя сертификата, проверьте фактические пути через sudo certbot certificates.

Включаем HTTPS и перенаправление

Сохраните копию существующего файла сайта перед заменой:

sudo cp -a /etc/nginx/sites-available/hostfera-lab.conf /etc/nginx/sites-available/hostfera-lab.conf.before-https

Затем настройте в этом файле два блока:

server {
    listen 80;
    listen [::]:80;
    server_name lab.hostfera.ru;
    root /srv/hostfera-lab/web/public;
    server_tokens off;

    add_header X-Robots-Tag "noindex, nofollow, noarchive" always;

    location ^~ /.well-known/acme-challenge/ {
        try_files $uri =404;
    }

    location / {
        return 308 https://lab.hostfera.ru$request_uri;
    }
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name lab.hostfera.ru;

    root /srv/hostfera-lab/web/public;
    index index.html;
    charset utf-8;
    server_tokens off;

    ssl_certificate /etc/letsencrypt/live/lab.hostfera.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/lab.hostfera.ru/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_session_cache shared:HostferaLabTLS:10m;
    ssl_session_timeout 1d;

    access_log /var/log/nginx/hostfera-lab.access.log;
    error_log /var/log/nginx/hostfera-lab.error.log warn;

    add_header X-Robots-Tag "noindex, nofollow, noarchive" always;
    add_header X-Content-Type-Options nosniff always;
    add_header X-Frame-Options DENY always;
    add_header Referrer-Policy no-referrer always;

    location ^~ /.well-known/acme-challenge/ {
        try_files $uri =404;
    }

    location / {
        try_files $uri $uri/ =404;
    }

    location ~ /\. {
        deny all;
    }
}

Этот пример сохраняет noindex для учебного сайта. Настройки индексации рабочего проекта выбираются отдельно. HSTS разумно добавлять после проверки HTTPS: его поведение разобрано ниже в отдельном разделе.

Порт 80 остаётся доступным для проверки и перенаправления. Мы не перенаправляем ACME-путь общим return на уровне всего HTTP-блока: отдельное правило продолжает отдавать проверочные файлы.

Примените настройки только после успешной проверки:

sudo nginx -t
sudo systemctl reload nginx

Теперь проверьте оба протокола:

curl -I http://lab.hostfera.ru/
curl -I https://lab.hostfera.ru/

На нашем стенде HTTP возвращает 308 с адресом https://lab.hostfera.ru/, а HTTPS — 200. В команде проверки не используется -k: стандартная проверка сертификата должна проходить самостоятельно.

HTTP 308 и HTTPS 200 для учебного сайта lab.hostfera.ru — HTTP перенаправляет на HTTPS, защищённая страница отвечает кодом 200.

Посмотреть данные сохранённого сертификата можно без вывода его приватного ключа:

sudo openssl x509 \
  -in /etc/letsencrypt/live/lab.hostfera.ru/fullchain.pem \
  -noout -subject -issuer -dates

Эта команда описывает файл на диске. Проверка браузером или curl нужна дополнительно, чтобы подтвердить, что веб-сервер действительно отдаёт подходящий сертификат посетителю.

Поля subject, issuer, notBefore и notAfter сертификата и активный certbot.timer — Данные сертификата на диске и состояние таймера Certbot.

Когда нужна DNS-проверка

DNS-01 полезна, если сертификат требуется до переключения сайта, веб-сервер не доступен для HTTP-проверки или нужен wildcard. Запись создаётся в зоне, которая действительно обслуживает домен.

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

Храните учётные данные в закрытом файле, не передавайте их в URL и не публикуйте в журнале. Проверьте, как плагин ждёт распространения записи и удаляет временные значения после проверки.

Wildcard *.example.com не покрывает сам example.com и не означает произвольную глубину вложенности. Набор имён нужно продумать отдельно. Для небольшого проекта явный список доменов часто проще в сопровождении, чем широкая маска без необходимости.

Как проверить установленный сертификат

Откройте основной домен и www обычным способом. Проверьте, что браузер не сообщает об истечении срока, несовпадении имени или недоверенной цепочке.

Командная проверка соединения:

curl -sS -o /dev/null -w 'HTTP: %{http_code}\n' https://example.com/

Не добавляйте -k для итоговой приёмки: он отключает верификацию. При необходимости посмотреть выдаваемый сервером сертификат можно использовать OpenSSL:

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

Эта команда показывает сведения, но не заменяет полную проверку доверия и всех имён. Если используется CDN, вы увидите сертификат узла, к которому подключились. Origin нужно проверять отдельно с сохранением правильного имени.

До смены DNS используйте проверку нового сервера через --resolve, а не открытие IP в браузере. Успешная проверка с реальным именем подтверждает больше, чем загрузка страницы по служебному адресу.

Перевод сайта на HTTPS

Сначала установите HTTPS-адрес в настройках CMS и проверьте внутренние ссылки. Затем настройте понятный постоянный редирект с HTTP на HTTPS, сохраняя путь и параметры запроса там, где они нужны приложению.

Не отправляйте каждую старую страницу просто на главную. Посетитель, открывший статью, должен попасть на ту же статью по защищённому адресу. Проверьте также единый вариант www и отсутствие цепочек из нескольких лишних переходов.

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

После изменения откройте страницы с картинками, формами и встроенными материалами. Ошибки загрузки HTTP-ресурсов исправляйте по руководству о смешанном контенте. Сертификат не переписывает ссылки в базе и шаблонах автоматически.

Автоматическое продление

Регулярное обновление должно работать без ручного повторения команды выпуска. Проверьте механизм своей установки: systemd timer, cron или расписание панели.

В нашем варианте пакет Certbot для Ubuntu создал таймер:

systemctl is-active certbot.timer
systemctl list-timers certbot.timer --no-pager

Если используется именно этот способ установки, но таймер выключен, его можно включить через sudo systemctl enable --now certbot.timer. При другом способе установки имя расписания может отличаться; не создавайте параллельные задания вслепую.

Перезагрузка Nginx после обновления

Новый сертификат на диске ещё не означает, что рабочие процессы Nginx начали его отдавать. Для сценария certonly добавим deploy-hook, который проверяет конфигурацию и выполняет reload после успешного продления нужного сертификата.

Создайте каталог, если его ещё нет:

sudo install -d -m 755 /etc/letsencrypt/renewal-hooks/deploy

Сохраните скрипт:

sudo tee /etc/letsencrypt/renewal-hooks/deploy/hostfera-lab-reload > /dev/null <<'SH'
#!/bin/sh
set -eu
if [ "${RENEWED_LINEAGE:-}" = /etc/letsencrypt/live/lab.hostfera.ru ]; then
    /usr/sbin/nginx -t 2>&1 && /usr/bin/systemctl reload nginx
fi
SH
sudo chmod 755 /etc/letsencrypt/renewal-hooks/deploy/hostfera-lab-reload

Замените имя сертификата в условии на своё. Проверка ограничивает этот скрипт указанным сертификатом, а nginx -t не даёт перезагрузить заведомо ошибочную конфигурацию.

Проверяем продление и сам hook

Сначала можно выполнить обычную пробную проверку:

sudo certbot renew --cert-name lab.hostfera.ru --dry-run

Она использует тестовую инфраструктуру центра сертификации. Для проверки deploy-hook в таком запуске нужен отдельный флаг:

sudo certbot renew --cert-name lab.hostfera.ru --dry-run --run-deploy-hooks

На нашем VPS проверка прошла: Certbot сообщил об успешном пробном продлении, hook проверил конфигурацию, Nginx остался активен. Именно этот вариант показан на снимке.

Успешный certbot renew с dry-run и run-deploy-hooks, проверка nginx -t и состояние active — Пробное продление, deploy-hook и проверка работающего Nginx завершились успешно.

Если ваша версия не распознаёт опцию, проверьте certbot --help all и документацию установленной версии. Поведение пробного продления и hooks описано в руководстве Certbot.

Успешный тест относится к текущим DNS, портам и конфигурации. После существенных изменений повторите проверку. Настройте наблюдение за сроком сертификата и ошибками расписания: активный timer сам по себе не доказывает, что каждый выпуск завершился успешно.

Частые причины неудачного выпуска

Причина	Что проверить
Домен направлен не туда	A, AAAA и действующую DNS-зону
Проверочный путь закрыт	Ограничения доступа, WAF, правила location
Неправильный виртуальный хост	Домен и корневую папку сайта
Ограничения CAA	Разрешён ли выбранный центр сертификации
Прокси меняет ответ	Маршрут проверки и настройки CDN
Ошибка TXT	Правильную зону, имя записи, распространение
Слишком много повторных попыток	Сообщение клиента и ограничения центра
Неверное время сервера	Синхронизацию часов

Не отключайте защиту всего сайта ради проверки. Лучше разрешить конкретный необходимый путь или выбрать другой поддерживаемый способ подтверждения. Если проект закрыт на разработку, DNS-01 позволяет не открывать его посетителям.

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

HSTS: когда включать

HSTS сообщает браузеру, что сайт нужно открывать только по HTTPS в течение заданного срока. Это полезная настройка после стабильного перевода, но она требует осторожности.

Сначала убедитесь, что HTTPS работает на всех нужных именах и продление проверено. Начинайте с ограниченного срока и расширяйте политику осознанно. includeSubDomains затрагивает поддомены, которые могут обслуживать другие приложения.

Не добавляйте preload «для максимального балла» без проверки требований и понимания последствий. Возврат после такой настройки сложнее, чем удаление одной строки из конфигурации. Для обычного подключения сертификата preload не является обязательным шагом.

Как перенести сертификат при смене хостинга

Часто проще выпустить новый сертификат для новой площадки, чем переносить приватный ключ. Если выпуск нужен до смены DNS, используйте доступный DNS-сценарий или возможности панели.

Если перенос ключа необходим, передавайте его защищённым способом и ограничьте доступ. Убедитесь, что после переноса настроено новое продление: скопированный сертификат не означает перенесённую автоматизацию.

В переходный период оба сервера могут получать запросы. На каждом используемом адресе должен быть корректный HTTPS. Полный порядок переезда рассмотрен в статье как перенести сайт без потери данных.

Как проверить весь набор доменных имён

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

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

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

Для нескольких независимых сайтов удобно вести таблицу: имя, площадка, способ выпуска, способ продления, ответственный и дата последней успешной проверки. Она помогает заметить забытый поддомен до истечения срока.

Что делать, если HTTP-проверка не проходит

Сначала прочитайте точное сообщение ACME-клиента. Если центр не может получить проверочный файл, нужно выяснить, к какому адресу он обращается и какой ответ получает. Повторный запуск той же команды без изменения причины редко полезен.

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

Если сайт закрыт авторизацией, исключение для проверки должно быть узким и понятным. Не открывайте всю административную панель ради выпуска сертификата. При неподходящей схеме доступа рассмотрите DNS-01.

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

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

Пример безопасного подключения нового сайта

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

Если панель умеет выпустить сертификат без открытия всего сайта, используют её штатный процесс. Если HTTP-проверка блокируется общей авторизацией, настраивают только необходимый проверочный путь или применяют DNS-проверку. Режим разработки и запрет индексации сохраняются.

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

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

Как организовать наблюдение за сроком

Проверка должна смотреть сертификат, который реально отдаётся посетителю, а не только дату локального файла. Это особенно важно при нескольких узлах, балансировщике и CDN.

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

Канал уведомлений должен быть доступен при проблеме с самим сайтом. Если единственный адрес оповещения зависит от той же инфраструктуры, продумайте резервный контакт. Не отправляйте приватный ключ или токен DNS в текст уведомления.

После изменения NS, firewall, прокси и корневой папки повторяйте тест продления. Эти изменения способны нарушить проверочный маршрут, хотя действующий сертификат ещё долго выглядит исправным.

План действий при истёкшем сертификате

Сначала подтвердите, какой узел отдаёт просроченный сертификат и для какого имени. Проверьте журнал продления и доступность способа подтверждения. Если новый файл уже выпущен, выясните, почему служба не применила его.

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

После восстановления устраните причину пропуска: неработающий timer, изменённые права, недоступная DNS-зона, забытый reload или сломанное оповещение. Иначе следующая дата истечения повторит тот же инцидент.

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

Бесплатный сертификат хуже шифрует?

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

Можно ли получить сертификат без открытого сайта?

Да, при подтверждении через DNS. Нужно управлять действующей зоной домена и использовать подходящий ACME-клиент или панель.

Нужен ли сертификат для www, если с него идёт редирект?

Да, если пользователь открывает www по HTTPS. Сначала устанавливается защищённое соединение, затем сервер отправляет HTTP-редирект.

Почему сертификат обновился, а браузер видит старый?

Проверьте применённость конфигурации, reload, выбранный виртуальный хост, DNS и прокси. Клиент может подключаться не к тому узлу, на котором вы обновили файлы.

Достаточно ли один раз включить SSL и забыть?

Нет. Нужно автоматическое продление, уведомление о сбоях и проверка фактически отдаваемого сертификата. После переноса DNS, смены прокси или закрытия портов сценарий стоит проверить повторно.

Проверка цепочки и промежуточных сертификатов

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

Используйте файлы, которые формирует ваш клиент, по его инструкции. Для Certbot распространены пути fullchain.pem и privkey.pem в каталоге конкретного сертификата, но нужно проверить фактическое имя и схему установки. Не заменяйте содержимое вручную случайным сертификатом из браузера.

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

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

Что сохранить в документации проекта

Запишите список имён, место завершения TLS, способ выпуска и продления, расположение управляемых конфигураций и ответственного за оповещения. Добавьте дату последнего успешного теста продления и способ проверки извне.

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

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

Контрольный список HTTPS

Все используемые имена включены в сертификат.
DNS и виртуальные хосты направляют на нужную площадку.
Приватный ключ хранится вне публичного доступа.
Браузер и curl проверяют соединение без обхода верификации.
HTTP перенаправляется на соответствующий HTTPS-адрес.
Формы и ресурсы работают без смешанного контента.
Автопродление испытано, reload и оповещения настроены.
HSTS включается только после проверки всей затрагиваемой области.

Исправный HTTPS — это работающий процесс, а не только файл сертификата. Если выпуск, установка, продление и проверка согласованы, защищённое соединение не потребует ручного спасения в последний день срока.

Когда HTTPS работает, проверьте robots.txt, sitemap и отсутствие случайного noindex: сертификат сам по себе не открывает страницы для поиска.

HTTPS для WordPress

Для сайта на WordPress важны также PHP-обработчик и замена старого URL. Эти шаги разобраны в инструкции подключения домена и HTTPS к WordPress.