SSL/TLS-сертификаты: как работают и что проверять

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

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

Вы открываете сайт, приложение вызывает API, сотрудник подключается к VPN. Перед обменом данными нужно удостовериться, что перед вами нужный сервер, а не подмена.

Четыре разных вопроса

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

Сертификат подтверждает связь ключа с идентичностью; сам по себе он не шифрует весь трафик и не выдаёт права в приложении. Разрешение читать отчёт или менять заказ относится к проверке авторизации API.

Что означает название SSL/TLS

«SSL-сертификат» — распространённое название сертификата для HTTPS. В современных соединениях используется TLS; SSL — название его предшественника. Сертификаты X.509 применяются и за пределами веб-сайтов: для клиентской аутентификации, сетевого доступа и других задач. Подпись документов — отдельный сценарий со своими требованиями; переносить на него правила HTTPS автоматически нельзя.

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

Открытый и закрытый ключ: что это значит

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

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

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

Почему одного открытого ключа мало

Вам прислали замок, а ключ остался у получателя. Можно закрыть сундук, не зная секрета. Но чей замок приехал? Если посредник подменил его своим, отправление получит посредник. Поэтому нужно удостоверить владельца открытого ключа. Аналогия объясняет задачу, а не алгоритм TLS.

Что находится внутри сертификата

Сертификат содержит открытый ключ, сведения о субъекте и издателе, серийный номер, срок, подпись и расширения. Для HTTPS имя проверяют по Subject Alternative Name (SAN), а не по произвольному названию записи. Правила — в RFC 9525 ↗.

На схеме — учебный сертификат для portal.example.org. Приватного ключа внутри нет: сервер хранит его отдельно и использует вместе с сертификатом.

Роль в цепочке и назначение сертификата

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

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

Расширение Key Usage ограничивает допустимые операции с ключом — например, создание цифровых подписей или проверку подписей сертификатов. Extended Key Usage (EKU), если присутствует, уточняет назначения применения: serverAuth означает подтверждение подлинности сервера, clientAuth — клиента. Если указаны оба расширения, применение должно соответствовать обоим. Программа учитывает эти ограничения вместе с остальными правилами проверки.

Подходящее назначение ещё не означает, что сертификат принят: отдельно проверяются срок, доверие, идентичность и другие применимые условия. Ограничения описаны в RFC 5280 ↗.

Кому доверяет проверяющая сторона

В нашем примере сертификат подписал заранее принятый издатель. Клиент проверяет подпись и применимые ограничения сертификата. Название организации в поле Issuer ещё не доказывает подлинность: нужна криптографическая проверка. Формат сертификата описан в RFC 5280 ↗.

Доверие настраивается отдельно. Предложение незнакомого сервера «принять моего издателя» не является основанием ему доверять. Результат зависит от принятых в конкретном клиенте опор доверия и правил их использования.

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

Чем отличаются DER, PEM и PKCS#12

Один и тот же сертификат может быть представлен в бинарном формате DER или текстовом PEM. PEM-представление сертификата содержит блок с заголовком BEGIN CERTIFICATE. Преобразование между этими представлениями не выпускает новый сертификат, не меняет его срок и не добавляет приватный ключ.

DER и PEM используются также для представления других криптографических объектов, поэтому одного названия формата или расширения файла недостаточно для определения содержимого. Текстовое представление сертификата описано в RFC 7468 ↗.

PKCS#12 — файловый контейнер, который может объединять сертификат, соответствующий приватный ключ и сертификаты издателей. Такие файлы часто имеют расширение .p12 или .pfx. Различие между сертификатом и контейнером сохраняется независимо от имени файла. В других системах ключевой контейнер криптопровайдера может иметь другое устройство и не являться одним файлом.

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

Контейнер может содержать только сертификаты, без закрытого ключа. Одного расширения файла недостаточно, чтобы определить состав. Если внутри есть закрытый ключ, файл содержит секрет: передача такого контейнера отличается от передачи открытого сертификата. Возможные состав и операции описаны в документации OpenSSL ↗.

Условия учебного примера

В учебном примере браузер открывает https://portal.example.org. TLS завершается непосредственно на веб-сервере: там доступны сертификат и соответствующий приватный ключ. Издатель сертификата заранее принят клиентом. В реальной системе вместо веб-сервера TLS может завершать прокси или балансировщик — тогда именно он предъявляет сертификат и использует ключ.

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

Что происходит при обычном TLS

1. Сервер предъявляет сертификат. Клиент проверяет имя по SAN, подпись принятого издателя, срок и применимые ограничения.
2. Сервер доказывает владение ключом. При новом сертификатном соединении TLS 1.3 он подписывает данные рукопожатия. Клиент проверяет подпись открытым ключом из сертификата.
3. Стороны защищают обмен. Данные передаются с использованием согласованных симметричных ключей сеанса. Затем приложение проверяет вход пользователя и его права.

Проверка двух подписей отвечает на разные вопросы:

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

Механизм CertificateVerify описан в актуальной спецификации TLS 1.3 — RFC 9846 ↗. На схеме показана проверка подлинности сервера, а не все сообщения протокола.

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

Как ключ превращается в удостоверение

1. Создают пару ключей. В нашем примере приватный ключ остаётся в защищённом хранилище сервера.
2. Готовят CSR. Это запрос на выпуск с открытым ключом и запрашиваемыми сведениями, ещё не сертификат.
3. Центр проверяет заявителя. Нужно подтвердить право получить сертификат с указанными именами и назначением.
4. Получают и устанавливают сертификат. Его связывают с соответствующим приватным ключом.
5. Проверяют реальное подключение. Наличия файла в каталоге недостаточно.

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

Что именно меняется при разных действиях

Изменение имени, срока или другого подписанного поля нарушает прежнюю подпись. «Исправить дату окончания» не означает продлить сертификат: для нового срока нужен выпуск нового сертификата. Ротация ключей дополнительно меняет саму пару ключей.

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

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

Успешное подключение и причины отказа

Результат относится к конкретному адресу, клиенту, предъявленному сертификату и настройкам проверки. Серийный номер вместе с издателем или отпечаток позволяет различить версии сертификата. Приватный ключ для описания результата не требуется.

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

У ошибки обычно есть конкретная сторона. «Unknown CA» направляет к настройкам доверия проверяющего; несовпадение имени — к адресу и SAN; срок — к датам сертификата и часам системы. Точный текст ошибки зависит от программы.

Отказ приложения после успешного TLS проверяют отдельно. Например, HTTP 403 может означать запрет операции; он сам по себе не доказывает ошибку сертификата. Причину устанавливают по журналу конкретной точки проверки и ответу приложения.

Частые вопросы о сертификатах

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

1. Сертификат скопировали на другой сервер. Этого достаточно? Нет: нужен соответствующий приватный ключ и успешные проверки клиента. Копирование контейнера с ключом меняет риск.
2. Срок не истёк, но издателю не доверяют. Почему сертификат отклонён? Действующий срок не заменяет доверия к издателю. Клиент может отклонить сертификат, если путь проверки не достигает принятой опоры доверия.
3. Исправили дату окончания. Это продление? Нет: изменённые данные нарушают подпись. Требуется новый сертификат, установленный и проверенный в соединении.
4. Удалили запись из каталога. Это отзыв? Нет: запись, копия на сервере и статус у издателя — разные состояния. Дополнительные действия определяет конкретная операция.
5. HTTPS работает, но изменить отчёт нельзя. Почему? TLS удостоверил сервер и защитил канал. Право менять отчёт определяет приложение.

Сертификат, доказательство владения ключом, настройки доверия и права приложения выполняют разные задачи. Фраза «сертификаты настроены» не описывает, какие из этих условий выполняются.

Успешное подключение при включённых проверках означает, что клиент принял предъявленное сервером удостоверение и подтверждение владения соответствующим ключом по своим правилам. Этот результат относится к конкретному адресу, программе и её настройкам. Другая программа может использовать другое хранилище доверия и получить отказ.

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

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

• Документирование интеграций и API
• Keycloak, OpenID Connect и LDAP
• Безопасность API

Роли корневого и промежуточного сертификатов раскрывает порядок проверки цепочки сертификатов. В разборе mTLS и взаимной проверки показано, как сервер проверяет сертификат клиента и владение его ключом.