SSL-сертификат для сайта: как подключить HTTPS и исправить ошибки

HTTPS стал базовым требованием для любого сайта — от лендинга до интернет-магазина. Он шифрует данные между браузером и сервером, подтверждает домен, снижает риск перехвата информации и убирает предупреждение «Не защищено». Однако нажатия кнопки «Выпустить SSL» в панели хостинга недостаточно. Нужно установить полную цепочку сертификатов, перевести внутренние ресурсы на HTTPS, настроить один чистый редирект 301 и проверить автоматическое продление.

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

Что такое SSL-сертификат и HTTPS

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

HTTPS обеспечивает:

• шифрование — трафик между посетителем и сервером не должен читаться при перехвате;

• целостность — данные не должны незаметно изменяться при передаче;

• аутентификацию — браузер проверяет выдачу сертификата для нужного домена.

SSL не удаляет вредоносный код, не исправляет уязвимости CMS и не заменяет контроль доступов. При подозрении на взлом нужна отдельная проверка сайта на вирусы и уязвимости.

Бесплатный или платный SSL

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

Тип	Что проверяется	Когда подходит
DV	контроль над доменом	большинство сайтов, блогов, магазинов и сервисов
OV	домен и сведения об организации	компании с внутренними требованиями к верификации
EV	расширенная проверка организации	регулируемые отрасли или прямое требование политики
Wildcard	домен и поддомены одного уровня	много динамических поддоменов
SAN / multidomain	несколько указанных доменов	один проект работает на нескольких доменах

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

Что подготовить до перехода

Не начинайте с изменения адреса в CMS. Сначала зафиксируйте восстановимую исходную точку:

1. Создайте полную копию файлов и базы данных, затем проверьте восстановление. Используйте подробную инструкцию о резервном копировании сайта.

2. Составьте список имен: example.com, www.example.com, поддомены, панели, API и веб-интерфейсы почты.

3. Определите точку завершения TLS: сервер, балансировщик, CDN или reverse proxy.

4. Проверьте доступы к регистратору, DNS, хостингу, CMS, CDN и аналитике.

5. Сохраните действующие правила редиректов, canonical, sitemap и robots.txt.

6. Запланируйте период низкого трафика и ответственного за откат.

Если одновременно меняется сервер, не объединяйте неконтролируемые изменения. Сначала изучите процедуру переноса сайта на другой хостинг.

Как установить SSL-сертификат: 12 шагов

1. Определите все доменные имена

Сертификат для example.com не всегда покрывает www.example.com. Добавьте оба варианта, если они доступны, а также действующие поддомены. Не выбирайте wildcard по умолчанию, когда достаточно нескольких конкретных имен.

2. Выпустите сертификат

Самый простой путь — функция SSL/TLS или Let’s Encrypt в панели хостинга. На самостоятельно управляемом сервере используйте поддерживаемый ACME-клиент и официальную документацию веб-сервера. Контроль домена может подтверждаться HTTP-запросом или DNS-записью.

3. Установите сертификат и полную цепочку

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

4. Настройте HTTPS на сервере или прокси

Убедитесь, что правильный сертификат привязан к нужному virtual host. Если перед сервером работает CDN, балансировщик или Cloudflare, защищенными должны быть оба участка: браузер — прокси и прокси — origin. Режим, при котором прокси обращается к origin по HTTP, не обеспечивает сквозную защиту передачи.

5. Измените основной адрес в CMS

Укажите в CMS канонический HTTPS-адрес. В WordPress проверяйте WordPress Address и Site Address только после того, как HTTPS уже отвечает корректно. Преждевременная смена может закрыть доступ к панели.

6. Замените внутренние HTTP-адреса

Обновите изображения, CSS, JavaScript, шрифты, iframe, API и загрузки. Для базы WordPress используйте инструмент с поддержкой сериализованных данных вместо слепой SQL-замены. Перед массовой операцией сделайте свежую копию.

7. Устраните mixed content

Mixed content появляется, когда HTTPS-документ запрашивает ресурс по HTTP. Браузер может заблокировать скрипт, стиль или iframe, из-за чего перестанут работать меню, форма или оплата. Откройте DevTools, найдите HTTP-запросы и замените их HTTPS-версиями. Если сторонний сервис не поддерживает HTTPS, замените или удалите интеграцию.

8. Настройте один редирект 301

Все HTTP-адреса должны постоянно перенаправляться на точные HTTPS-аналоги:

http://example.com/page → https://example.com/page

Одновременно выберите основной вариант с www или без него. Избегайте цепочки HTTP → HTTPS www → HTTPS без www и циклов между сервером, CMS и CDN.

9. Обновите SEO-сигналы

Замените URL в canonical, hreflang, XML sitemap, структурированных данных и внутренних ссылках. Убедитесь, что robots.txt не закрывает HTTPS-страницы, а sitemap содержит только конечные адреса с кодом 200. Добавьте или подтвердите HTTPS-ресурс в инструментах вебмастера, если платформа различает протоколы.

10. Обновите внешние системы

Измените адрес в аналитике, Tag Manager, рекламных кабинетах, CRM, платежных сервисах, webhook, email-шаблонах, картах и профилях компании. Особенно внимательно проверьте callback URL авторизации и оплаты.

11. Протестируйте пользовательские сценарии

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

12. Включите автопродление и мониторинг

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

Типичные ошибки SSL и их значение

Симптом или код	Вероятная причина	Что проверить
ERR_CERT_DATE_INVALID	сертификат просрочен, еще не действует или неверны часы	время сервера и устройства, период действия, журнал продления
ERR_CERT_COMMON_NAME_INVALID	имя не входит в сертификат	SAN, www/без www, привязку virtual host
ERR_CERT_AUTHORITY_INVALID	недоверенный издатель или неполная цепочка	промежуточные сертификаты, full chain, корпоративный proxy
«Не защищено» на части страниц	mixed content или отправка формы по HTTP	Console/Network в DevTools, шаблоны, плагины, внешние ресурсы
ERR_TOO_MANY_REDIRECTS	конфликт правил сервера, CMS и CDN	режим SSL прокси, forwarded headers, дубли редиректов
SSL handshake / protocol error	протокол, шифр, SNI или сбой origin	логи сервера, конфигурацию TLS, сертификат origin

Не исправляйте эти ошибки отключением HTTPS. Сначала определите уровень сбоя: DNS, CDN, сервер, CMS или конкретный ресурс страницы.

Особенности WordPress

После установки SSL в WordPress часто остаются HTTP-адреса в контенте, настройках темы и метаданных плагинов. Безопасная последовательность:

1. проверить ответ https://домен;

2. сделать актуальную резервную копию;

3. изменить WordPress Address и Site Address;

4. выполнить search-replace с поддержкой сериализованных данных;

5. очистить кеш CMS, сервера и CDN;

6. проверить медиафайлы, конструктор страниц, формы и шрифты;

7. только после проверок включить глобальный редирект 301.

За reverse proxy WordPress должен правильно распознавать исходный HTTPS-запрос. Иначе возникает бесконечный редирект или приложение создает HTTP-ссылки. Не вставляйте случайные фрагменты конфигурации без понимания заголовков вашего прокси.

Cloudflare, CDN и origin-сервер

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

• протокол обращения CDN к origin;

• выполняет ли редирект сервер, CMS или правило CDN;

• передается ли правильный заголовок исходного протокола;

• отвечает ли origin на ожидаемое имя;

• не остался ли старый сертификат после смены сервера.

Собрать данные о DNS, IP и инфраструктуре поможет инструкция как проверить домен, хостинг и сервер.

Влияет ли переход на HTTPS на SEO

Изменение протокола меняет URL, поэтому поисковой системе нужны согласованные сигналы. Каждая старая страница должна перенаправляться кодом 301 на соответствующую HTTPS-страницу; canonical, hreflang, sitemap и внутренние ссылки должны содержать конечный адрес. Не объединяйте переход на HTTPS с масштабной перестройкой URL без необходимости — диагностика станет сложнее.

После запуска контролируйте:

• индексацию HTTPS-страниц;

• старые HTTP-URL в отчетах;

• ответы 3xx, 4xx и 5xx;

• органический трафик и основные конверсии;

• скорость и Core Web Vitals.

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

Как проверить результат

Протестируйте четыре варианта главной: HTTP/HTTPS и www/без www. Три неканонических варианта должны по чистому маршруту вести на выбранный канонический URL. Затем:

• откройте сведения о сертификате в браузере и проверьте имя, издателя и срок действия;

• найдите в DevTools HTTP-запросы и заблокированные ресурсы;

• командой curl -I посмотрите коды ответа и заголовок Location;

• через openssl s_client проверьте цепочку и SNI, если есть технический опыт;

• запустите независимый SSL-сканер конфигурации;

• обойдите сайт краулером и найдите внутренние HTTP-ссылки;

• проверьте формы, оплату, API и webhook;

• смоделируйте продление или изучите журнал тестового запуска.

Другие инструкции по инфраструктуре и обслуживанию собраны в категории «Хостинг и техническое».

Чеклист после перехода

• Сертификат охватывает домен, www и необходимые поддомены.

• Сервер отдает полную доверенную цепочку.

• Доступ к приватному ключу ограничен.

• Все HTTP-URL перенаправляются на точные HTTPS-аналоги кодом 301.

• Нет циклов и лишних цепочек редиректов.

• Canonical, hreflang, sitemap и structured data используют HTTPS.

• В коде и базе нет необходимых ресурсов с HTTP.

• Формы, оплата, авторизация и API работают.

• Трафик между CDN и origin защищен.

• Аналитика и конверсии продолжают поступать.

• Автопродление включено и протестировано.

• Мониторинг окончания срока или сбоя продления активен.

Распространенные ошибки

1. Охвачено только одно имя. Вариант с www или поддомен показывает предупреждение.

2. В CMS остались HTTP-адреса. Приложение продолжает создавать небезопасные ссылки.

3. Редиректы включены на каждом уровне. Сервер, плагин и CDN создают цикл.

4. Используется временный 302 вместо постоянного 301. Поисковые сигналы становятся менее однозначными.

5. Не проверен mixed content. Важная функция ломается лишь на отдельных шаблонах.

6. Продление предполагается, а не тестируется. Позже сайт становится недоступен части посетителей.

7. Приватный ключ передается другим. После утечки перевыпустите сертификат и замените ключ.

Самостоятельная настройка или помощь специалиста

Самостоятельная установка уместна, если хостинг предоставляет автоматический SSL, сайт небольшой, есть свежая копия и понятный откат. Помощь нужна для VPS, нескольких поддоменов, CDN, reverse proxy, интернет-магазина, платежных интеграций или нестандартного сервера — особенно после цикла, потери доступа к панели или снижения конверсий.

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

FAQ

Можно ли получить SSL-сертификат бесплатно?

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

Почему сайт все еще показывает «Не защищено» после установки SSL?

Чаще всего страница запрашивает изображение, скрипт, шрифт или iframe по HTTP. Другие причины — несовпадение имени, неполная цепочка, кеш или просроченный сертификат.

Нужно ли закрывать порт 80 после перехода?

Обычно нет. HTTP-запросы на порт 80 нужны для перенаправления посетителей на HTTPS и могут использоваться при автоматической проверке домена. Сервер должен отвечать безопасным редиректом, а не отдельной незащищенной версией.

Потеряет ли сайт позиции после перехода на HTTPS?

Кратковременные колебания возможны во время переобхода URL, но точные редиректы 301, canonical, sitemap и внутренние ссылки создают согласованный маршрут. Основной риск связан с ошибками миграции, а не с HTTPS.

Как часто нужно продлевать сертификат?

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