SSL-сертификат: как он работает, как проверять срок и цепочку и как перейти на HTTPS, не потеряв трафик

Коротко: что такое SSL-сертификат и как не потерять сайт из-за его ошибки

SSL-сертификат (точнее, TLS-сертификат; название SSL сохранилось по привычке) подтверждает, что сайт по адресу example.ru действительно принадлежит тому, кто им управляет, и позволяет браузеру шифровать связь с сервером. Результат для покупателя — значок защищённого соединения и отсутствие красного предупреждения. Результат для вас — сайт открывается по https://, а форма заказа и личный кабинет защищены от перехвата.

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

1. HTTPS — безопасность и (по Google) положительный сигнал. В руководстве web.dev по включению HTTPS сказано, что Google учитывает HTTPS как положительный сигнал для поискового ранжирования. По пересказу на vc.ru позиция Яндекса: HTTPS сам по себе прямого влияния на ранжирование не оказывает, но для пользователей часто необходим. Это второй источник, формулировку нужно сверить со справкой Яндекса.
2. Срок жизни сертификатов короткий и автоматизируется. По FAQ Let's Encrypt стандартные сертификаты действуют 90 дней; продлевать советуют примерно через 60 дней; можно выбрать краткоживущие сертификаты на шесть дней. Значит, без автоматического продления сайт рано или поздно «упадёт».
3. Ошибки TLS при HSTS не обойти. Заголовок HSTS заставляет браузер всегда использовать HTTPS и запрещает обходить ошибку недействительного сертификата: полезно для безопасности, но при просроченном сертификате сайт для вернувшихся пользователей будет недоступен совсем.
4. Переезд на HTTPS — это переезд сайта. Яндекс считает http и https, а также www и без www разными сайтами, которые могут конкурировать в выдаче: нужны редиректы и склейка.

В статье: как работает сертификат (цепочка доверия, домены, срок), какие бывают типы, как проверить, какие бывают ошибки и как их исправлять, как перейти на HTTPS, HSTS, смешанный контент, автоматическое продление, особенности для магазина, российские сертификаты (осторожно), десять ошибок и PDF-чек-лист на 30 пунктов. Быстрая проверка: проверка SSL-сертификата на tools.cetto.ru (кто выдал, до какого числа действует, на какие домены выписан, полная ли цепочка, версия TLS).

Основа статьи — руководство web.dev по включению HTTPS (бывшая страница Google Search Central), документация MDN о TLS и заголовке Strict-Transport-Security, FAQ Let's Encrypt, статья web.dev о смешанном контенте и пересказы справки Яндекса о переходе на HTTPS. Страницу самой справки Яндекса о переходе на HTTPS я напрямую не открывал; о ней сужу по пересказу поиска. Материалы о российских удостоверяющих центрах взяты из журналистских и блоговых источников разного качества; я отмечаю это в разделе и не делаю выводов за пределами фактов.

Как работает сертификат

По MDN, TLS обеспечивает шифрование (данные нельзя прочитать), целостность (нельзя незаметно изменить) и аутентификацию (в вебе обычно подтверждается подлинность сервера). Сертификат содержит открытый ключ сервера, подписанный доверенной стороной, и связывает ключ с доменным именем. При установке соединения клиент и сервер согласуют версию TLS и набор шифров, аутентифицируют сервер и получают общий секретный ключ. Актуальная версия — TLS 1.3 (RFC 8446); TLS 1.2 ещё используется, а TLS 1.1 и 1.0 использовать не следует (по MDN).

Общее устройство проверки (общие сведения, не пересказ MDN, где эта тема не разобрана): сертификат сайта подписан промежуточным удостоверяющим центром, тот — корневым; браузер доверяет корневым сертификатам из своего хранилища или из операционной системы и проверяет, что сертификат выдан доверенным центром, не истёк, соответствует имени хоста и не отозван. Отсюда типичные ошибки (все они отображаются как «соединение не защищено»):

Wildcard-сертификат (*.example.com) покрывает только один уровень поддоменов (web.dev). Сертификат на несколько имён называется SAN.

Типы сертификатов и откуда их брать

• DV (подтверждение домена) — самый простой: центр проверяет только, что вы управляете доменом. Let's Encrypt выдаёт только DV; OV и EV не выдаются и не планируются, потому что их выпуск нельзя автоматизировать. Wildcard выдаётся, но только через проверку DNS-01; сертификаты для почтовой криптографии и подписи кода не выпускаются (FAQ Let's Encrypt).
• OV и EV — расширенная проверка организации; их выдают платные центры. Для магазина это вопрос доверия и требований партнёров, а не технической необходимости.
• Бесплатные и платные. MDN называет Let's Encrypt некоммерческим центром, выдающим бесплатные TLS-сертификаты; многие хостинги включают HTTPS по умолчанию или через настройку и сами управляют сертификатом. Яндекс советует уточнить у хостинг-провайдера, с какими центрами он работает.
• Где запросить: у хостинга, у регистратора или напрямую у центра. Ключи и сертификат хранятся в закрытом месте сервера: web.dev советует установить сертификат в место, недоступное из веба (например, /etc/ssl в Linux).
• Ключ. web.dev описывает создание 2048-битной пары ключей RSA и запроса на подпись сертификата (CSR). Современные центры и ACME-клиенты делают это автоматически.

Срок действия и автоматическое продление

FAQ Let's Encrypt: стандартные сертификаты действуют 90 дней; можно выбрать краткоживущие на шесть дней; срок изменить нельзя. Продлевать 90-дневные рекомендуется примерно через 60 дней, шестидневные каждые три дня. ACME-клиентам советуют запускать плановое продление в случайное время, чтобы не создавать пиков нагрузки; результат успешной проверки домена кешируется на аккаунте до 30 дней. Практические выводы:

• Настройте автоматическое продление и проверьте, что оно действительно срабатывает (журнал клиента, проверка срока).
• Настройте оповещения о сроке: за 30, 14 и 7 дней. Не полагайтесь на то, что «хостинг сам продлит».
• Проверяйте срок вручную после смены хостинга, DNS и CDN: проверка SSL.
• При смене DNS и CDN учтите, что проверка домена и запись CAA могут помешать выпуску: если у домена есть CAA, там должны быть указаны все нужные центры: «DNS-записи».
• Для нескольких серверов сертификат должен быть обновлён везде.

Переход на HTTPS без потерь

Рекомендации web.dev и справки Яндекса сводятся к следующему порядку.

1. Получите сертификат на все имена (корень, www, нужные поддомены) и установите на сервер; web.dev советует проверять конфигурацию Qualys SSL Server Test и стремиться к оценке A или A+; генератор конфигурации Mozilla помогает выбрать настройки.
2. Исправьте внутренние ссылки и ресурсы. web.dev советует делать внутренние ссылки относительными или протокол-относительными, обновлять ссылки скриптом и учитывать CSS, JavaScript, правила перенаправления, теги link и CSP; ссылки на внешние сайты не трогайте.
3. Настройте постоянный редирект 301 с HTTP на HTTPS и укажите канонические ссылки на HTTPS-версии страниц. Редиректы без цепочек: цепочки редиректов, «Canonical».
4. Обновите служебные файлы: карту сайта (адреса HTTPS), robots.txt, hreflang, Open Graph, счётчики.
5. Добавьте HTTPS-версию в вебмастера и следуйте инструкции «Переход сайта на HTTPS» (Яндекс называет http и https разными сайтами, поэтому нужно настроить перенаправление на главный адрес). Практики на форумах расходятся в порядке шагов (когда ставить 301: сразу или после склейки зеркал); следуйте официальной справке: «Миграция сайта», «Яндекс Вебмастер».
6. Проверьте результат: коды ответа, смешанный контент, сертификат на разных страницах, индексацию, трафик. Яндекс просит проверить, что сертификат корректно работает на других страницах сайта.
7. Следите: HTTP-адреса должны постепенно исчезать из поиска, а HTTPS появляться. Колебания в первые недели нормальны.

Влияние на трафик: по пересказам практиков, при переходе в пределах одного домена просадки обычно небольшие, а трафик часто растёт; это опыт отдельных специалистов, не гарантия.

HSTS

По MDN, заголовок Strict-Transport-Security сообщает браузеру, что хост нужно открывать только по HTTPS; он также не позволяет обойти ошибки защищённого соединения. Директивы: max-age (время в секундах), includeSubDomains (на все поддомены), preload (для списка предзагрузки нужны max-age не меньше года и includeSubDomains). Заголовок учитывается только в ответе по HTTPS; отключить HSTS можно только отправкой max-age=0 по HTTPS. Риски: первый визит по HTTP остаётся уязвимым (снижает предзагрузка); includeSubDomains сделает недоступным любой поддомен, работающий только по HTTP; при ошибке сертификата пользователь не сможет её обойти. Рекомендации:

• Включайте HSTS, когда инфраструктура стабильна, и начинайте с небольших значений max-age (web.dev).
• Пример для обычного использования (MDN): Strict-Transport-Security: max-age=31536000; includeSubDomains.
• Не включайте includeSubDomains, пока все поддомены не поддерживают HTTPS.
• Редирект с HTTP на HTTPS должен быть постоянным (301), а сам редирект не должен содержать заголовок HSTS; заголовок отправляется по HTTPS, в том числе на каждом поддомене.
• Для предзагрузки MDN приводит значение max-age=63072000; includeSubDomains; preload и отправку домена на hstspreload.org; список ведёт Google, и он не входит в стандарт.

Смешанный контент

Смешанный контент возникает, когда страница загружена по HTTPS, а часть ресурсов (изображения, видео, стили, скрипты) — по HTTP (web.dev). Пассивный (изображения, видео, аудио) может показать значок небезопасного соединения и позволяет подменять картинки; активный (скрипты, стили, iframe) опаснее, и большинство браузеров блокирует его по умолчанию. Чтобы найти, откройте DevTools: вкладка Issues в Chromium показывает каждый небезопасный ресурс и рекомендации; Firefox и Safari пишут в консоль. Исправление: заменить адреса ресурсов на HTTPS. По MDN, автоматически обновлять HTTP-ссылки может директива Content-Security-Policy: upgrade-insecure-requests; это подстраховка, а не замена исправления адресов. Для магазина проверьте картинки товаров, скрипты счётчиков, виджеты, внешние формы и платёжные блоки: «Оптимизация изображений».

Особенности магазина

• HTTPS на всех страницах, а не только на оформлении заказа: корзина, личный кабинет, поиск, фильтры.
• Все варианты адреса приводят на один: http и https, www и без; редиректы 301, canonical на HTTPS: «Коды ответа».
• Сертификат покрывает все используемые имена: корень, www, поддомены (каталог, блог, почта).
• Куки с флагом Secure (web.dev), особенно для сессий.
• Рекламные и внешние блоки по HTTPS: HTTP-iframe не работает на HTTPS-страницах (web.dev).
• Referer при переходе с HTTPS на HTTP не передаётся (web.dev): учитывайте при аналитике и партнёрах: «Сквозная аналитика».
• Обслуживание: срок сертификата и домена в календаре, ответственный назначен: Whois.
• Доверие: HTTPS — часть базовой надёжности сайта: «E-E-A-T».

Российские сертификаты: что известно

Вопрос сертификатов от российского удостоверяющего центра (НУЦ Минцифры) затрагивает не техническую, а политическую и правовую сторону, поэтому я ограничусь общими сведениями из журналистских и блоговых материалов (официальных страниц Минцифры и вендоров браузеров я не проверял). По этим материалам: НУЦ с 2022 года выдаёт российским организациям бесплатные TLS-сертификаты на фоне того, что западные центры стали отказывать российским организациям; поддержка корня НУЦ встроена в российские браузеры (например, Яндекс Браузер, по материалам банковского блога), а в других браузерах корневой сертификат нужно устанавливать вручную; в 2026 году сообщалось о предупреждениях в зарубежных браузерах на ряде сайтов, перешедших на такие сертификаты. Журналистский материал также упоминает риски установки корневого сертификата на устройство. Практический вывод для владельца сайта: выбирая центр, учитывайте, какие браузеры и устройства используют ваши покупатели, проверьте, как сайт открывается в Chrome, Firefox, Safari и Яндекс Браузере, и обсудите решение с технической командой и юристом. Установка корневых сертификатов на устройства пользователей — отдельное решение; не рекомендуйте её покупателям без необходимости.

Как проверить сертификат

1. Проверьте сертификат сервисом: проверка SSL-сертификата показывает центр, срок действия, домены, полноту цепочки, доверие браузеров, версию TLS.
2. Откройте все варианты адреса: корень, www, важные поддомены; на каждом нет предупреждений.
3. Проверьте цепочку и конфигурацию внешним тестом (web.dev называет Qualys SSL Server Test; MDN — SSL Labs и Mozilla Observatory) и сравните с рекомендациями Mozilla по настройкам.
4. Проверьте редиректы и коды: коды ответа, цепочки.
5. Найдите смешанный контент: DevTools, вкладка Issues.
6. Проверьте записи CAA и DNS: DNS-записи.
7. Проверьте срок и автопродление; настройте оповещения.
8. Проверьте в вебмастерах: сообщения о безопасности и индексации: «Google Search Console».

Десять частых ошибок

1. Просроченный сертификат из-за сломанного автопродления.
2. Сертификат не покрывает www или нужный поддомен.
3. Неполная цепочка (нет промежуточного сертификата).
4. Смешанный контент после переезда.
5. Нет редиректа с HTTP на HTTPS или редирект цепочкой.
6. Canonical, карта сайта и ссылки остались на HTTP.
7. HSTS с большим сроком и includeSubDomains включён до проверки всех поддоменов.
8. CAA не включает нужные центры, и сертификат не выпускается.
9. Устаревшие версии TLS (1.0 и 1.1).
10. Нет оповещений о сроке и ответственного.

Что проверяю в аудите я

В техническом SEO-аудите я проверяю HTTPS: сертификат (срок, цепочку, домены, TLS), редиректы с HTTP и между зеркалами, canonical и карту сайта на HTTPS, смешанный контент, HSTS, записи CAA и DNS, сообщения вебмастеров, и даю приоритетный план. Результат: PDF-отчёт на 30–50 страниц, технические задания для программистов, прогноз по трафику и заявкам и созвон, на котором я лично расскажу о найденных ошибках и отвечу на вопросы. Стоимость от 30 000 ₽, срок 3–5 рабочих дней для небольшого сайта и 7–10 для крупного магазина.

Итоговый чек-лист (короткая версия, полная в PDF)

• Сертификат действителен, покрывает корень, www и нужные поддомены, цепочка полная, TLS актуален.
• Автопродление настроено и проверено; оповещения о сроке есть, ответственный назначен.
• HTTP переадресуется на HTTPS одним 301; canonical, карта сайта и ссылки на HTTPS.
• Смешанного контента нет; HSTS включён осознанно, с проверенными поддоменами.
• Записи CAA (если есть) включают всех нужных центров.
• Сайт проверен в разных браузерах и в вебмастерах.

Об автореВладимир Родионов

Интернет-маркетолог, частный SEO-специалист cetto.ru. 10+ лет в IT, 200+ реализованных проектов, сертификация Яндекса и Google.

Все статьи автора →Задать вопрос в Telegram →