SSL/TLS-сертификаты: зачем бизнесу управлять доверием в защищенном трафике

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

Почему сертификаты важны для бизнеса

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

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

Для бизнеса важны несколько взаимосвязанных задач:

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

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

Цифровой сертификат можно представить как электронное удостоверение сайта или сервиса. Чтобы разобраться, что такое SSL/TLS-сертификат, достаточно посмотреть, какие сведения он содержит:

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

По этим сведениям клиент проверяет, соответствует ли сертификат адресу подключения, кто его выпустил и можно ли доверять предъявленному открытому ключу.

Выражение «SSL/TLS-сертификат» объединяет привычное рыночное название и современный технический смысл. Сегодня корректнее говорить «сертификат для TLS-соединения», поскольку актуальные защищенные соединения строятся на TLS. При этом термин «SSL-сертификат» продолжает встречаться в интерфейсах, статьях, договорах и разговорной речи.

SSL- и TLS-сертификаты не являются двумя самостоятельными классами продуктов. Один и тот же сертификат формата X.509 может использоваться при установлении соединений по разным версиям TLS, если его параметры с ними совместимы. Безопасность соединения зависит не от слова SSL или TLS в названии, а от настроек клиента и сервера, версии протокола и корректной проверки цепочки доверия.

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

Разница между протоколами связана прежде всего с развитием технологий. Чтобы понять, чем отличается SSL от TLS, нужно учитывать, что SSL — историческое семейство протоколов, ранние версии которого больше не подходят для современной защиты. TLS стал дальнейшим развитием этого подхода и устранил ряд ограничений предшественника.

Наиболее распространенными остаются TLS 1.2 и TLS 1.3, а актуальная спецификация TLS 1.3 описана в RFC 9846. Протокол позволяет клиентским и серверным приложениям устанавливать соединения, защищенные от прослушивания, подмены данных и подделки сообщений. При этом фактический уровень защиты всегда зависит от реализации и настроек обеих сторон.

Как сертификат участвует в HTTPS-соединении

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

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

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

Базовая последовательность выглядит так:

• Пользователь открывает адрес сайта по HTTPS.
• Клиент и сервер обмениваются сведениями, необходимыми для согласования криптографических параметров и формирования ключевого материала.
• Сервер отправляет сертификат, а клиент выполняет проверку SSL/TLS-сертификата и цепочки доверия.
• Стороны завершают рукопожатие и формируют ключи защищенной сессии.
• Прикладные данные передаются по зашифрованному каналу.

Что проверяется

PKIPublic Key Infrastructure — инфраструктура открытых ключей, которая объединяет сертификаты, удостоверяющие центры и правила управления доверием. определяет правила выпуска, хранения, проверки и отзыва цифровых сертификатов. В типичной публичной схеме сертификат сайта подписывает промежуточный удостоверяющий центр, а его сертификат связан с корневым центром. Корневой сертификат заранее находится в доверенном хранилище операционной системы или браузера.

Проверяя TLS-сертификат, клиент оценивает несколько параметров:

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

Несоответствие хотя бы одному важному условию может привести к предупреждению или отказу от подключения.

Клиент также может проверить, не был ли сертификат отозван до окончания срока действия, например после компрометации закрытого ключа. Важно и то, как настроен сервер: он должен передавать полную цепочку промежуточных сертификатов и поддерживать совместимые версии TLS. Поэтому проверка SSL/TLS-сертификата не ограничивается контролем срока его действия.

Доверие шире шифрования

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

Екатерина Черкасова

PMM Solar webProxy

Какие бывают сертификаты

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

DV, OV и EV различаются объемом сведений, которые удостоверяющий центр проверяет перед выпуском. Тип проверки не задает отдельный алгоритм шифрования и сам по себе не делает соединение криптографически сильнее. За техническую стойкость отвечают версия TLS, алгоритмы, параметры ключей и корректная конфигурация.

Отдельно выделяют wildcard- и многодоменные сертификаты. Wildcard обычно охватывает поддомены одного уровня, например portal.example.ru и mail.example.ru, но не обязательно сам корневой домен или более глубокие уровни. Multidomain-сертификат содержит несколько явно перечисленных имен в поле SANSubject Alternative Name — поле сертификата, в котором перечисляются доменные имена или другие идентификаторы, для которых он действителен..

Для публично доверенных сертификатов важен и срок действия. С 15 марта 2026 года максимальный период действия нового конечного серверного сертификата по требованиям CA/Browser Forum составляет 200 дней. Сокращение срока повышает значимость автоматизированного учета и своевременного перевыпуска, однако эти правила нельзя автоматически переносить на внутреннюю корпоративную PKI.

Почему сертификат не гарантирует безопасность сайта

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

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

Зачем управлять сертификатами и доверием

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

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

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

При слабом контроле возникают характерные проблемы:

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

Даже когда интернет-трафик защищен с помощью TLS, соединение может вести к облачному хранилищу, мессенджеру или приложению, не согласованному с ИТ- и ИБ-службами. Через такие сервисы сотрудники могут передавать корпоративные сведения или использовать неизвестное ПО.

Выведите сервисы из HTTPS-тени. Получите руководство «Как бороться с Shadow IT» и узнайте, как провести инвентаризацию, категоризировать веб-ресурсы, обновить модель угроз и применять организационные и технические меры контроля.

Скачать руководство

Как SWG помогает контролировать защищенный трафик

SWGSecure Web Gateway — шлюз веб-безопасности, который контролирует доступ пользователей к интернет-ресурсам и применяет политики к веб-трафику. находится между корпоративным пользователем и внешними веб-ресурсами и применяет к соединениям правила безопасности. При принятии решения система может учитывать:

• Пользователя и его группу.
• Категорию сайта.
• Репутацию домена или адреса.
• Тип выполняемой операции.
• Другие условия, заданные политикой компании.

Это позволяет разрешать необходимые сервисы и ограничивать ресурсы, которые не соответствуют требованиям безопасности.

Один из механизмов такого контроля — инспекция TLS-трафика. При ее применении шлюз создает отдельное защищенное соединение с внешним сервером и отдельное соединение с корпоративным клиентом. Между ними содержимое можно проверить по заданным правилам, после чего разрешенные данные снова передаются в зашифрованном виде.

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

Важно различать несколько механизмов контроля:

• Проверка сертификата определяет, можно ли доверять цифровой идентичности ресурса.
• Инспекция анализирует данные внутри установленного защищенного соединения.
• Категоризация определяет тип и назначение веб-ресурса.
• Репутационная проверка помогает оценить известные риски домена или адреса.
• Журналирование сохраняет сведения для диагностики и расследования инцидентов.

Роль Solar webProxy

Solar webProxyРоссийская система Secure Web Gateway для контроля доступа к веб-ресурсам и защиты корпоративного веб-трафика. — шлюз веб-безопасности для управления доступом сотрудников к интернет-ресурсам и контроля корпоративного веб-трафика. Система позволяет:

• Фильтровать HTTP(S)-запросы и ответы.
• Применять политики доступа к отдельным пользователям и группам.
• Проводить SSL/TLS-инспекцию, включая трафик TLS 1.3.
• Определять приложения и протоколы в расшифрованном HTTPS-трафике с помощью DPI.
• Контролировать загрузку и отправку файлов.

При соответствующей настройке Solar webProxy анализирует содержимое защищенного трафика, блокирует файлы, признанные вредоносными по результатам проверки или запрещенные политикой, и ограничивает нежелательные ресурсы и соединения. Архитектура включает антивирусную проверку веб-трафика и контроль MIME-типов. По протоколу ICAP HTTP-запросы и ответы, включая передаваемые файлы, можно направлять во внешние DLP-системы, антивирусы и песочницы, а события — в SIEM по Syslog для анализа и расследования.

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

Возьмите защищенный веб-трафик под контроль

Применяйте единые политики доступа к веб-ресурсам с помощью Solar webProxy. Контролируйте защищенные соединения и действия пользователей при работе с веб-ресурсами.

Запросить демонстрацию

Что важно запомнить

Каждый SSL/TLS-сертификат решает ограниченную, но важную задачу: помогает проверить цифровую идентичность ресурса и установить доверенное соединение. Шифрование защищает данные в пути от просмотра и незаметного изменения. Однако оно не проверяет содержимое страницы и не подтверждает добросовестность владельца.

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

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

Часто задаваемые вопросы