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

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

SSL-сертификат сайта связывает доменное имя с открытым ключом и участвует в проверке сервера при защищённом соединении. Название SSL осталось в обиходе, хотя современные HTTPS-соединения используют TLS. Ниже разберём выбор, установку, проверку и продление на условном магазине с адресами example.com, www.example.com и api.example.com. Это учебная архитектура.

Для чего сайту SSL-сертификат и что защищает HTTPS

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

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

Граница защиты зависит от инфраструктуры. Когда перед сайтом стоит CDN или обратный прокси, есть отдельное соединение «посетитель → CDN» и отдельное «CDN → исходный сервер». Валидный сертификат на внешнем узле не доказывает, что второй участок тоже зашифрован и проверяет подлинность сервера. Его конфигурацию принимают отдельно.

Как выбрать сертификат и охватить нужные домены

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

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

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

DV, OV и EV описывают уровень проверки при выдаче. Для DV подтверждают контроль над доменом; OV и EV включают дополнительные проверки организации по правилам удостоверяющего центра. Из этого не следует, что трафик сайта с DV шифруется «слабее»: свойства соединения зависят также от ключей, протокола и настроек сервера. Не выбирайте EV ради обещанной зелёной адресной строки: представление сертификатов в браузерах менялось.

Отдельно выбирают покрытие имён. Сертификат может содержать несколько DNS-имён в SAN. Wildcard вида *.example.com подходит для имени api.example.com, но сам по себе не покрывает example.com и v2.api.example.com. Для основного домена нужно отдельное имя в сертификате. Проверяйте фактический SAN, а не рекламное название тарифа.

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

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

Проверки при выдаче и состав имён можно сверить с объяснением DV, OV и EV у DigiCert. Допустимые имена проверяйте в самом выданном сертификате.

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

В автоматизированном выпуске через ACME сервер удостоверяющего центра проверяет, что заявитель управляет доменом. У Let’s Encrypt распространены проверки HTTP-01 и DNS-01. Их ограничения подробно описаны в документации типов проверок.

HTTP-01 у Let’s Encrypt не выпускает wildcard. Для wildcard применяют DNS-01. В распределённой системе HTTP-проверка должна успешно обслуживаться теми узлами, на которые может попасть запрос проверки. Настройка только одного сервера из нескольких создаёт нестабильный результат.

DNS-01 удобен, когда веб-сервер недоступен снаружи, но требует аккуратного управления доступом к DNS. Не выдавайте процессу продления полный административный доступ ко всем зонам, если провайдер позволяет ограничить права. Документация Let’s Encrypt отдельно рекомендует ограниченные учётные данные либо отдельный сервер проверки. Ручное добавление TXT при каждом выпуске мешает автоматизировать продление.

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

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

Имена файлов зависят от клиента выпуска и веб-сервера. Не копируйте конфигурацию с чужого примера без понимания, где конечный сертификат, где цепочка, а где ключ. После изменения сначала проверяют синтаксис конфигурации доступным для данного сервера способом, затем применяют её и проверяют ответ снаружи. Точная команда зависит от Nginx, Apache, панели хостинга или балансировщика.

Если нужен бесплатный сертификат, сначала проверьте возможности платформы или хостинга. Let’s Encrypt выпускает сертификаты бесплатно, а сервис размещения может управлять выпуском и обновлением за вас. При самостоятельной настройке нужен ACME-клиент и необходимые права на сервере. Этот выбор описан в официальном руководстве Let’s Encrypt. Бесплатный выпуск не отменяет работы по настройке и контролю.

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

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

Для диагностики можно использовать OpenSSL. Команда ниже ничего не меняет на сервере: она подключается к учебному адресу и проверяет имя. Замените домен своим. Параметры описаны в официальной документации s_client.

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error -showcerts

-servername передаёт имя через SNI, чтобы сервер выбрал нужный виртуальный хост. -verify_hostname проверяет соответствие имени. -verify_return_error не позволяет считать диагностическое продолжение после ошибки проверки доказательством доверия. -showcerts показывает присланные сервером сертификаты; само наличие этого списка ещё не означает успешную проверку цепочки.

Результат зависит и от хранилища доверенных центров на машине, с которой выполняется команда. Ошибку доверия разбирайте вместе с цепочкой и настройкой локального trust store. Не делайте вывод «сертификат сломан у всех» по одному старому диагностическому окружению. Но и успешное соединение OpenSSL не заменяет проверку браузера, поддерживаемых клиентов и фактического пользовательского сценария.

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

Для проверки онлайн можно начать с инструкции сервиса Рег.ру: введите своё имя сайта и посмотрите сведения о сертификате и сроке. Результат конкретного сервиса оценивайте вместе с проверкой браузера. В этой статье мы объясняем порядок, а не приводим результат проверки вашего сайта.

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

Представим учебный инцидент. ACME-клиент сообщает об успешном продлении. Файл на сервере имеет новый срок действия, но внешняя проверка показывает старый сертификат. Из этих наблюдений следует только то, что выпуск и внешняя выдача не совпали. Причину устанавливают по маршруту соединения.

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

1. Найдите точку завершения TLS. Если перед приложением CDN, внешний сертификат может управляться в панели CDN независимо от локального ACME-клиента.
2. Сравните конфигурацию и путь файла. Процесс может читать другую директорию, старую копию или секрет в контейнере, который не обновился вместе с файлом на хосте.
3. Проверьте применение. Выпуск сертификата не всегда перезагружает конфигурацию сервиса. Проверяйте результат соответствующего deployment hook и журнала службы.
4. Проверьте все обслуживающие узлы. Один балансировщик мог получить новую версию, второй : остаться со старой.
5. Повторите внешнюю проверку. Закройте инцидент после проверки фактически выдаваемого сертификата и рабочего пользовательского маршрута.

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

Запрос к https://www.example.com сначала устанавливает TLS-соединение. Только после этого клиент получает HTTP-ответ, в том числе редирект на https://example.com. Если сертификат для www невалиден, пользователь может увидеть предупреждение раньше, чем сервер отправит перенаправление. Поэтому имя, используемое только для HTTPS-редиректа, тоже нуждается в корректном TLS.

После настройки HTTPS проверьте прямой вход по основным вариантам адреса, число перенаправлений и конечный URL. Затем согласуйте внутренние ссылки, canonical и sitemap с выбранным адресом. Подробный порядок смены адресов разобран в материалах о редиректе 301 и миграции сайта.

Страница может открываться по HTTPS, но ссылаться на ресурсы по HTTP. Браузер обрабатывает смешанное содержимое по своим правилам: часть запросов может обновляться до HTTPS, часть блокироваться. Проверяйте консоль и Network, адреса скриптов, стилей, изображений, встроенных фреймов и запросов API. Для исправления нужны корректные защищённые адреса ресурсов и поддержка HTTPS на принимающей стороне, а не отключение защиты браузера.

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

Правила обработки смешанного содержимого описаны в документации MDN, а поведение HSTS в справке заголовка Strict-Transport-Security. Это разные проверки после включения защищённого соединения.

Как принимать HTTPS и контролировать продление

• Все публичные имена и точки завершения TLS внесены в реестр; для каждого известен владелец.
• Сертификат соответствует имени, действует на дату проверки, сервер выдаёт корректную цепочку.
• Работают прямой вход, перенаправления, формы, авторизация и интеграции; нет необъяснённых ошибок смешанного содержимого.
• Автоматическое продление проверено предусмотренным клиентом способом; отдельно проверены доставка и применение.
• Внешний монитор наблюдает обслуживаемый сертификат, а не только локальный файл; уведомление получает ответственный.
• Известен порядок восстановления при сбое DNS-проверки, истечении сертификата или утечке ключа.

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

Мы в Гуси-Лебеди предлагаем завершать настройку проверкой пользовательских действий и порядка следующего обновления. Тогда у ответственного есть и рабочий сайт, и понятный способ заметить проблему заранее.