SSL-сертификат для сайта: выпуск, HTTPS и автопродление

Сертификат позволяет браузеру установить защищённое соединение с нужным доменом. В обиходе говорят «SSL», хотя современные соединения используют TLS. Установка сертификата — часть настройки HTTPS. После неё ещё нужно проверить адреса страниц, ресурсы, перенаправления и автоматическое продление.

Что сертификат подтверждает

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

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

Как подтверждается контроль над доменом

Let’s Encrypt описывает несколько способов проверки. При HTTP-01 специальный файл должен быть доступен по HTTP на порту 80. При DNS-01 используется TXT-запись в DNS; этот способ позволяет выпускать wildcard-сертификаты. Конкретную схему выбирают с учётом инфраструктуры и используемого клиента.

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

Что проверить после установки

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

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

Продление должно работать без ручного напоминания

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

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

Не смешивайте HTTPS и общую защиту проекта

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

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

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