Перейти к основному содержимому

7.07. Сертификация и сертификаты

В РАЗРАБОТКЕНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНО
Разработчику Инженеру

Сертификация​

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

Сертификация — это не просто техническая процедура; это социально-техническая система, в которой участвуют три базовых актора:

  1. Субъект сертификации — сторона, чья идентичность (или атрибуты) должны быть подтверждены. Например, веб-сервер, программное обеспечение, пользователь, устройство.
  2. Удостоверяющий центр (Certificate Authority, CA) — доверенная третья сторона, уполномоченная подтверждать идентичность субъекта и выдавать цифровые документы (сертификаты), заверенные своей криптографической подписью.
  3. Верификатор (полагающаяся сторона, relying party) — сторона, которая принимает решение о доверии на основе проверки сертификата. Например, браузер, почтовый клиент, API-шлюз, клиентское приложение.

Процесс сертификации начинается с генерации пары криптографических ключей — открытого и закрытого — на стороне субъекта. Закрытый ключ никогда не покидает владение субъекта и используется исключительно для создания цифровых подписей или расшифровки данных. Открытый ключ, напротив, предназначен для распространения и встраивается в запрос на выпуск сертификата (Certificate Signing Request, CSR). В этом запросе также указываются идентификационные данные: доменное имя, наименование организации, страна и другие атрибуты.

CSR направляется удостоверяющему центру. CA проверяет достоверность предоставленной информации в соответствии со своей политикой сертификации (Certification Practice Statement, CPS). Уровень проверки может варьироваться: от простого подтверждения контроля над доменом (Domain Validation, DV) до строгой верификации юридического лица и его физического адреса (Extended Validation, EV). После успешной проверки CA генерирует цифровой сертификат — структурированный документ, содержащий открытый ключ субъекта и его идентификационные данные, заверенный цифровой подписью самого центра.

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

Когда клиент (например, веб-браузер) устанавливает соединение с сервером по протоколу HTTPS, сервер представляет свой сертификат. Клиент проверяет его, опираясь на заранее установленные доверенные корневые сертификаты (root certificates), встроенные в операционную систему или браузер. Эта проверка включает:

  • контроль срока действия сертификата;
  • сопоставление доменного имени в сертификате с запрашиваемым URL;
  • проверку целостности цифровой подписи (через цепочку доверия до корневого CA);
  • проверку статуса отзыва сертификата (через OCSP или CRL).

Если хотя бы один из этих этапов завершается неудачей, соединение считается ненадёжным, и браузер выдаёт предупреждение. Это — проявление модели нулевого доверия (zero trust): доверие не предполагается, оно доказывается каждый раз на основе криптографических свидетельств.

Сертификация — это, по сути, инструмент распределённого доверия. В отличие от централизованных систем контроля доступа (например, единой базы пользователей в домене Active Directory), сертификация работает в открытой, децентрализованной среде, где участники не обязаны находиться в едином административном домене. Именно поэтому она лежит в основе не только HTTPS, но и таких технологий, как S/MIME для электронной почты, кодовая подпись (code signing), аутентификация устройств в IoT, защищённые API (mTLS), и даже государственные системы электронной идентификации (например, ЕСИА в России или eIDAS в Европе).

Однако сертификация — не панацея. Она эффективна только при соблюдении нескольких условий:

  • Конфиденциальность закрытого ключа. Если злоумышленник получает закрытый ключ, он может выдавать себя за владельца сертификата — даже если сам сертификат остаётся валидным. Именно поэтому ключи хранятся в защищённых средах: аппаратных модулях безопасности (HSM), доверенных платформенных модулях (TPM), изолированных контейнерах.
  • Целостность инфраструктуры удостоверяющего центра. Компрометация CA — событие катастрофического масштаба, поскольку позволяет выдавать поддельные сертификаты на любые домены. История знает такие инциденты (DigiNotar, 2011; WoSign, 2016), после которых браузеры вынуждены были отозвать доверие к целым цепочкам сертификации.
  • Актуальность проверок отзыва. Сертификат может быть отозван досрочно (например, при утечке закрытого ключа), но если клиент не проверяет статус отзыва, он может принять скомпрометированный сертификат как действительный. Современные браузеры всё чаще применяют OCSP stapling, чтобы снизить задержки и усилить конфиденциальность при такой проверке.

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

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

Что такое сертификат​

Цифровой сертификат — это стандартизированный криптографический документ, призванный нести в себе достаточную информацию для однозначного установления связи между субъектом (entity) и его открытым ключом, а также для проверки подлинности этого утверждения. Де-факто стандартом для таких документов в большинстве современных систем является X.509, разработанный в рамках рекомендаций Международного союза электросвязи (ITU-T). Версии X.509 v1, v2, v3 используются последовательно, причём v3 — текущая и наиболее распространённая, благодаря поддержке расширений (extensions), без которых невозможна гибкая настройка политик использования.

Основные поля X.509-сертификата (v3)​

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

1. Информация о субъекте (Subject)​

Это набор атрибутов, однозначно идентифицирующих владельца сертификата. В контексте веб-сервера это, как правило, доменное имя, но может включать и дополнительные данные:

  • Common Name (CN) — исторически использовалось для указания домена (например, example.com). Однако в современных стандартах (RFC 6125) CN не рекомендуется использовать для валидации имён, поскольку основной механизм — это расширение Subject Alternative Name (SAN).
  • Organization (O) — наименование организации (например, ООО "Рога и Копыта").
  • Organizational Unit (OU) — подразделение внутри организации (например, ИТ-отдел).
  • Locality (L), State (ST), Country (C) — географические атрибуты.
  • Email Address, Serial Number и другие — в зависимости от типа сертификата.

Для EV-сертификатов (Extended Validation) эта секция особенно насыщенна и проходит строгую проверку: указываются юридическое название, регистрационный номер, юрисдикция, физический адрес.

2. Информация об издателе (Issuer)​

Аналогичная структура, но описывает удостоверяющий центр, подписавший сертификат. Например:
C=US, O=Let's Encrypt, CN=R3 — говорит о том, что сертификат выдан промежуточным центром Let’s Encrypt с именем R3.

3. Период действия​

Содержит два временных маркера:

  • Not Before — дата и время, начиная с которых сертификат считается действительным.
  • Not After — дата и время окончания действия.

Эти значения задаются в формате UTC (всегда — без временных зон) и строго проверяются клиентом. Даже небольшое рассогласование часов (например, на 5 минут вперёд на клиенте при ещё не наступившем Not Before) приведёт к отказу в установке соединения.

Краткосрочность срока действия — сознательная мера безопасности. Let’s Encrypt, например, устанавливает срок в 90 дней, что снижает риски при компрометации ключа и побуждает к автоматизации управления сертификатами.

4. Открытый ключ субъекта​

Самая критически важная часть. Здесь хранится:

  • алгоритм (например, RSA, ECDSA, Ed25519);
  • параметры (длина ключа — 2048, 3072, 4096 бит для RSA; тип кривой — secp256r1, secp384r1 для ECDSA);
  • само значение открытого ключа в двоичной форме.

Открытый ключ используется клиентом для:

  • проверки цифровых подписей, сделанных владельцем сертификата;
  • шифрования данных, которые только владелец (с закрытым ключом) сможет расшифровать (в TLS — для передачи предварительного секрета);
  • установления общего сеансового ключа в рамках протокола обмена ключами (например, ECDHE).

5. Уникальные идентификаторы (необязательно)​

  • Subject Key Identifier (SKI) — хэш открытого ключа субъекта, используется для быстрого поиска соответствующего закрытого ключа при наличии нескольких.
  • Authority Key Identifier (AKI) — хэш открытого ключа издателя, позволяет быстро определить, какой промежуточный сертификат должен использоваться для проверки подписи.

6. Расширения (Extensions) — ключевая особенность X.509 v3​

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

  • Basic Constraints — указывает, является ли сертификат CA-сертификатом (может ли он подписывать другие сертификаты). Для конечных (серверных, клиентских) сертификатов значение CA:FALSE.

  • Key Usage — определяет, для каких криптографических операций разрешено использовать ключ. Например:

    • digitalSignature — подпись данных;
    • keyEncipherment — шифрование ключей (для RSA);
    • keyAgreement — участие в протоколах согласования ключей (например, ECDH);
    • dataEncipherment, keyCertSign, cRLSign — для специализированных случаев.

  • Extended Key Usage (EKU) — уточняет конкретные сценарии применения. Например:

    • serverAuth (OID 1.3.6.1.5.5.7.3.1) — аутентификация сервера (HTTPS);
    • clientAuth (1.3.6.1.5.5.7.3.2) — аутентификация клиента (mTLS);
    • codeSigning — подпись программного кода;
    • emailProtection — S/MIME;
    • timeStamping — сервисы временных меток.

Браузер может отклонить сертификат, если он не содержит нужный EKU, даже если все остальные проверки пройдены.

  • Subject Alternative Name (SAN) — наиболее важное расширение для веб-сертификатов. Содержит список имён, для которых сертификат действителен:
    • DNS-имена (DNS:example.com, DNS:www.example.com, DNS:*.api.example.com);
    • IP-адреса (IP:192.0.2.1);
    • URI, email и др.

Современные браузеры игнорируют поле Common Name, если присутствует SAN — и наоборот, если SAN отсутствует, поведение может быть непредсказуемым (вплоть до отказа в соединении). Поэтому SAN обязателен даже для однодоменных сертификатов.

  • Certificate Policies — ссылки на политики сертификации CA (OID и URL), позволяют автоматизированным системам проверять соответствие требованиям (например, для EV-сертификатов — наличие политики 2.23.140.1.1).

  • CRL Distribution Points и Authority Information Access (AIA) — указывают, где находятся списки отозванных сертификатов (CRL) и OCSP-серверы CA. Например:

    AIA: OCSP - URI:http://r3.o.lencr.org
    AIA: CA Issuers - URI:http://r3.i.lencr.org/

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

7. Подпись CA​

Завершающая часть — криптографическая подпись всего содержимого сертификата (за исключением самой подписи), вычисленная с использованием закрытого ключа издателя. Алгоритм подписи (например, sha256WithRSAEncryption, ecdsa-with-SHA384) должен быть совместим с возможностями клиента.

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

Форматы представления: PEM, DER, PKCS#7, PKCS#12​

Сертификат — это структура данных, описанная в нотации ASN.1 (Abstract Syntax Notation One). Однако ASN.1 сама по себе — лишь метаязык описания структур. Для хранения и передачи используются конкретные кодировки:

1. DER (Distinguished Encoding Rules)​

— бинарная, каноническая кодировка ASN.1. Компактна, однозначна, неизменяема. Используется в операционных системах (например, Windows хранит сертификаты в реестре в DER), в Java KeyStore (JKS), в некоторых API. Файлы обычно имеют расширение .cer, .crt, .der.

2. PEM (Privacy-Enhanced Mail)​

— текстовый формат, представляющий собой DER, закодированный в Base64 и обрамлённый строками:

-----BEGIN CERTIFICATE-----
MIIF... (много строк Base64)
-----END CERTIFICATE-----

Может содержать один или несколько сертификатов (например, серверный + промежуточные), а также закрытые ключи (в блоках BEGIN PRIVATE KEY или BEGIN RSA PRIVATE KEY). Широко используется веб-серверами (Nginx, Apache), утилитами OpenSSL, системами оркестрации (Kubernetes Secrets). Легко копируется, вставляется, редактируется в текстовом редакторе — но требует корректного форматирования (переносы строк, отсутствие лишних пробелов).

3. PKCS#7 / CMS (Cryptographic Message Syntax)​

— контейнер для передачи цепочки сертификатов (без закрытых ключей). Часто используется в Windows при экспорте сертификатов. Файлы: .p7b, .p7c. Содержит только сертификаты и CRL, подходит для распространения публичных данных.

4. PKCS#12 (ранее PFX)​

— зашифрованный контейнер, содержащий и сертификат, и соответствующий закрытый ключ, а также, при необходимости, всю цепочку доверия. Файлы: .p12, .pfx. Используется для переноса учётных данных между системами — например, при развёртывании сервера или импорте клиентского сертификата в браузер. Защита контейнера осуществляется паролем (хотя и возможен пустой пароль, что небезопасно).

Жизненный цикл сертификата​

Сертификат проходит несколько фаз:

  1. Генерация ключевой пары
    Выполняется на стороне владельца (не на CA!). Закрытый ключ никогда не передаётся третьим лицам. Рекомендуется использовать аппаратную защиту (HSM/TPM) для критически важных систем.

  2. Формирование CSR (Certificate Signing Request)
    Содержит открытый ключ и идентификационные данные, подписывается закрытым ключом — это доказывает, что заявитель действительно владеет ключом.

  3. Верификация CA
    В зависимости от типа:

    • DV (Domain Validation) — подтверждение контроля над доменом (через DNS-запись, HTTP-файл, email на admin@, webmaster@ и др.).
    • OV (Organization Validation) — проверка существования организации по официальным реестрам.
    • EV (Extended Validation) — углублённая проверка по стандарту CA/Browser Forum, включая звонки, документы, подтверждение полномочий.

  4. Выпуск и подпись
    CA формирует сертификат, включая расширения, и подписывает его закрытым ключом промежуточного CA.

  5. Развертывание
    Сертификат (и промежуточные) устанавливаются на сервер. Важно: клиент должен получить полную цепочку, иначе проверка провалится. Серверный сертификат — первый в файле, затем — промежуточные (в порядке от листового к корневому). Корневой сертификат не включается — он должен быть уже у клиента.

  6. Мониторинг и обновление
    Сертификаты требуют отслеживания срока действия. Ручное обновление ошибочно и рискованно — используются автоматизированные системы: Certbot (для Let’s Encrypt), HashiCorp Vault, step-ca, внутренние CA на базе Windows AD CS или smallstep.

  7. Отзыв
    Если закрытый ключ скомпрометирован, владелец запрашивает отзыв у CA. CA публикует информацию об этом в:

    • CRL (Certificate Revocation List) — подписанный список отозванных сертификатов (серийные номера + даты);
    • OCSP (Online Certificate Status Protocol) — протокол для онлайн-запроса статуса по серийному номеру.

Современные системы стремятся к отказу от CRL в пользу OCSP stapling: сервер сам запрашивает статус у OCSP-резондера CA и «прикрепляет» (staple) ответ к TLS-рукопожатию — это снижает задержки и повышает приватность (браузеру не нужно обращаться к CA).

  1. Истечение срока действия
    После Not After сертификат становится недействительным. Современные протоколы (TLS 1.3) могут поддерживать предварительное обновление (early renewal) без разрыва соединения.

Виды сертификатов​

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

  1. По уровню верификации (Validation Level) — насколько строго проверяется личность владельца;
  2. По назначению (Usage Purpose) — для каких операций предназначен сертификат;
  3. По способу выпуска — кто выступает в роли CA и как организована инфраструктура;
  4. По криптографическому алгоритму — какие математические примитивы используются для ключей и подписей;
  5. По юрисдикции и нормативной базе — какие стандарты и требования соблюдаются.

Ниже рассмотрим каждую группу подробно.

1. По уровню верификации: DV, OV, EV​

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

Domain Validation (DV)​

Наименее строгий, но самый распространённый тип. Проверяется только контроль над доменом. Методы валидации:

  • размещение временного файла в корне сайта (HTTP-01);
  • добавление TXT-записи в DNS (DNS-01);
  • отправка письма на заранее определённые адреса (admin@, webmaster@, hostmaster@ и др.).

Преимущества: мгновенный выпуск (часто — менее минуты), бесплатность (Let’s Encrypt), полная автоматизация.
Недостатки: не подтверждает существование организации. Злоумышленник, получивший контроль над DNS или веб-сервером, может получить DV-сертификат на домен paypa1.com и визуально имитировать PayPal.
Визуальное отображение в браузере: значок замка (🔒), но без указания имени организации.

DV-сертификаты составляют подавляющее большинство в интернете — более 90 % всех HTTPS-соединений. Их достаточность подтверждается тем, что основная задача — защита канала от прослушивания и MITM, а не верификация юридического лица.

Organization Validation (OV)​

Требует подтверждения юридического существования организации и её права на владение доменом. CA проверяет:

  • выписки из ЕГРЮЛ / ЕГРИП (в России) или аналогов (например, Dun & Bradstreet в США);
  • контактные данные (телефон, адрес);
  • подпись уполномоченного лица.

Выпуск занимает от нескольких часов до нескольких дней.
Визуальное отображение: по-прежнему только замок, но при клике на него можно увидеть данные организации (в Chrome: «Соединение защищено» → «Сертификат» → вкладка «Сведения»).
Применение: корпоративные сайты, внутренние порталы, где важно подтвердить принадлежность ресурса конкретной компании.

Extended Validation (EV)​

Максимальный уровень проверки, регулируемый стандартом CA/Browser Forum Baseline Requirements. Помимо OV-требований, предполагает:

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

Ранее EV-сертификаты отображались в адресной строке зелёной полосой с названием организации (например, АО «Сбербанк»). Однако с 2019–2020 годов все ведущие браузеры отказались от визуального выделения EV, поскольку исследования показали, что пользователи не понимают разницы между DV и EV, а злоумышленники всё равно использовали DV для фишинга. Тем не менее, EV остаётся востребованным в финансовой, государственной и критической инфраструктуре — ради аудиторских и регуляторных требований.

2. По назначению: серверные, клиентские, кодовая подпись, S/MIME, IoT​

Серверные сертификаты​

— наиболее известный тип. Используются для аутентификации сервера перед клиентом. Обязательно содержат serverAuth в Extended Key Usage. Могут быть:

  • однодоменными (example.com);
  • многодоменными (SAN) (example.com, api.example.com, shop.example.ru);
  • wildcard (*.example.com) — покрывают все поддомены одного уровня. Не покрывают *.sub.example.com или example.com (без звёздочки).

Важно: wildcard-сертификаты запрещены для EV, а также несовместимы с некоторыми механизмами безопасности (например, HTTP Public Key Pinning — HPKP, ныне устаревший).

Клиентские сертификаты​

— обратная ситуация: клиент предъявляет сертификат серверу для аутентификации. Используются в:

  • корпоративных веб-приложениях (вход по сертификату вместо логина/пароля);
  • API-шлюзах для аутентификации микросервисов;
  • mTLS (Mutual TLS) — двустороннее доверие.

Содержат clientAuth в EKU. Должны быть установлены в хранилище пользователя (браузер, ОС) или передаваться приложением программно. Управление жизненным циклом таких сертификатов — сложная задача (выпуск, отзыв, обновление на тысячах устройств), поэтому часто применяются PKI на базе Active Directory или специализированные системы (например, Teleport для SSH/mTLS).

Сертификаты кодовой подписи (Code Signing)​

— позволяют подтвердить подлинность и целостность программного обеспечения. Подпись внедряется в исполняемые файлы (.exe, .dll, .msi, .app, .apk), драйверы, скрипты.

Важнейшие особенности:

  • Timestamping — обязательна. Подпись остаётся валидной даже после истечения срока действия сертификата, если на момент подписи ставилась временная метка от доверенного TSA (Time-Stamping Authority). Без неё установка ПО после окончания срока сертификата вызовет предупреждение.
  • EV Code Signing — единственный тип, позволяющий немедленно пройти репутационные проверки Microsoft SmartScreen и Apple Notarization. Для обычных (OV/DV) требуется накопление репутации — первые установки будут блокироваться.

Хранение закрытого ключа — критично. Рекомендуется использовать USB-токены с HSM (например, YubiKey, eToken), где ключ никогда не покидает аппаратное устройство.

Сертификаты S/MIME​

— для подписи и шифрования электронной почты. Содержат emailProtection в EKU и, как правило, email-адрес в Subject или SAN.

Позволяют:

  • заверить, что письмо отправлено именно тем, за кого себя выдаёт отправитель (подпись);
  • зашифровать письмо открытым ключом получателя, чтобы только он мог его прочитать (шифрование).

Требуют обмена сертификатами между сторонами заранее или использования каталогов (LDAP, Global Address List). Массового распространения не получили из-за сложности UX, но остаются востребованными в юриспруденции, финансах и госсекторе.

Сертификаты для IoT и встраиваемых систем​

— часто self-signed или выданы внутренним CA. Применяются для:

  • аутентификации устройства в облаке (mTLS к MQTT-брокеру);
  • подписи прошивок (аналог code signing, но для микроконтроллеров);
  • шифрования трафика между датчиками и шлюзами.

Особенности: малый размер (ECDSA вместо RSA), долгий срок действия (до 10 лет), хранение ключей в Secure Element или TPM.

3. По способу выпуска: публичные CA, частные CA, самоподписанные​

Публичные удостоверяющие центры​

— организации, чьи корневые сертификаты предустановлены в ОС и браузерах (Mozilla, Microsoft, Apple, Google). Примеры:

  • Let’s Encrypt (бесплатный, ACME);
  • Sectigo (бывший Comodo), DigiCert, GlobalSign — коммерческие;
  • Amazon ACM, Google Trust Services — облачные CA.

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

Частные (внутренние) CA​

— развёрнуты внутри организации. Используются для:

  • внутренних HTTPS-сервисов (админки, мониторинг);
  • аутентификации пользователей и машин в домене;
  • подписи документов и кода.

Инструменты:

  • Windows Server + Active Directory Certificate Services (AD CS);
  • OpenSSL (вручную, для небольших систем);
  • step-ca, smallstep, EJBCA, CFSSL — open-source CA.

Важно: корневой сертификат внутреннего CA необходимо развернуть на всех доверяющих клиентах (через групповые политики, MDM, скрипты). В противном случае — ошибка доверия.

Самоподписанные сертификаты​

— крайний случай частной CA: сертификат подписан собственным закрытым ключом (Issuer = Subject, CA:TRUE, но без делегирования).

Применяются только для:

  • разработки и тестирования (локальный запуск https://localhost);
  • изолированных систем, где невозможно или нежелательно разворачивать CA.

Нельзя использовать в продакшене, даже во внутренней сети — это нарушает принципы PKI и создаёт ложное ощущение безопасности. Клиенты будут выдавать предупреждения, а обход этих предупреждений пользователем («Да, всё равно перейти») приводит к нормализации игнорирования MITM-рисков.

4. По криптографическому алгоритму: RSA, ECDSA, ГОСТ​

RSA​

— классический алгоритм, основанный на сложности факторизации больших чисел.
Требуемая длина ключа для долгосрочной безопасности — минимум 3072 бит (2048 бит считается уязвимым к атакам в ближайшем будущем).
Преимущества: универсальная поддержка, стабильность.
Недостатки: большие размеры ключей и подписей, высокие вычислительные затраты на подпись.

ECDSA (Elliptic Curve Digital Signature Algorithm)​

— основан на эллиптических кривых.
Ключи 256 бит (кривая secp256r1, эквивалент RSA-3072) обеспечивают сопоставимый уровень стойкости.
Преимущества: меньший размер, выше производительность, особенно на мобильных устройствах. TLS 1.3 рекомендует ECDSA.
Недостатки: меньшая поддержка в старых системах (Windows XP, Android < 5.0); потенциальные риски при использовании слабых генераторов случайных чисел (атака на повторное k в подписи).

EdDSA / Ed25519​

— более современная альтернатива ECDSA на основе кривой Curve25519.
Обеспечивает высокую скорость и устойчивость к side-channel-атакам. Поддерживается в TLS 1.3, OpenSSH, GnuPG.
Пока не везде принят в веб-PKI (браузеры поддерживают, но не все CA выпускают такие сертификаты).

ГОСТ Р 34.10-2012 / ГОСТ Р 34.11-2012​

— российские стандарты цифровой подписи и хэширования. Используются в национальной инфраструктуре:

  • сертификаты ФСБ, Минцифры, УЦ КриптоПро;
  • системы ЕСИА, ГИС ЖКХ, ЕГАИС;
  • средства криптозащиты информации (СКЗИ) — КриптоПро CSP, ViPNet, Signal-VPN.

Особенности:

  • используют отечественные эллиптические кривые (id-GostR3410-2001-CryptoPro-A-ParamSet);
  • требуют установки специальных криптопровайдеров в ОС;
  • не доверяются по умолчанию в зарубежных ОС и браузерах — корневые сертификаты отсутствуют в хранилищах Mozilla/Apple/Microsoft.

Это приводит к необходимости ручной установки корневых сертификатов российских УЦ при работе с государственными ресурсами за пределами доверенной среды (например, из домашнего компьютера). В 2023–2024 годах Минцифры инициировала процесс включения национальных корневых сертификатов в доверенные хранилища (в том числе в дистрибутивы Linux), но на текущий момент поддержка остаётся ограниченной.

5. Национальные сертификаты​

В РФ действует единая система сертификации ключей (ЕССК), в рамках которой функционируют:

  • Главный удостоверяющий центр (ГУЦ) — Минцифры России;
  • Промежуточные УЦ — ведомственные (Минобороны, ФСБ, ФНС, ПФР и др.);
  • Операторы технических средств (ОТС) — организации, аккредитованные ФСБ для эксплуатации СКЗИ.

Сертификаты выдаются в соответствии с:

  • ФЗ-63 «Об электронной подписи» (2021 г.) — вводит три типа подписи: простая, усиленная неквалифицированная (УНЭП), усиленная квалифицированная (УКЭП);
  • Приказ ФСБ № 546 — регламентирует использование ГОСТ в системах защиты информации;
  • ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012, ГОСТ Р 34.12-2015 («Кузнечик», «Магма») — криптографические алгоритмы.

УКЭП — единственный тип, имеющий юридическую силу, равную собственноручной подписи. Для его получения требуется:

  • личное присутствие в аккредитованном УЦ;
  • проверка паспорта и СНИЛС;
  • генерация ключей на сертифицированном СКЗИ (например, Рутокен, eToken ГОСТ);
  • подписание заявления на бумажном носителе.

Такой сертификат может использоваться для:

  • подачи документов в госорганы (Госуслуги, налоговая);
  • участия в электронных торгах (ЕИС);
  • подписания трудовых договоров, бухгалтерской отчётности.

Важно: сертификат УКЭП — это не файл .p12, который можно скопировать. Это связка: закрытый ключ (в защищённом устройстве), сертификат (на том же устройстве или отдельно), и регистрационные данные в реестре УЦ. Потеря ключа = потеря возможности подписи.

Хранение и чтение сертификатов​

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

Хранилища сертификатов реализуются по-разному в зависимости от платформы, но все они решают три общие задачи:

  1. Безопасное хранение — особенно закрытых ключей, доступ к которым должен быть строго контролируемым;
  2. Индексация и поиск — по отпечатку, имени субъекта, издателю, EKU и другим атрибутам;
  3. Интеграция с криптографическими API — чтобы приложения могли использовать сертификаты без прямой работы с файлами.

Ниже рассмотрим реализации в основных средах, а затем — инструменты анализа и типичные сценарии сбоев.

1. Хранилища сертификатов в операционных системах​

Windows: Certificate Store (Cert Store)​

Windows использует иерархическую систему логических хранилищ, реализованных поверх реестра и файловой системы. Доступ к ним осуществляется через графический интерфейс (certmgr.msc, certlm.msc) или PowerShell (Get-ChildItem Cert:\...).

Основные хранилища:

  • Current User — привязаны к профилю пользователя:

    • My (Личные) — сертификаты с закрытыми ключами (клиентские, кодовая подпись, УКЭП);
    • Root — доверенные корневые сертификаты;
    • CA — промежуточные сертификаты;
    • TrustedPeople, Disallowed — дополнительные политики.

  • Local Machine — системные, доступны всем пользователям:

    • My — серверные сертификаты (IIS, служебные приложения);
    • Root, CA — системные корневые и промежуточные;
    • Request — сохранённые CSR;
    • WebHosting — специализированное хранилище для IIS (поддержка SNI, быстрый доступ).

Особенности:

  • Закрытые ключи хранятся в %APPDATA%\Microsoft\Crypto\RSA\ (пользователь) или %ALLUSERSPROFILE%\Microsoft\Crypto\RSA\MachineKeys\ (система), зашифрованы DPAPI.
  • Доступ к закрытому ключу управляется ACL (права NTFS + CryptoAPI ACL).
  • Через certutil -store My можно вывести список сертификатов в консоли.

macOS и iOS: Keychain​

Единая защищённая база данных, управляемая службой Keychain Services. Существует несколько ключевых цепочек:

  • login.keychain — привязана к пользователю (по умолчанию);
  • System.keychain — системные сертификаты;
  • System Roots — только для чтения, содержит Apple-доверенные корневые;
  • iCloud Keychain — синхронизация между устройствами (только пароли и некоторые сертификаты).

Сертификаты и ключи хранятся вместе. Для доступа к закрытому ключу требуется разблокировка ключевой цепочки (обычно при входе в систему) и, при необходимости, дополнительный запрос разрешения (например, Safari спрашивает: «Разрешить сайту X использовать сертификат Y?»).

Инструменты:

  • Keychain Access.app — графический просмотр и экспорт;
  • security find-certificate -c "example" -p — поиск и вывод в PEM через терминал;
  • codesign --verify --verbose MyApp.app — проверка подписи приложения.

Linux и Unix-подобные системы​

В отличие от Windows и macOS, единая система хранилища отсутствует. Вместо этого используется децентрализованный подход:

  • Системные корневые сертификаты:

    • Debian/Ubuntu: /etc/ssl/certs/ (символические ссылки на отдельные .crt-файлы) + /usr/share/ca-certificates/;
    • RHEL/CentOS/Fedora: /etc/pki/tls/certs/ca-bundle.crt (единый bundle);
    • Обновление через update-ca-certificates (Debian) или update-ca-trust (RHEL).

  • Приложения используют собственные механизмы:

    • OpenSSL и производные (curl, wget, Node.js, Python ssl) — читают из системного bundle или указанного --cacert;
    • Java — использует cacerts в $JAVA_HOME/jre/lib/security/; обновляется через keytool -importcert;
    • Firefox — имеет собственное хранилище, независимое от ОС (файл cert9.db в профиле);
    • Chrome/Chromium на Linux — использует системное хранилище (NSS или OpenSSL, в зависимости от сборки).

Важно: при развёртывании приложений в контейнерах (Docker) необходимо явно копировать CA-бандл в образ, иначе соединения к внешним HTTPS-ресурсам будут падать с ошибкой CERTIFICATE_VERIFY_FAILED.

2. Чтение и анализ сертификатов​

Для диагностики и проверки сертификатов используются как графические, так и консольные утилиты.

OpenSSL — универсальный инструмент​

  • Просмотр содержимого PEM-сертификата:

    openssl x509 -in cert.pem -text -noout

    Выводит все поля, расширения, отпечатки (SHA1 Fingerprint, SHA256 Fingerprint).

  • Проверка цепочки:

    openssl verify -CAfile ca-bundle.pem server.crt

  • Извлечение открытого ключа:

    openssl x509 -in cert.pem -pubkey -noout > pubkey.pem

  • Проверка срока действия:

    openssl x509 -in cert.pem -dates -noout
    # notBefore=Nov 20 00:00:00 2024 GMT
    # notAfter=Feb 18 23:59:59 2025 GMT

  • Подключение к серверу и получение сертификата:

    openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -text -noout

keytool (Java)​

  • Просмотр сертификата в JKS:

    keytool -list -v -keystore keystore.jks -alias mycert

  • Импорт сертификата в доверенное хранилище Java:

    keytool -importcert -file ca.crt -alias myca -keystore $JAVA_HOME/jre/lib/security/cacerts
    # пароль по умолчанию: changeit

certutil (Windows)​

  • Просмотр сертификатов в хранилище:

    certutil -store My

  • Проверка цепочки:

    certutil -verify -urlfetch cert.cer

  • Экспорт с закрытым ключом (только из My):

    certutil -user -p "pass" -exportPFX My "CN=example" cert.pfx

Online-инструменты​

  • SSL Labs Server Test — глубокий аудит TLS-конфигурации сервера;
  • crt.sh — поиск сертификатов по домену в базе Certificate Transparency;
  • Google Transparency Report — просмотр CT-логов.

3. Диагностика типичных ошибок​

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

Ошибка: «Your connection is not private» / «NET::ERR_CERT_AUTHORITY_INVALID»​

Причины:

  • Используется самоподписанный или внутренний сертификат, корневой CA которого не установлен на клиенте;
  • Сервер не присылает промежуточные сертификаты (цепочка неполная);
  • Корневой сертификат CA был удалён из хранилища (например, политика безопасности).

Диагностика:

  • В Chrome: кликнуть на замок → «Сертификат» → вкладка «Цепочка сертификации». Если последнее звено — не «Доверенный корневой центр сертификации», значит, корневой сертификат отсутствует или не доверен.
  • В OpenSSL: openssl s_client -connect host:443 -showcerts. Проверить, сколько сертификатов получено. Должен быть серверный + промежуточные (но не корневой).

Решение:

  • Установить корневой сертификат CA в доверенное хранилище;
  • На сервере настроить отправку полной цепочки (в Nginx: ssl_certificate должен указывать на файл, содержащий сначала серверный, затем промежуточные сертификаты).

Ошибка: «ERR_CERT_COMMON_NAME_INVALID»​

Причина: домен в адресной строке не совпадает ни с Common Name, ни с Subject Alternative Name.

Диагностика:

  • openssl x509 -in cert.pem -text | grep -A1 "Subject Alternative Name"
  • Убедиться, что запрашиваемый хост (например, api.example.com) присутствует в списке DNS:.

Решение:

  • Перевыпустить сертификат с корректным SAN;
  • Использовать wildcard, если применимо (*.example.com);
  • Избегать использования CN как единственного идентификатора.

Ошибка: «ERR_CERT_DATE_INVALID»​

Причины:

  • Сертификат просрочен (Not After в прошлом);
  • Сертификат ещё не вступил в силу (Not Before в будущем);
  • Рассогласование времени на клиенте (например, неправильный часовой пояс, отключённая синхронизация NTP).

Диагностика:

  • date — проверить системное время;
  • openssl x509 -in cert.pem -dates -noout — сверить с текущим UTC.

Решение:

  • Обновить сертификат;
  • Настроить NTP-синхронизацию (systemd-timesyncd, chrony, ntpd).

Ошибка: «revoked certificate» / OCSP failure​

Причины:

  • Сертификат отозван CA (утечка ключа, компрометация);
  • Клиент не может связаться с OCSP-резондером (блокировка фаерволом, отсутствие интернета);
  • OCSP-stapling не настроен, а OCSP-сервер недоступен.

Диагностика:

  • openssl x509 -in cert.pem -text | grep -A2 "OCSP"
  • openssl ocsp -issuer intermediate.crt -cert server.crt -url http://ocsp.example.com

Решение:

  • Для сервера: включить OCSP stapling (в Nginx: ssl_stapling on; ssl_stapling_verify on;);
  • Для клиента: при невозможности онлайн-проверки — использовать режим «мягкой» проверки (например, curl --insecure — только для отладки!).

Ошибка при использовании российских сертификатов: «unknown issuer»​

Причина: корневой сертификат УЦ Минцифры / ФСБ отсутствует в доверенном хранилище.

Решение:

  1. Скачать корневой сертификат с официального сайта (например, минцифры.рф → раздел «Электронная подпись» → «Доверенные корневые сертификаты»).
  2. Установить:
    • Windows: двойной клик → «Установить сертификат» → «Текущий пользователь» → «Доверенные корневые центры сертификации».
    • Linux (Debian): 
      sudo cp root-ca.cer /usr/local/share/ca-certificates/
      sudo update-ca-certificates
    • Java: 
      keytool -importcert -file root-ca.cer -alias minsvyaz_root -keystore $JAVA_HOME/lib/security/cacerts

После этого ресурсы вроде gosuslugi.ru или service.nalog.ru перестанут выдавать ошибки.

Сертификаты и защита от MITM​

Сертификаты — центральный, но не единственный элемент защиты от атак типа man-in-the-middle (MITM). Их эффективность определяется не изолированно, а в рамках комплексной архитектуры доверия, где криптография, инфраструктура, политики и поведение пользователя взаимодействуют друг с другом. Чтобы понять, как именно сертификаты предотвращают MITM, необходимо разобрать, что позволяет злоумышленнику осуществить MITM в принципе, и какие звенья цепи доверия должны выдержать проверку, чтобы атака была заблокирована.

Как работает MITM в отсутствие сертификатов (HTTP)​

В незашифрованном HTTP-соединении клиент отправляет запрос в открытом виде. Злоумышленник, находящийся на пути трафика (например, в той же Wi-Fi-сети, на маршрутизаторе, в провайдере), может:

  1. Перехватить HTTP-запрос (GET /login HTTP/1.1);
  2. Перехватить HTTP-ответ с формой входа;
  3. Подменить содержимое формы, внедрив скрипт, отправляющий логин и пароль к себе;
  4. Проксировать остальной трафик, сохраняя иллюзию нормальной работы.

Это возможно, потому что:

  • Нет аутентификации сервера — клиент не проверяет, с кем он на самом деле говорит;
  • Нет шифрования — данные читаются в открытом виде;
  • Нет контроля целостности — ответы можно модифицировать без обнаружения.

HTTPS устраняет все три уязвимости — но только при условии корректной реализации.

Как TLS с сертификатами предотвращает MITM​

Когда клиент устанавливает соединение по HTTPS, происходит TLS-рукопожатие (handshake). В его рамках решаются три задачи:

  1. Аутентификация сервера
    Сервер представляет сертификат. Клиент:

    • проверяет, что издатель — доверенный CA (через цепочку до корневого сертификата);
    • сверяет доменное имя с SAN;
    • убеждается, что сертификат не просрочен и не отозван.

    Только после успешной проверки клиент считает, что общается именно с тем сервером, который заявлен в URL.

  2. Шифрование канала
    С использованием открытого ключа из сертификата (или, чаще, через ephemeral-ключи в ECDHE) клиент и сервер вырабатывают общий сеансовый ключ — симметричный, используемый для шифрования всего последующего трафика (AES-GCM, ChaCha20-Poly1305 и др.).
    Даже если злоумышленник перехватит зашифрованные пакеты, без сеансового ключа их расшифровка невозможна.

  3. Контроль целостности
    Каждый TLS-запись (record) защищается механизмом аутентифицированного шифрования (AEAD), который гарантирует, что данные не были изменены в пути. Попытка подмены байта приведёт к мгновенному разрыву соединения.

Таким образом, MITM становится невозможен, если:

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

Однако — и это критически важно — сама по себе технология TLS не заставляет клиента проверять сертификат. Это — обязанность реализации. Если приложение отключает проверку (например, curl -k, HttpClientHandler.ServerCertificateCustomValidationCallback = (…)=> true в .NET), то MITM снова становится тривиальным.

Где остаются уязвимости​

Несмотря на надёжность TLS, атаки MITM возможны в следующих ситуациях:

1. Установка доверенного корневого сертификата злоумышленника​

Если пользователь (сознательно или под давлением) устанавливает корневой сертификат, созданный злоумышленником, тот может выпускать валидные сертификаты на google.com, sberbank.ru и любые другие домены. Так работают:

  • антивирусы с функцией HTTPS-сканирования (Kaspersky, ESET);
  • корпоративные прокси (Zscaler, Blue Coat);
  • вредоносные программы (Superfish — случай Lenovo, 2015).

Защита:

  • ОС и браузеры начинают ограничивать такие практики:
    • Windows 10+ требует явного разрешения на установку CA в системное хранилище;
    • Chrome и Firefox помечают сертификаты от прозрачных прокси (если известны их CA) как ненадёжные;
    • Certificate Transparency (см. ниже) позволяет обнаружить несанкционированный выпуск.

2. Компрометация удостоверяющего центра​

Если CA утечёт закрытый ключ промежуточного сертификата, злоумышленник может массово выпускать доверенные сертификаты. Так было с DigiNotar (2011), когда были выданы сертификаты на gmail.com, facebook.com, использовавшиеся для атак на иранских dissidents.

Последствия:

  • Браузеры экстренно отзывают доверие к CA через обновления (Google, Mozilla публикуют «revocation lists»);
  • Вводятся более строгие требования к аудиту CA (WebTrust, ETSI EN 319 411).

3. Отсутствие проверки отзыва (revocation checking)​

Если сертификат отозван (например, после утечки ключа), но клиент не проверяет статус, он примет его как валидный. По умолчанию:

  • Windows проверяет CRL/OCSP для EV-сертификатов, но не всегда для DV;
  • macOS и iOS используют OCSP stapling + кэширование;
  • Android и многие IoT-устройства — почти никогда не проверяют.

Решение: OCSP stapling на стороне сервера + политики «мягкого» (soft-fail) или «жёсткого» (hard-fail) отказа.

4. SSL/TLS stripping (downgrade-атаки)​

Злоумышленник блокирует переадресацию http:// → https:// и заставляет пользователя оставаться на HTTP. Классический пример — инструмент SSLStrip (Moxie Marlinspike, 2009).

Защита:

  • HTTP Strict Transport Security (HSTS) — HTTP-заголовок: 
    Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
    После первого визита браузер автоматически преобразует все http://-запросы к этому домену в https://, даже если пользователь ввёл http вручную.
  • HSTS Preload List — список доменов, вшитый в исходный код браузеров. Чтобы попасть туда, нужно выполнить строгие требования (все поддомены на HTTPS, max-age ≥ 1 год и др.). Включено для google.com, yandex.ru, vk.com и десятков тысяч других.

5. Подмена DNS (DNS spoofing / cache poisoning)​

Если злоумышленник заставит клиента разрешить bank.ru в IP-адрес своего сервера, а на своём сервере установит валидный DV-сертификат на bank.ru (полученный, например, через компрометацию DNS), то TLS-проверка пройдёт успешно.

Защита:

  • DNSSEC — подписывает DNS-ответы, клиент проверяет подпись;
  • DoH / DoT — шифрует DNS-трафик, предотвращая подмену на уровне сети;
  • Certificate Transparency (CT) — механизм, призванный обнаружить такие атаки после факта.

Certificate Transparency​

CT — это открытая система логирования всех выданных публичных TLS-сертификатов. Идея проста: если каждый сертификат публикуется в публичных, неизменяемых журналах, то любая несанкционированная выдача будет замечена.

Как это работает:

  1. CA, перед выдачей сертификата, отправляет его в один или несколько CT-логов (Google, Cloudflare, DigiCert и др.).
  2. Лог возвращает Signed Certificate Timestamp (SCT) — доказательство приёма.
  3. SCT встраивается в сертификат (в расширение ct_precert_scts) или передаётся через TLS-расширение (signed_certificate_timestamp).
  4. Браузер проверяет наличие SCT от минимум двух независимых логов (требование Google с 2018 г.).

Что даёт CT:

  • Владелец домена может подписаться на уведомления (через crt.sh или Facebook’s Certificate Transparency Monitoring) и мгновенно увидеть, если CA выдал сертификат на его домен без ведома.
  • Исследователи сканируют логи на признаки массовой выдачи (например, для фишинга).
  • CA не могут «тихо» отозвать или скрыть факт выпуска.

CT не предотвращает MITM в момент атаки, но делает её обнаруживаемой и недолговечной — что является важным элементом кибергигиены.

Другие механизмы усиления​

HTTP Public Key Pinning (HPKP)​

HPKP позволял сайту «закрепить» (pin) определённые публичные ключи, запрещая браузеру принимать сертификаты с другими ключами, даже если они подписаны доверенным CA.
Пример заголовка:

Public-Key-Pins: pin-sha256="base64=="; pin-sha256="backup=="; max-age=2592000; includeSubDomains

Почему отменён:

  • Высокий риск человеческой ошибки: при потере закрытого ключа и отсутствии резервного пина сайт становился недоступен для всех пользователей на max-age дней;
  • CT оказался более гибким и безопасным решением.

Современная альтернатива — Expect-CT (тоже deprecated), а в перспективе — Certificate-Bound Tokens (RFC 8705) и Token Binding.

Mutual TLS (mTLS) — MITM-proof для сервер-сервер и клиент-сервер​

В стандартном TLS только сервер аутентифицируется. В mTLS клиент также предъявляет сертификат, и сервер проверяет его. Это полностью исключает MITM, потому что:

  • Злоумышленник должен владеть и серверным, и клиентским закрытым ключом;
  • Клиентские сертификаты, как правило, хранятся в HSM или TPM, их кража маловероятна.

Применение:

  • микросервисы в Kubernetes (Istio, Linkerd);
  • API-шлюзы (Apigee, Kong);
  • банковские терминалы, POS-устройства;
  • государственные ГИС (например, интеграция с ЕГАИС по защищённому каналу).

End-to-End Encryption (E2EE)​

TLS защищает канал, но не данные. Если сервер скомпрометирован, данные в открытом виде у него в памяти.
E2EE (например, в Signal, WhatsApp, ProtonMail) означает, что:

  • данные шифруются на устройстве отправителя до отправки по TLS;
  • расшифровываются только на устройстве получателя;
  • сервер никогда не видит открытый текст.

В этом случае даже успешный MITM на уровне сети не даёт злоумышленнику содержимого — только метаданные (кто с кем общался, когда, сколько).