TLS или SSL: что выбрать?

Выбирайте TLS: это современный протокол защиты данных при передаче по сети. SSL — устаревшее семейство протоколов; SSL 2.0 и SSL 3.0 не следует включать в рабочих конфигурациях. Термины «SSL-сертификат» и «цепочка SSL-сертификатов» часто сохраняются в интерфейсах, но обычно означают сертификаты, используемые для TLS.

Можно ли использовать самоподписанный SSL-сертификат?

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

Что такое OCSP stapling?

OCSP stapling — механизм, при котором сервер заранее получает подписанный OCSP-ответ о статусе сертификата и передаёт его клиенту во время TLS-рукопожатия. Это может сократить обращения клиентов к OCSP-респондеру. Однако не все клиенты обязаны запрашивать, получать или одинаково обрабатывать такой ответ.

Есть ли в PFX-сертификате закрытый ключ?

Да, контейнер PFX, или PKCS#12, может содержать закрытый ключ, сертификат владельца и сертификаты цепочки. Обычно такой бинарный контейнер защищён паролем и удобен для переноса. Перед импортом или передачей нужно выяснить состав PFX и способ защиты: закрытый ключ нельзя отправлять по незащищённым каналам или хранить рядом с общедоступными сертификатами.

Что такое mTLS и достаточно ли сертификата клиента для доступа?

mTLS — это двусторонний TLS: клиент проверяет сертификат сервера, а сервер запрашивает и проверяет сертификат клиента. Нет, успешная проверка сертификата клиента не означает автоматический доступ. Сервер должен сопоставить сертификат с субъектом и применить правила авторизации для действий, ресурсов и ролей.

TLS-сертификаты на сервере: как работают и какой выбрать

Q: Что такое CSR и заменяет ли он сертификат?

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

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

TLS, SSL и сертификат — разные вещи

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

SSL — предшествующее TLS устаревшее семейство протоколов. Выражения «SSL-сертификат», «SSL certificate trusted» и «цепочка сертификатов SSL» всё ещё встречаются в интерфейсах, документации и маркетинге, но обычно означают сертификат для TLS. SSL 2.0 и SSL 3.0 не следует включать в рабочих конфигурациях.

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

TLS 1.2 или TLS 1.3

TLS 1.2 и TLS 1.3 — версии протокола, а не типы сертификатов. Поддерживаемые версии, алгоритмы и настройки зависят от TLS-терминатора, криптобиблиотеки, ОС и политики организации. Выбор версий и наборов шифров рассматривается отдельно в статье «Hardening TLS: версии протокола, cipher suites и проверка слабых настроек».

Что находится в сертификате и в закрытом ключе

Сертификат X.509 — публичный документ. В типичном серверном сертификате есть открытый ключ, сведения о субъекте и издателе, период действия, серийный номер, расширения, назначение ключа и цифровая подпись издателя. Набор и смысл полей определяют профиль сертификата, политика центра сертификации и правила клиента.

Разделение публичных и секретных данных

Объект	Что содержит	Кому доступен
Сертификат	Открытый ключ, идентификаторы, срок действия, издатель, расширения и подпись	Серверу, клиентам и обычно любому, кто получает сертификат
Закрытый ключ	Секретный материал ключевой пары, которым сервер подтверждает владение ключом	Только уполномоченному владельцу или компоненту, завершающему TLS
Цепочка CA	Промежуточные и иногда другие сертификаты центров сертификации	Передаётся клиенту вместе с серверным сертификатом, кроме доверенного корня в обычной схеме

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

Закрытый ключ — секрет

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

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

Цепочка сертификатов связывает серверный сертификат с точкой доверия клиента. Типичная схема выглядит так: клиент ← серверный сертификат ← промежуточный сертификат CA ← корневой сертификат, уже установленный в хранилище доверенных сертификатов клиента.

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

Согласно модели TLS 1.3 из RFC 8446, сервер передаёт список сертификатов certificate_list; в распространённой конфигурации это конечный сертификат и промежуточные CA. Корневой сертификат обычно не передают: клиент берёт его из собственного хранилища доверия. Отправка корня, как правило, не создаёт доверие, если этого корня в хранилище клиента нет.

RFC 5280 задаёт профиль X.509 и алгоритм проверки заданного пути сертификации, но не универсальный алгоритм поиска и построения такого пути. Конкретный клиент строит путь средствами своей реализации и может применять дополнительные ограничения. Например, при проверке учитываются допустимость CA для выпуска сертификатов, ограничения пути, назначения ключа, критические расширения и криптографические алгоритмы.

Почему действующий сертификат всё равно не принимают

Неистёкший срок — только одна из проверок. Клиент обычно проверяет подписи и путь доверия, период действия, имя сервиса, назначение ключа, ограничения CA, допустимость алгоритмов и, когда это применимо, статус отзыва. Политики браузеров, ОС, библиотек и прикладных клиентов могут различаться.

Типовые причины ошибок доверия

Сообщение или симптом	Что это обычно означает	Что проверить
`untrusted` / `certificate not trusted`	Клиент не нашёл доверенную точку цепочки или не принимает её по своей политике	Есть ли нужный корень в trust store клиента, верны ли подписи и ограничения CA
`chain incomplete` / `unable to verify certificate`	Сервер не отдал нужный промежуточный сертификат либо цепочка построена неверно	Полный набор промежуточных сертификатов на TLS-терминаторе и порядок, ожидаемый его ПО
`hostname mismatch`	Имя, по которому подключился клиент, не соответствует идентификатору в сертификате	Наличие DNS-имени или IP-адреса в Subject Alternative Name
Ошибка при действующих датах	Не подходит назначение ключа, алгоритм, политика CA или проверка отзыва	Расширения Key Usage и Extended Key Usage, алгоритмы, ограничения клиента и доступность механизмов статуса

Для проверки имени современные правила ориентируются прежде всего на Subject Alternative Name (SAN), как описано в RFC 9525. Для DNS-имени ищут соответствующий DNS SAN, для подключения по IP-адресу — IP SAN. Поле Common Name может присутствовать, но полагаться на него как на универсальный механизм сопоставления имени нельзя: поведение устаревших и специализированных клиентов различается.

Ошибку нужно проверять на фактической точке TLS

Сертификат может завершаться на прокси, балансировщике, CDN, BMC или самом приложении, а не там, где администратор менял конфигурацию. Пошаговая диагностика expired, chain incomplete, mismatch и ошибок проверки приведена в статье «Ошибки SSL/TLS-сертификатов: expired, chain incomplete и mismatch».

Публичный сертификат, внутренний CA или самоподписанный

Центр сертификации выпускает сертификаты и подписывает их, подтверждая связь ключа с заявленной идентичностью в рамках своей процедуры. Главное различие вариантов — не «сила шифрования», а способ, которым клиент получает основание доверять издателю.

Выбор модели доверия

Вариант	Когда выбирать	Что должен сделать клиент	Ограничение
Публично доверенный сертификат	Сайт или сервис доступен произвольным внешним пользователям, браузерам, устройствам и API-клиентам	Использовать уже доверенные публичные корни в своём хранилище	Публичный CA выпускает сертификаты только для идентичностей, которые может проверить по своей процедуре
Внутренний CA	Корпоративные сервисы, устройства и приложения, чьими trust store организация управляет	Получить и доверять корневому сертификату внутреннего CA через управление устройствами, ОС или приложение	Нужно безопасно распространять корень, управлять жизненным циклом CA и поддерживать доверие на всех клиентах
Самоподписанный сертификат	Небольшой изолированный контур, лаборатория, временный сервис или отдельное устройство, где доверие можно установить и сопровождать явно	Заранее проверить и установить конкретный сертификат или его публичный ключ как доверенный	Не подходит для произвольных клиентов: предупреждение нельзя считать безопасной проверкой личности

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

Публичный сертификат не делает сервис безопасным сам по себе: он не заменяет контроль доступа, обновления, безопасную TLS-политику и ограничение сетевой экспозиции. Для интерфейсов BMC особенно важно сочетать контролируемое доверие к сертификату с изолированной сетью управления; это разобрано в статье «Защита BMC: безопасная настройка iDRAC, iLO и отдельной сети управления».

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

CSR: запрос на выпуск, а не сертификат

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

Администратор создаёт CSR вручную, когда ключ должен остаться на конкретном сервере, в аппаратном модуле безопасности, на балансировщике или когда CA принимает запрос через портал.
Клиентское или автоматизированное ПО формирует CSR само, когда оно управляет выпуском и установкой сертификата: например, в схеме ACME или через корпоративный агент.
CA выполняет проверку идентичности отдельно от CSR: право на доменное имя, организационные данные или другую идентичность проверяются процедурой конкретного CA.

Автоматизированный выпуск, ACME-проверки, wildcard-сертификаты и автопродление не меняют модель доверия: они автоматизируют получение и сопровождение сертификата. Практические действия для Let’s Encrypt описаны в статье «Let’s Encrypt на Linux: выпуск, установка и автопродление».

PEM, DER и PFX/PKCS#12: форматы файлов

PEM, DER и PKCS#12 не являются разными типами доверия или разными видами TLS-сертификата. Это способы представления сертификатов, ключей и связанных объектов. Поддержка импорта конкретного контейнера зависит от продукта и его версии.

PEM и DER: разница, а также PFX/PKCS#12

Формат	Представление	Типичное содержимое	Практическое замечание
PEM	Текст Base64 с блоками `BEGIN`/`END`	Один или несколько сертификатов, открытый или закрытый ключ, CSR	Удобен для конфигурационных файлов и просмотра; расширение файла не гарантирует содержимое
DER	Бинарное ASN.1 DER-представление	Обычно один сертификат или другой ASN.1-объект	Часто используется там, где приложение ожидает бинарный объект; это не контейнер цепочки и ключа в общем случае
PKCS#12, также PFX	Бинарный контейнер, обычно защищённый паролем	Закрытый ключ, сертификат владельца и сертификаты цепочки	Удобен для переноса, но требует особенно осторожного обращения: в нём может находиться закрытый ключ

PFX может содержать закрытый ключ

Перед передачей или импортом PKCS#12 выясните, включает ли контейнер ключ и как он защищён паролем. Не отправляйте PFX через незащищённые каналы и не храните его рядом с общедоступными сертификатами. Конкретные допустимые форматы, параметры импорта и расположение файлов определяются ОС, TLS-сервером, способом развёртывания и версией ПО.

mTLS: сертификат предъявляет и клиент

mTLS, или двусторонний TLS, — режим, при котором клиент проверяет сертификат сервера, а сервер запрашивает и проверяет сертификат клиента. Его применяют для взаимодействия сервисов, устройств, корпоративных клиентов и административных API, когда сертификат может служить идентификатором клиента.

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

CRL, OCSP и OCSP stapling: как узнают об отзыве

Отзыв сертификата позволяет CA прекратить доверие к сертификату до окончания его срока действия. Это может потребоваться, например, при компрометации ключа или ошибке выпуска. Сведения об отзыве могут публиковаться как список отзыва сертификатов (CRL) или выдаваться через OCSP.

CRL — подписанный CA список отозванных сертификатов. Клиент или другое средство получает и проверяет список, затем ищет в нём серийный номер сертификата.
OCSP — запрос статуса конкретного сертификата к OCSP-респондеру. Его модель и статусы определены RFC 6960.
OCSP stapling — сервер заранее получает подписанный OCSP-ответ и передаёт его клиенту в ходе TLS-рукопожатия. В TLS это связано с расширением status_request; механизм описан в RFC 6066 и RFC 8446.

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

Что проверять в конкретном продукте

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

Термины в статье

CSR: CSR — запрос на выпуск сертификата, содержащий открытый ключ и сведения о субъекте, подписанные соответствующим закрытым ключом для подтверждения владения ключевой парой.
OCSP: OCSP — сетевой протокол для запроса статуса отдельного X.509-сертификата у OCSP-респондера без загрузки списка отозванных сертификатов (CRL).
PEM: PEM — текстовый формат представления криптографических объектов в Base64 между строками BEGIN/END с меткой типа объекта; он не задаёт алгоритм шифрования или тип ключа.
PKCS#12: PKCS#12 — бинарный контейнер для закрытого ключа, сертификата и цепочки УЦ, обычно защищаемый паролем; файлы формата имеют расширения .p12 или .pfx.
SSL: SSL — устаревшее семейство протоколов защиты сетевых соединений, предшествующее TLS; версии SSL 2.0 и SSL 3.0 не следует включать в рабочих конфигурациях.
Subject Alternative Name: Subject Alternative Name — расширение X.509-сертификата, содержащее DNS-имена, IP-адреса, URI и другие идентификаторы, с которыми связывается открытый ключ.
TLS: TLS — криптографический протокол защиты прикладных данных при передаче по сети, обеспечивающий их конфиденциальность и целостность, а также аутентификацию сервера и, при настройке, клиента.
mTLS: mTLS — режим TLS, в котором сервер и клиент подтверждают личности сертификатами X.509, а не только сервер предъявляет сертификат клиенту.
Закрытый ключ: Закрытый ключ — секретная часть асимметричной ключевой пары для создания подписей, расшифрования данных или подтверждения владения ключом при аутентификации.
Корневой сертификат: Корневой сертификат — самоподписанный сертификат центра сертификации, служащий верхней точкой доверия при проверке цепочек сертификатов.
Отзыв сертификата: Отзыв сертификата — прекращение доверия к действующему сертификату до истечения его срока, фиксируемое центром сертификации в CRL или через OCSP.
Открытый ключ: Открытый ключ — несекретный ключ асимметричной пары, используемый в зависимости от алгоритма для проверки подписей, шифрования, аутентификации или согласования общего секрета.
Промежуточный сертификат: Промежуточный сертификат — подписанный вышестоящим CA сертификат подчинённого центра, чей открытый ключ используется для проверки выпущенных им сертификатов в цепочке доверия.
Сертификат TLS: Сертификат TLS — цифровой документ X.509, содержащий открытый ключ и идентификаторы субъекта и подписанный издателем; доверие к связи определяется цепочкой и политикой клиента.
Сертификат X.509: Сертификат X.509 — цифровой документ стандартизированного формата, связывающий открытый ключ с субъектом и подписанный издателем: центром сертификации или самим субъектом.
Сертификат клиента: Сертификат клиента — цифровой сертификат X.509, идентифицирующий пользователя, устройство или сервис при взаимной TLS-аутентификации перед сервером.
Список отзыва сертификатов: Список отзыва сертификатов — подписанный издателем CRL перечень сертификатов, признанных недействительными до истечения срока их действия.
Хранилище доверенных сертификатов: Хранилище доверенных сертификатов — набор сертификатов и правил доверия, используемый системой или приложением при проверке цепочек сертификатов и цифровых подписей.
Центр сертификации: Центр сертификации — доверенная организация или сервис PKI, выпускающий и подписывающий сертификаты, чтобы связать открытые ключи с проверенными идентификаторами субъектов.
Цепочка сертификатов: Цепочка сертификатов — последовательность от конечного сертификата через сертификаты центров сертификации к точке доверия, позволяющая проверить подписи и построить путь доверия.