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

Происхождение и история термина

SSL. Протокол Secure Sockets Layer версии 3.0 датируется 1996 годом, но IETF не публиковал его как стандарт: текст версии от 18 ноября 1996 г. вышел в 2011 г. как исторический документ RFC 6101; двое из трёх его авторов указаны как сотрудники Netscape Communications ^[5].

TLS и HTTPS. Преемником SSL стал протокол Transport Layer Security. В мае 2000 г. Эрик Рескорла описал в RFC 2818 «HTTP Over TLS»: клиент открывает соединение, проводит TLS-рукопожатие, после чего все данные HTTP передаются как прикладные данные TLS; порт по умолчанию — 443, а адреса отличаются идентификатором схемы https ^[2]. В 2022 г. информационный RFC 2818 заменил стандарт RFC 9110 «HTTP Semantics» ^[1].

Вывод старых версий из употребления. RFC 6176 (март 2011 г.) запретил договариваться об SSL 2.0 ^[6]. RFC 7568 (июнь 2015 г.) признал SSL 3.0 недостаточно защищённым и установил: «SSLv3 MUST NOT be used» («SSLv3 не должен использоваться») ^[7]; среди причин документ называет атаку POODLE ^[7]. RFC 8996 (март 2021 г., BCP 195) так же запретил TLS 1.0 и TLS 1.1 ^[8].

TLS 1.3. Версия 1.3 описана в RFC 8446 (август 2018 г.) ^[4]. В июле 2026 г. вышел RFC 9846 — ревизия TLS 1.3 с тем же номером версии протокола, которая отменяет RFC 8446 и RFC 5246 (спецификацию TLS 1.2) ^[3]. Ссылаться на RFC 8446 как на действующий стандарт после этой даты некорректно.

Веб-браузеры и поиск. В августе 2014 г. блог Google для вебмастеров опубликовал пост «HTTPS as a ranking signal» («HTTPS как фактор ранжирования») ^[22]. В феврале 2018 г. команда Chrome объявила, что Chrome 68 (июль 2018 г.) будет помечать все HTTP-сайты как «не защищённые»; по данным того сообщения (февраль 2018 г., исторические), более 68% трафика Chrome на Android и Windows и более 78% на Chrome OS и Mac уже шли по защищённому каналу ^[23]. В 2019 г. стандартизирован протокол автоматического выпуска сертификатов ACME (RFC 8555) ^[10], на котором работает Let's Encrypt ^[15].

Суть и механизм

Что даёт HTTPS

Спецификация TLS 1.3 описывает защищённый канал через три свойства ^[3]:

На практике посредник в сети — например, провайдер — не может незаметно прочитать данные или встроить в страницу свою рекламу ^[17][26]. По описанию web.dev, ряд новых возможностей браузеров — например, съёмка фото и запись звука через getUserMedia() или офлайн-режим на сервис-воркерах — требует явного разрешения пользователя через HTTPS ^[26].

Как устанавливается соединение

Упрощённая схема (рисунок редакции):

Браузер                         Сервер example.ru                Удостоверяющий центр (УЦ)
   | --- TCP-соединение, порт 443 --->|                                      |
   | --- ClientHello (версии TLS,  -->|                                      |
   |      шифры, имя домена — SNI)    |                                      |
   | <-- ServerHello + сертификат ----|   сертификат заранее подписан УЦ <---|
   |  проверка: цепочка до доверенного корня, срок, имя домена в SAN         |
   | <== зашифрованный канал TLS ===> |                                      |
   | == HTTP-запросы и ответы как прикладные данные TLS ==                   |

1. Браузер открывает TCP-соединение с портом 443 и начинает TLS-рукопожатие ^[1][2].
2. Сервер предъявляет сертификат. Клиент обязан проверить, что сертификат выдан именно на запрошенное имя: RFC 2818 требует брать имя из расширения subjectAltName типа dNSName, если оно есть ^[2]; RFC 9110 отсылает к общей процедуре проверки идентичности сервиса ^[1].
3. После рукопожатия все данные HTTP передаются как прикладные данные TLS ^[2].

Важная деталь из RFC 9110: ресурсы по схеме https не имеют общей идентичности с ресурсами по схеме http — это разные источники (origins) с отдельными пространствами имён ^[1]. Поэтому http://example.ru/ и https://example.ru/ с точки зрения протокола — два разных адреса.

Сертификат и цепочка доверия

Формат сертификатов в интернете описывает профиль X.509 v3 в RFC 5280; там же — списки отзыва сертификатов (CRL) и проверка пути сертификации ^[9]. У браузера есть ограниченный набор доверенных ключей УЦ, поэтому сертификат сайта проверяется по цепочке: сертификат сервера → промежуточный УЦ → корневой (самоподписанный) сертификат, с которого начинается путь ^[9]. Имя домена может храниться в поле subject и/или в расширении subjectAltName ^[9].

Выпуск сертификата в автоматическом режиме выглядит так (на примере Let's Encrypt): ACME-клиент на сервере создаёт ключевую пару, УЦ даёт задание подтвердить контроль над доменом — разместить файл по заданному пути на сайте (HTTP) или создать DNS-запись; затем клиент отправляет запрос на сертификат (CSR), подписанный закрытым ключом ^[15]. Выданный сертификат УЦ публикует в публичных журналах Certificate Transparency, а отозванные — в списке отзыва CRL ^[15].

Чем TLS 1.3 отличается от TLS 1.2

По описанию в RFC 9846 ^[3]:

Виды и классификации

По уровню проверки владельца

Классификация DV/OV/EV используется в справке Яндекс Вебмастера ^[17]; идентификаторы политик для DV, OV и IV закреплены в Baseline Requirements CA/Browser Forum ^[12], требования к EV — в отдельных EV Guidelines ^[14].

Важно: уровень проверки не меняет криптографию. TLS-канал одинаков для DV, OV и EV; разница — в том, какие сведения о владельце проверил УЦ (вывод на основе ^[3][12][14]).

По числу доменов

• На одно или несколько имён. Имя домена хранится в поле subject и/или в расширении subjectAltName (Subject Alternative Name, SAN) ^[9]; если в сертификате есть subjectAltName типа dNSName, клиент сверяет адрес именно с ним ^[2]. Яндекс среди вариантов сертификатов называет сертификат на «заранее определенный ограниченный список адресов» ^[17].
• Wildcard (*.example.ru) — звёздочка заменяет ровно один уровень имени: по RFC 2818 *.a.com подходит для foo.a.com, но не для bar.foo.a.com ^[2]. Google упоминает wildcard-сертификат как способ покрыть поддомены ^[19].

По способу выпуска

• Автоматические — выпуск и продление по протоколу ACME; Let's Encrypt называет себя бесплатным, автоматизированным и открытым УЦ ^[10][15].
• С проверкой организации — сертификаты OV и EV: перед выпуском УЦ проверяет не только контроль над доменом, но и сведения об организации ^[14][17], поэтому такой выпуск не сводится к автоматической проверке по ACME.

По корню доверия: российская специфика

Помимо международных УЦ, в России выдаются сертификаты Национального удостоверяющего центра (НУЦ). По данным ComNews, НУЦ создан в 2022 г. на базе НИИ «Восход», подведомственного Минцифры ^[32]. Правила для этих сертификатов меняются: по данным того же издания, Минцифры представило проект постановления правительства о новых случаях прекращения действия сертификатов НУЦ, обсуждение которого было назначено до 7 сентября 2026 г. ^[32]. В редакции закона № 63-ФЗ «Об электронной подписи», которую на 14.10.2026 показывает КонсультантПлюс, статей о Национальном удостоверяющем центре пока нет, а система отмечает, что подготовлены редакции «с изменениями, не вступившими в силу» ^[34]. Таким образом, на 14.10.2026 правила выдачи и прекращения действия сертификатов НУЦ, по данным СМИ, существуют в виде проектов ^[32][33].

Речь не только об отечественной криптографии. По данным Код.ру, Минцифры опубликовало для общественного обсуждения проект приказа, который вводит десять видов сертификатов НУЦ; сертификаты для сайтов DV и OV упоминаются в версиях RSA и ГОСТ ^[33]. Издание пишет, что RSA-сертификаты «по-прежнему публично фиксируются в глобальных CT-логах», а для ГОСТ-сертификатов такого требования нет ^[33].

Поддержка браузерами различается. Яндекс Браузер и приложение Яндекс, по данным компании, поддерживают зарубежные и отечественные TLS-сертификаты, включая НУЦ Минцифры ^[29]. Яндекс характеризует их как сертификаты, «обеспечивающие шифрование по отечественным протоколам» ^[28] — это формулировка вендора, а не описание всех типов. По данным Яндекса, в Chrome и Safari такие сайты вызывают предупреждение о небезопасном соединении ^[28].

Версии протоколов

Как применяется на практике

Переезд на HTTPS в Яндексе

Справка Яндекс Вебмастера предупреждает: робот воспринимает адреса с разными протоколами как разные сайты, которые могут конкурировать в выдаче, пока робот не объединит их в одну группу ^[17]. Порядок действий по справке ^[17]:

1. Получить и установить сертификат; проверить его инструментом «Проверка ответа сервера» — при ошибках SSL сервис покажет сообщение.
2. Заменить http на https во внутренних ссылках, адресах стилей, скриптов и изображений, в Sitemap, ссылке на Sitemap в robots.txt и в hreflang.
3. Открыть по HTTPS несколько страниц сайта и убедиться, что браузер сообщает о безопасном подключении.
4. Настроить редирект с каждой старой страницы на аналогичную новую — постоянный или временный, например с кодом 301 или 302. Главная перенаправляется на главную.
5. Добавить в Вебмастер обе версии сайта и в разделе «Индексирование → Переезд сайта» включить «Добавить HTTPS».

Перенаправлять все страницы на главную не следует — это замедлит индексацию ^[17]. Индекс качества сайта (ИКС) переносится, но верное значение может отобразиться не сразу ^[17]. Регионы сайта нужно задать заново: один регион задаётся в Вебмастере, дополнительные — через филиалы в Яндекс Бизнесе ^[17]. По данным Яндекса, при соблюдении рекомендаций трафик при переезде не теряется ^[17].

Переезд на HTTPS в Google

Документация Google относит HTTP→HTTPS к переездам со сменой URL ^[18]: нужно заранее настроить сертификаты, подтвердить в Search Console обе версии сайта, поставить постоянные редиректы (например, 301 или 308) и обновить Sitemap; инструмент «Изменение адреса» (Change of Address) для такого переезда не нужен ^[18].

Сравнение подходов Google и Яндекса

Канонический адрес

Google предпочитает HTTPS-страницы эквивалентным HTTP-страницам как канонические, кроме случаев, когда у HTTPS-страницы невалидный сертификат, есть небезопасные зависимости (кроме изображений), редирект на HTTP или через HTTP, либо rel="canonical" указывает на HTTP-версию ^[19]. При плохом сертификате или редиректе HTTPS→HTTP Google будет сильно предпочитать HTTP, и HSTS это не переопределит ^[19]. В Sitemap и hreflang нужно указывать HTTPS-адреса ^[19]. Подробнее — в статье «Канонический адрес».

HSTS

HTTP Strict Transport Security (RFC 6797) позволяет сайту объявить, что он доступен только по защищённому соединению: сервер отправляет заголовок Strict-Transport-Security ^[11]. Директива max-age задаёт в секундах, сколько браузер будет помнить это правило, includeSubDomains распространяет его на поддомены ^[11]. Пока правило действует, браузер сам заменяет схему http на https перед запросом ^[11], а при любой ошибке сертификата обрывает соединение без кнопки «Всё равно перейти» ^[11].

Есть и preload-список, встроенный в браузеры. Требования для включения через hstspreload.org: валидный сертификат; редирект с HTTP на HTTPS на том же хосте; все поддомены работают по HTTPS; заголовок на основном домене с max-age не меньше 31 536 000 секунд (1 год), includeSubDomains и preload ^[27]. Наращивать max-age сайт советует ступенями: 5 минут, неделя, месяц ^[27].

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

Смешанный контент — ресурсы, которые HTTPS-страница загружает по HTTP ^[25]. MDN делит его на два вида ^[25]:

• обновляемый (upgradable) — изображения, аудио, видео: браузер сам переводит запрос на HTTPS;
• блокируемый (blockable) — скрипты, стили, iframe, fetch(), XMLHttpRequest, веб-шрифты и всё остальное: браузер такой запрос блокирует.

Исправление — отдавать весь контент по HTTPS и сделать ссылки на собственные ресурсы относительными или HTTPS-ссылками ^[25]. Директива Content-Security-Policy upgrade-insecure-requests переводит все запросы страницы на HTTPS, включая блокируемый смешанный контент ^[25]. Предупреждения о смешанном контенте видны в консоли разработчика браузера ^[25].

Сроки действия сертификатов и автоматизация

11 апреля 2025 г. CA/Browser Forum принял бюллетень SC-081v3. Среди удостоверяющих центров 25 проголосовали «за», против — никто, 5 воздержались; все четыре разработчика браузеров — Apple, Google, Microsoft и Mozilla — проголосовали «за» ^[13]. График закреплён в Baseline Requirements (версия 2.3.1 от 4 октября 2026 г.) ^[12]:

Let's Encrypt, выдававший сертификаты на 90 дней, переходит на 45 дней ^[16]:

Let's Encrypt советует не продлевать сертификаты вручную, использовать механизм ARI (ACME Renewal Information), а без него — продлевать примерно на двух третях срока и настроить мониторинг ^[16]. Вывод: при сроках в 100 и 47 дней автоматический выпуск по ACME ^[10] становится необходимостью.

Пример (условный)

Пример условный. Интернет-магазин на http://shop.example выпускает сертификат через ACME-клиент хостинга, переводит ссылки и Sitemap на HTTPS, ставит постраничные 301-редиректы и сообщает о переезде в обеих панелях. Через неделю команда смотрит долю HTTPS-адресов в индексе, предупреждения о смешанном контенте в консоли, причины вроде «HTTPS has redirect» или «Sitemap points to HTTP» в отчёте Search Console ^[21] и работу автопродления.

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

Единой формулы «качества HTTPS» нет. Проверяют набор признаков.

В браузере. В консоли разработчика видны предупреждения о смешанном контенте ^[25].

В Яндекс Вебмастере. Инструмент «Проверка ответа сервера» показывает ошибки SSL-сертификата ^[17].

В Google Search Console. Отчёт HTTPS показывает число проиндексированных HTTPS- и HTTP-адресов и причины, по которым HTTPS-версия не показывается: невалидный сертификат, редирект HTTPS→HTTP, канонический тег на HTTP-странице, Sitemap со ссылкой на HTTP, блокировка в robots.txt ^[21]. Отчёт доступен для ресурсов типа «Домен» и HTTPS-ресурсов с префиксом URL и не является полным списком ^[21].

В командной строке. Утилита openssl s_client — универсальный TLS-клиент ^[30], а openssl x509 выводит даты действия, издателя и расширения сертификата ^[31]:

openssl s_client -connect example.ru:443 -servername example.ru -showcerts </dev/null
openssl s_client -connect example.ru:443 -servername example.ru </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -dates -ext subjectAltName
openssl x509 -in cert.pem -noout -checkend 1209600   # истекает ли в ближайшие 14 дней

Пример команд условный; синтаксис сверяйте с документацией OpenSSL своей версии ^[30][31].

Что мониторить: долю HTTPS-адресов в индексе, смешанный контент, дни до истечения сертификата, заголовок HSTS, версии TLS (1.0 и 1.1 запрещены ^[8]).

Мини-инструмент «Проверка HTTPS и сертификата сайта»

Как пользоваться.

Режим А — проверка домена. Введите домен без протокола. Инструмент показывает:

• открывается ли сайт по HTTPS и есть ли редирект с HTTP на HTTPS (код, число переходов); при цепочке — ссылка на статью «Цепочка редиректов», при редиректе внутренних страниц на главную — предупреждение со ссылкой на справку Яндекса ^[17];
• данные сертификата: издатель, даты действия, сколько дней осталось, есть ли домен в SAN, полна ли цепочка; тип DV/OV/IV/EV — только если он определяется по идентификатору политики ^[12];
• версии TLS с предупреждением о TLS 1.0/1.1 ^[8];
• заголовок Strict-Transport-Security и справочно — соответствие требованиям hstspreload.org ^[27];
• пояснение, если цепочка ведёт к корню НУЦ: такие сертификаты поддерживаются не всеми браузерами ^[28].

Режим Б — генераторы и калькулятор (работают в браузере). Генератор заголовка HSTS с предупреждениями о рисках preload и includeSubDomains ^[11][27]; генератор строки Content-Security-Policy: upgrade-insecure-requests ^[25]; калькулятор максимальной даты окончания сертификата по графику CA/Browser Forum (200/100/47 дней) ^[12]. Конкретный УЦ может выдавать сертификаты короче максимума ^[16].

Инструмент проверяет только транспортный уровень: он не оценивает «безопасность сайта» в целом, не прогнозирует позиции и не рекомендует УЦ.

Пример условный. Сертификат выпущен 1 октября 2026 г., действует правило «не более 200 дней». Baseline Requirements считают срок действия включительно — от notBefore до notAfter ^[12], поэтому последний допустимый день — около 18–19 апреля 2027 г. (точная дата зависит от времени выпуска). Сертификат, выпущенный начиная с 15 марта 2027 г., будет действовать не более 100 дней ^[12].

Ошибки, ограничения и спорные вопросы

Влияет ли HTTPS на позиции

Это главный спорный вопрос, и ответы поисковиков различаются.

• Google, исторически. В августе 2014 г. Google опубликовал в блоге для вебмастеров пост «HTTPS as a ranking signal» ^[22].
• Google, сейчас. Страница «Understanding page experience» (обновлена 22.09.2026) включает HTTPS в вопросы для самопроверки («Are your pages served in a secure fashion?») и одновременно пишет: «Beyond Core Web Vitals, other page experience aspects don't directly help your website rank higher in search results» («Кроме Core Web Vitals, другие аспекты удобства страницы напрямую не помогают сайту подняться выше в результатах поиска») ^[20]. Там же сказано, что единого сигнала page experience нет ^[20].
• Яндекс. Справка Вебмастера называет безопасность важным атрибутом качества для пользователя и пишет, что это «может быть учтено в ранжировании» ^[17].

Вывод: прямого заметного роста позиций от одного лишь HTTPS ожидать не стоит. Ощутимые эффекты косвенные: Google выбирает HTTPS-адрес каноническим ^[19], браузеры предупреждают о незащищённых HTTP-страницах ^[23], а при ошибке сертификата браузер вместо сайта показывает страницу-предупреждение ^[35], на HSTS-сайте — без возможности перейти дальше ^[11].

«HTTPS — значит, сайт безопасный»

Нет. HTTPS защищает канал, а сертификат DV подтверждает только контроль над доменом ^[17]. Команда Chrome в 2023 г. писала, что значок замка не говорит о надёжности сайта, а «nearly all phishing sites use HTTPS» («почти все фишинговые сайты используют HTTPS») ^[24]. По исследованию Google 2021 г. (данные исторические), точный смысл значка понимали лишь 11% участников ^[24]. Поэтому Google объявил, что в Chrome 117 (выход — начало сентября 2023 г.) замок в адресной строке заменят вариантом значка «tune», которым обычно обозначают элементы управления и настройки ^[24].

Ошибки при переезде

Типичные ошибки, описанные в справках поисковиков: редирект всех страниц на главную ^[17]; редирект с HTTPS обратно на HTTP, после которого Google может выбрать каноническим HTTP-адрес ^[19]; rel="canonical", hreflang и Sitemap со старыми адресами ^[17][19]; блокируемый смешанный контент ^[25]; невалидный сертификат или сертификат без нужного имени ^[19][21].

Риски HSTS

Включение includeSubDomains до того, как все поддомены переведены на HTTPS, делает их недоступными для браузеров, получивших правило ^[11]. Включение в preload-список трудно отменить: удаление занимает месяцы, пока изменение дойдёт до пользователей с обновлением Chrome ^[27].

Просроченный сертификат

Если срок действия сертификата истёк, браузер вместо сайта показывает страницу-предупреждение: в справке Firefox этот случай описан ошибкой SEC_ERROR_EXPIRED_CERTIFICATE, а часть предупреждений обойти нельзя ^[35]. На HSTS-сайте браузер обрывает соединение при любой ошибке сертификата и не даёт пользователю перейти дальше ^[11]. Для Google невалидный сертификат — одна из причин, по которым каноническим может стать HTTP-адрес ^[19][21]. С переходом на 100 и 47 дней число продлений в год растёт, и без автоматизации риск аварии увеличивается ^[12][16].

Терминологическая неточность

Название «SSL-сертификат» прижилось, хотя SSL 3.0 запрещён с 2015 г. ^[7]. Технически речь о сертификате X.509 ^[9], который используется в TLS. Энциклопедия использует привычное название, но фразы вроде «сайт работает по протоколу SSL» неверны.

Сертификаты НУЦ

Сайт только с сертификатом НУЦ часть аудитории откроет с предупреждением: по данным Яндекса, так происходит в Chrome и Safari ^[28], а Код.ру пишет, что «для зарубежных браузеров российские сертификаты доверенными не станут» ^[33].

Устаревающие сведения

График CA/Browser Forum и Let's Encrypt, номер актуального RFC TLS 1.3 (RFC 9846) проверены на 14.10.2026 ^[3][12][16]. Статистика Chrome 2018 г. и данные исследования Google 2021 г. — исторические ^[23][24]. Правила выдачи и прекращения действия сертификатов НУЦ на 14.10.2026, по данным СМИ, существуют в виде проектов ^[32][33]; по данным Код.ру, новая система сертификатов должна заработать с 1 марта 2027 г. ^[33].

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

Связанные термины

• 301-редирект
• Главное зеркало
• Зеркало сайта
• Канонический адрес (canonical)
• Цепочка редиректов
• Карта сайта (sitemap.xml)
• Коды ответа сервера
• Хостинг
• Core Web Vitals
• Индексация