Перейти к содержанию

12. Сертификаты в информационной безопасности

1. Введение

Пользователь открывает сайт банка:

Пользователь → https://bank.example.ru

Но злоумышленник может попытаться вмешаться в соединение:

Пользователь → Злоумышленник → Сервер

В такой ситуации возникает важный вопрос: Как пользователь может понять, что сервер действительно является тем сервером, за который себя выдаёт?

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

Поэтому в защищённых соединениях необходимо решить две задачи: 1. установить защищённый канал связи; 2. убедиться в подлинности стороны, с которой устанавливается соединение.

Одним из основных механизмов решения этой задачи являются цифровые сертификаты.

Что такое цифровой сертификат

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

Упрощённо сертификат можно представить следующим образом:

Сертификат
    │
    ├── Имя владельца
    ├── Доменное имя
    ├── Открытый ключ
    ├── Срок действия
    ├── Информация об издателе
    ├── Назначение сертификата
    └── Цифровая подпись удостоверяющего центра

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

Важно понимать: сертификат не является самим ключом.

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

Зачем нужны сертификаты

Цифровые сертификаты используются для решения нескольких задач.

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

В контексте веб-сайтов наиболее знакомым примером является HTTPS.

Когда браузер подключается к сайту по HTTPS, сервер предоставляет сертификат.

Упрощённая схема выглядит так:

Браузер
   │
   │ запрос HTTPS
   ▼
Сервер
   │
   │ сертификат
   ▼
Браузер проверяет сертификат
   │
   ├── сертификат действителен → продолжаем соединение
   │
   └── проблема с сертификатом → предупреждение

Сертификат и открытый ключ

Чтобы понять назначение сертификата, необходимо вспомнить принцип асимметричной криптографии.

При использовании асимметричной криптографии создаётся пара ключей:

             Ключевая пара
                  │
          ┌───────┴───────┐
          │               │
     Открытый ключ    Закрытый ключ
     (Public Key)    (Private Key)

Открытый ключ

Открытый ключ можно передавать другим участникам.

Он не считается секретным.

Закрытый ключ

Закрытый ключ должен храниться в секрете.

Если злоумышленник получает закрытый ключ, безопасность соответствующей системы может быть серьёзно нарушена.

Почему недостаточно просто передать открытый ключ

Предположим, браузер подключается к серверу.

Сервер говорит:

Я bank.example.ru.

Вот мой открытый ключ.

Но злоумышленник может сделать то же самое:

Я bank.example.ru.

Вот мой открытый ключ.

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

Злоумышленник может подменить открытый ключ своим.

Схема атаки:

Браузер
   │
   │ хочет подключиться к bank.example.ru
   ▼
Злоумышленник
   │
   │ представляет свой ключ
   ▼
Браузер

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

Именно здесь появляется сертификат.

Связь доменного имени и открытого ключа

Сертификат позволяет связать идентификатор сервера с открытым ключом.

Упрощённо:

bank.example.ru
       │
       │ связан с
       ▼
Открытый ключ
       │
       │ подтверждено
       ▼
Цифровой сертификат

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

Например:

Запрошен:
bank.example.ru

Сертификат:
bank.example.ru

Если имя соответствует требованиям сертификата, эта часть проверки пройдена.

Если же сертификат выдан для другого имени:

Запрошен:
bank.example.ru

Сертификат:
example.com

возникает проблема.

Браузер должен предупредить пользователя о несоответствии.

Кто выдаёт сертификаты

Возникает следующий вопрос: Кто решает, каким сертификатам можно доверять?

Для этого существует инфраструктура открытых ключей и специальные организации — удостоверяющие центры.

На английском используется термин: CA — Certificate Authority.

На русском: УЦ — удостоверяющий центр.

Удостоверяющий центр выпускает сертификаты и подписывает их своим закрытым ключом.

Упрощённая схема:

Владелец сайта
      │
      │ запрос на сертификат
      ▼
Удостоверяющий центр
      │
      │ проверка необходимых данных
      ▼
Сертификат
      │
      │ подписан УЦ
      ▼
Веб-сервер

После этого сервер предоставляет сертификат клиенту.

Цифровая подпись сертификата

Одна из важнейших частей сертификата — цифровая подпись удостоверяющего центра.

Упрощённо процесс можно представить так:

Информация сертификата
        │
        ▼
    Хеширование
        │
        ▼
Формирование подписи
с использованием закрытого ключа УЦ
        │
        ▼
Цифровая подпись

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

Упрощённо:

Сертификат
    │
    ├── данные
    │
    └── подпись УЦ
             │
             ▼
      проверка подписи
             │
       ┌─────┴─────┐
       │           │
     успешно     ошибка

Если данные сертификата были изменены после подписания, проверка цифровой подписи не пройдёт.

Таким образом, подпись помогает обнаружить подмену или изменение содержимого сертификата.

Корневые удостоверяющие центры

Но возникает новый вопрос:

Откуда браузер знает, что самому удостоверяющему центру можно доверять?

Для этого в операционной системе и браузерах существует хранилище доверенных сертификатов.

В нём находятся сертификаты доверенных корневых удостоверяющих центров.

Например:

Операционная система
       │
       ▼
Хранилище доверенных сертификатов
       │
       ├── Корневой УЦ №1
       ├── Корневой УЦ №2
       ├── Корневой УЦ №3
       └── ...

Таким образом формируется цепочка доверия.

Цепочка доверия

На практике сертификат веб-сервера не обязательно подписывается непосредственно корневым удостоверяющим центром.

Между ними могут находиться промежуточные удостоверяющие центры.

Например:

Корневой УЦ
     │
     ▼
Промежуточный УЦ
     │
     ▼
Сертификат сервера
     │
     ▼
bank.example.ru

Такая структура называется цепочкой сертификатов или цепочкой доверия.

Браузер проверяет эту цепочку.

Упрощённо:

Сертификат сервера
       │
       ▼
Промежуточный сертификат
       │
       ▼
Корневой сертификат
       │
       ▼
Доверие операционной системы

Если цепочка корректна и заканчивается доверенным корневым сертификатом, сертификат сервера может считаться доверенным.

Почему корневой сертификат считается доверенным

Корневой сертификат является особым элементом инфраструктуры.

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

Корневые сертификаты заранее добавляются в доверенное хранилище операционной системы или браузера.

Получается модель:

Доверенное хранилище
        │
        ▼
Корневой УЦ
        │
        ▼
Промежуточный УЦ
        │
        ▼
Сертификат сервера

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

Что содержится в сертификате

Цифровой сертификат содержит множество полей.

Среди наиболее важных:

Поле Назначение
Subject информация о владельце сертификата
Issuer удостоверяющий центр, выдавший сертификат
Public Key открытый ключ владельца
Valid From начало срока действия
Valid To окончание срока действия
Serial Number уникальный номер сертификата
Signature Algorithm алгоритм цифровой подписи
Key Usage назначение ключа
Extended Key Usage расширенное назначение
Subject Alternative Name имена, для которых действует сертификат
Signature цифровая подпись удостоверяющего центра

Subject и Issuer

Два важных поля:

Subject — кому принадлежит сертификат.

Issuer — кто выдал сертификат.

Например:

Subject:
CN = server.example.ru

Issuer:
Example Intermediate CA

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

Subject Alternative Name

Современные сертификаты могут содержать поле: Subject Alternative Name — SAN.

Оно используется для указания имён и других идентификаторов, для которых действителен сертификат.

Например:

Subject Alternative Name:

DNS: example.ru
DNS: www.example.ru
DNS: mail.example.ru

Это позволяет одному сертификату использоваться для нескольких доменных имён.

При проверке HTTPS браузер учитывает соответствующие имена из SAN.

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

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

Например:

Valid From:
01.01.2026

Valid To:
01.01.2027

После окончания срока действия сертификат считается недействительным.

Это необходимо учитывать администраторам.

Если сертификат сайта закончился, пользователи могут получить предупреждение:

Соединение не является безопасным

Поэтому срок действия сертификатов необходимо контролировать заранее.

Почему сертификат нельзя просто скопировать

Предположим, сертификат принадлежит серверу:

server.example.ru

Злоумышленник может получить сам сертификат.

Это не обязательно является проблемой.

Причина в том, что сертификат содержит открытый, а не закрытый ключ.

Главный секрет находится в закрытом ключе.

Упрощённо:

Сертификат
     │
     └── Открытый ключ → можно распространять

Закрытый ключ
     │
     └── должен храниться в секрете

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

Сертификат и HTTPS

Наиболее распространённый пример использования сертификатов — HTTPS.

HTTPS представляет собой защищённую работу HTTP поверх TLS.

Упрощённо:

HTTP
  │
  ▼
TLS
  │
  ▼
TCP
  │
  ▼
IP

При подключении к HTTPS-сайту сервер предоставляет сертификат.

Браузер выполняет проверки.

Упрощённо:

1. Сервер предоставляет сертификат
             │
             ▼
2. Проверка срока действия
             │
             ▼
3. Проверка имени сайта
             │
             ▼
4. Проверка цифровой подписи
             │
             ▼
5. Проверка цепочки доверия
             │
             ▼
6. Проверка назначения сертификата
             │
             ▼
7. Продолжение установки TLS-соединения

При успешной установке защищённого соединения данные передаются в зашифрованном виде.

Что происходит при открытии HTTPS-сайта

Рассмотрим упрощённый сценарий.

Пользователь вводит:

https://example.ru

Браузер обращается к серверу.

Сервер предоставляет сертификат.

Браузер
   │
   │ HTTPS
   ▼
Сервер
   │
   │ сертификат
   ▼
Браузер

Браузер проверяет:

Имя подходит?
       │
       ▼
Сертификат не просрочен?
       │
       ▼
Подпись действительна?
       │
       ▼
Цепочка доверия корректна?
       │
       ▼
Назначение сертификата подходит?
       │
       ▼
Да → продолжаем соединение

После этого устанавливается защищённый канал TLS.

Что означает значок замка в браузере

Рядом с HTTPS-адресом браузер обычно показывает информацию о защищённом соединении.

Важно понимать: замок не означает, что сайт обязательно является честным или безопасным во всех смыслах.

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

Например, мошенники могут зарегистрировать собственный домен:

bank-example-login.com

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

Браузер может показать корректное HTTPS-соединение.

Но это не превращает мошеннический сайт в настоящий сайт банка.

Поэтому необходимо различать:

Защищённое соединение
        ≠
Автоматическая гарантия добросовестности сайта

Сертификат не защищает от всех видов мошенничества

Предположим, пользователь получил письмо:

Ваш банковский аккаунт заблокирован.
Перейдите:
https://bank-example-login.com

На сайте действительно используется HTTPS.

Сертификат действителен.

Но домен принадлежит злоумышленнику.

Следовательно:

HTTPS
   │
   ├── защищает соединение
   │
   └── не гарантирует, что пользователь выбрал правильный сайт

Пользователь должен самостоятельно проверить доменное имя.

Как сертификат помогает против Man-in-the-Middle

Рассмотрим атаку Man-in-the-Middle.

Злоумышленник пытается расположиться между клиентом и сервером:

Клиент
   │
   ▼
Злоумышленник
   │
   ▼
Сервер

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

При использовании TLS клиент проверяет сертификат.

Если злоумышленник предоставляет сертификат:

bank.example.ru

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

Например:

Сертификат:
bank.example.ru

Выдан:
Неизвестным центром

Результат:
Предупреждение

Это значительно усложняет проведение MitM-атаки.

Что произойдёт при поддельном сертификате

Если злоумышленник создаёт собственный сертификат:

bank.example.ru

это ещё не означает, что браузер ему доверит.

Браузер проверяет цепочку доверия.

Например:

Поддельный сертификат
        │
        ▼
Неизвестный УЦ
        │
        ▼
Нет доверенного корня
        │
        ▼
ОШИБКА

В этом случае пользователь может увидеть предупреждение.

Почему злоумышленник не может просто подписать сертификат сам

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

Но такой сертификат не будет автоматически считаться доверенным.

Можно представить ситуацию:

Злоумышленник
     │
     ├── создаёт сертификат
     ├── создаёт собственный УЦ
     └── подписывает сертификат

Проблема заключается в том, что этот УЦ отсутствует среди доверенных корневых центров.

Поэтому:

Самоподписанный сертификат
          │
          ▼
Неизвестный источник доверия
          │
          ▼
Предупреждение

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

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

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

Упрощённо:

Сервер
  │
  ├── создаёт ключи
  │
  ├── создаёт сертификат
  │
  └── подписывает его самостоятельно

Такой сертификат может использоваться: - в лабораториях; - на внутренних серверах; - в тестовых системах; - при разработке; - в некоторых закрытых корпоративных инфраструктурах.

Но если клиент заранее не доверяет этому сертификату или соответствующему УЦ, браузер обычно выдаст предупреждение.

Собственный удостоверяющий центр организации

Крупные организации могут использовать собственную инфраструктуру PKI.

Например:

Корневой УЦ организации
          │
          ▼
Промежуточный УЦ
          │
    ┌─────┼─────┐
    ▼     ▼     ▼
 Сервер  VPN   Почта

Рабочие станции организации заранее получают корневой сертификат этого УЦ.

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

Например:

https://portal.company.local

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

PKI

Инфраструктура, предназначенная для управления открытыми ключами и цифровыми сертификатами, называется: PKI — Public Key Infrastructure.

По-русски: инфраструктура открытых ключей.

PKI включает не только сертификаты.

В неё могут входить: - удостоверяющие центры; - сертификаты; - ключи; - процедуры выпуска сертификатов; - процедуры отзыва; - политики доверия; - хранилища сертификатов; - механизмы проверки статуса сертификатов.

Упрощённо:

                    PKI
                     │
       ┌─────────────┼─────────────┐
       │             │             │
      УЦ        Сертификаты      Ключи
       │
       ├── выпуск
       ├── продление
       └── отзыв

Отзыв сертификата

Иногда сертификат необходимо сделать недействительным до окончания его срока.

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

В таком случае сертификат может быть отозван.

Упрощённо:

Сертификат действителен
          │
          │ обнаружена проблема
          ▼
      Отзыв
          │
          ▼
Сертификат больше не должен использоваться

CRL

Одним из механизмов проверки отозванных сертификатов является: CRL — Certificate Revocation List.

По-русски: список отозванных сертификатов.

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

Упрощённо:

Удостоверяющий центр
        │
        ▼
Список отозванных сертификатов
        │
        ▼
Клиент проверяет сертификат

Если серийный номер сертификата находится в списке, сертификат считается отозванным.

OCSP

Другой механизм проверки статуса сертификата: OCSP — Online Certificate Status Protocol.

Вместо получения большого списка клиент может запросить статус конкретного сертификата.

Упрощённо:

Клиент
   │
   │ "Каков статус сертификата №123?"
   ▼
OCSP-сервер
   │
   ▼
"Действителен"

или:

"Отозван"

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

Сертификаты и электронная подпись

Сертификаты используются не только для HTTPS.

Они могут применяться для электронной подписи.

Упрощённая схема:

Документ
   │
   ▼
Хеш
   │
   ▼
Подпись закрытым ключом
   │
   ▼
Электронная подпись

Сертификат помогает связать открытый ключ с определённым владельцем.

Получатель может проверить:

Электронная подпись
        │
        ▼
Открытый ключ
        │
        ▼
Сертификат
        │
        ▼
Кому принадлежит ключ?

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

Сертификат и идентификация

Важно различать несколько понятий.

Аутентификация

Определение того, кто именно является участником взаимодействия.

Авторизация

Определение того, что этому участнику разрешено делать.

Сертификат

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

Например:

Сертификат
    │
    ▼
Ключ принадлежит серверу X
    │
    ▼
TLS
    │
    ▼
Защищённое соединение

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

Сертификаты пользователей

Сертификаты могут выдаваться не только серверам.

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

Например:

Компьютер пользователя
        │
        ▼
Клиентский сертификат
        │
        ▼
Сервер
        │
        ▼
Проверка сертификата

Такой подход называется взаимной аутентификацией или mTLS — mutual TLS.

В обычном HTTPS чаще всего сервер доказывает свою подлинность клиенту.

В mTLS стороны могут аутентифицировать друг друга.

Обычный TLS и взаимная аутентификация

Обычный сценарий:

Клиент ─────────► Сервер
          ◄────── Сертификат сервера

Сервер подтверждает свою подлинность
перед клиентом.

При mTLS:

Клиент ─────────► Сервер
          ◄────── Сертификат сервера

Клиент ─────────► Сертификат клиента

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

mTLS применяется, например, в некоторых корпоративных системах и API.

Типичные ошибки при работе с сертификатами

Администраторы могут столкнуться с различными проблемами.

1. Сертификат просрочен

Valid To < текущая дата

2. Неверное имя

Сертификат выдан для другого домена.

3. Нарушена цепочка доверия

Клиент не может построить цепочку до доверенного корневого сертификата.

4. Неизвестный удостоверяющий центр

Клиент не доверяет центру, который выдал сертификат.

5. Сертификат отозван

Сертификат больше не должен использоваться.

6. Неправильное назначение

Сертификат или ключ не предназначен для необходимого типа использования.

Что видит пользователь при ошибке сертификата

Например, пользователь открывает сайт, но браузер обнаруживает проблему.

Возможные причины:

Сертификат просрочен
        или
Имя не соответствует
        или
Не доверен удостоверяющий центр
        или
Нарушена цепочка доверия

Браузер может показать предупреждение.

Для администратора это сигнал о необходимости выяснить причину.

Важно: не следует автоматически игнорировать предупреждения сертификата.

Особенно опасно делать это при работе с: - банковскими системами; - корпоративными порталами; - административными интерфейсами; - системами управления; - почтовыми серверами; - VPN; - API.

Почему нельзя бездумно нажимать «Продолжить»

Предупреждение сертификата может означать обычную административную ошибку.

Например:

Внутренний сервер
+
самоподписанный сертификат

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

Например:

Пользователь
     │
     ▼
Злоумышленник
     │
     ▼
Настоящий сервер

Поэтому администратор должен сначала выяснить причину предупреждения.

Сертификаты и CIA

Рассмотрим сертификаты с точки зрения модели CIA.

Confidentiality — конфиденциальность

TLS использует криптографические механизмы для защиты передаваемых данных.

Сертификат участвует в установлении доверенного защищённого соединения.

Сертификат
    ↓
Аутентификация сервера
    ↓
TLS
    ↓
Шифрование трафика
    ↓
Конфиденциальность

Integrity — целостность

TLS обеспечивает защиту данных от незаметного изменения в процессе передачи.

Сертификаты и криптографические механизмы участвуют в формировании доверенного соединения.

Availability — доступность

Сертификаты напрямую не обеспечивают доступность.

Однако неправильная работа сертификатов может привести к недоступности сервиса для пользователей.

Например:

Сертификат истёк
       ↓
Браузер предупреждает
       ↓
Пользователь не может нормально работать
       ↓
Сервис фактически становится недоступным

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

При обычном MitM злоумышленник пытается занять положение между двумя сторонами:

Клиент
   │
   ▼
Злоумышленник
   │
   ▼
Сервер

TLS с проверкой сертификата создаёт дополнительный уровень защиты:

Клиент
   │
   │ проверяет сертификат
   ▼
Злоумышленник
   │
   └── поддельный сертификат
            │
            ▼
      Проверка доверия
            │
            ▼
          ОШИБКА

Поэтому сертификаты являются одним из важных элементов защиты от определённых вариантов MitM.

Что должен контролировать сетевой администратор

Сетевой администратор должен контролировать состояние сертификатов используемых сервисов.

В частности: - срок действия; - доменные имена; - цепочку доверия; - удостоверяющий центр; - алгоритмы и параметры ключей; - назначение сертификата; - состояние отзыва; - хранение закрытых ключей; - своевременное продление.

Для большого количества серверов полезно использовать централизованный мониторинг.

Например:

Сервер 1 ── сертификат ── 120 дней
Сервер 2 ── сертификат ── 45 дней
Сервер 3 ── сертификат ── 7 дней

Администратор должен заранее получить предупреждение:

Внимание!
Сертификат сервера 3 истекает через 7 дней.

Защита закрытого ключа

Одной из наиболее важных задач является защита закрытого ключа.

Сертификат можно сделать публично доступным.

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

Упрощённо:

Сертификат
    │
    └── можно передавать клиентам

Закрытый ключ
    │
    └── хранить только на защищённой системе

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

Поэтому необходимо: - ограничивать доступ к ключу; - использовать защищённые хранилища; - устанавливать правильные права доступа; - не передавать ключ через незащищённые каналы; - своевременно менять ключи при компрометации; - отзывать соответствующие сертификаты.

Сертификат — не просто «шифрование»

Распространённая ошибка — считать:

«Сертификат нужен для шифрования сайта».

Это упрощённое представление.

Сертификат сам по себе не является механизмом шифрования всего трафика.

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

В HTTPS сертификат является частью более сложного процесса установления TLS-соединения.

Упрощённо:

Сертификат
     ↓
Проверка подлинности
     ↓
Установление доверия
     ↓
TLS
     ↓
Согласование защищённого соединения
     ↓
Шифрование и защита трафика

Упрощённая общая схема работы

Весь процесс можно представить следующим образом:

                    Удостоверяющий центр
                           │
                           │ подписывает
                           ▼
                    Сертификат сервера
                           │
                           ▼
Клиент ───────────────► Сервер
  │                        │
  │     Сертификат         │
  │◄───────────────────────│
  │
  │ Проверка:
  │ ├─ срок действия
  │ ├─ имя
  │ ├─ подпись
  │ ├─ цепочка доверия
  │ └─ назначение
  │
  ▼
Установка TLS
  │
  ▼
Защищённое соединение
  │
  ▼
Передача данных

Основные виды сертификатов по назначению

Сертификаты могут использоваться для различных целей.

Сертификаты серверов

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

Пример:

HTTPS

Сертификаты клиентов

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

Пример:

mTLS

Сертификаты электронной подписи

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

Сертификаты удостоверяющих центров

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

Сертификаты в сетевой инфраструктуре

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

Например:

             Сетевая инфраструктура
                       │
       ┌───────────────┼───────────────┐
       │               │               │
      HTTPS           VPN             Почта
       │               │               │
    Сертификат      Сертификат      Сертификат

Также сертификаты могут использоваться в: - корпоративных порталах; - API; - прокси-серверах; - VPN; - системах удалённого доступа; - почтовых системах; - системах мониторинга; - сетевых устройствах; - системах аутентификации.

Практический пример

Предположим, организация имеет внутренний портал:

https://portal.company.local

Сервер предоставляет сертификат.

В сертификате указано:

Subject:
portal.company.local

Issuer:
Company Intermediate CA

Цепочка:

Company Root CA
        │
        ▼
Company Intermediate CA
        │
        ▼
portal.company.local

Рабочие компьютеры организации доверяют:

Company Root CA

Поэтому браузер может построить цепочку:

portal.company.local
        ↓
Company Intermediate CA
        ↓
Company Root CA
        ↓
Доверие

Соединение устанавливается без предупреждения.

Что произойдёт после компрометации закрытого ключа

Рассмотрим ситуацию:

Сервер
  │
  └── закрытый ключ
          │
          ▼
     украден злоумышленником

Администратор не должен просто заменить файл сертификата и считать проблему решённой.

Необходимо: 1. прекратить использование скомпрометированного ключа; 2. создать новую ключевую пару; 3. получить новый сертификат; 4. при необходимости отозвать старый сертификат; 5. проверить системы, где использовался старый ключ; 6. проанализировать возможные последствия компрометации.

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

Типичные ошибки пользователей и администраторов

Ошибка 1. Игнорирование предупреждений

Пользователь нажимает:

Продолжить несмотря на предупреждение

не выясняя причину.

Ошибка 2. Просроченные сертификаты

Администратор не контролирует сроки действия.

Ошибка 3. Неправильное доменное имя

Сертификат не соответствует адресу сервера.

Ошибка 4. Установка неизвестного корневого сертификата

Пользователь или администратор добавляет неизвестный сертификат в доверенное хранилище.

Ошибка 5. Небезопасное хранение закрытого ключа

Ключ доступен слишком большому числу пользователей или сервисов.

Ошибка 6. Использование одного ключа слишком долго

При необходимости ключ должен быть заменён в соответствии с политикой безопасности.

Основные понятия

Термин Значение
Цифровой сертификат документ, связывающий идентификатор и открытый ключ
Public Key открытый ключ
Private Key закрытый ключ
CA удостоверяющий центр
Root CA корневой удостоверяющий центр
Intermediate CA промежуточный удостоверяющий центр
PKI инфраструктура открытых ключей
TLS протокол защищённого сетевого взаимодействия
HTTPS HTTP поверх TLS
CRL список отозванных сертификатов
OCSP механизм проверки статуса сертификата
SAN альтернативные имена субъекта сертификата
mTLS TLS с взаимной аутентификацией сторон

Главное, что необходимо запомнить

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

Главная идея:

Идентификатор
      +
Открытый ключ
      +
Подпись доверенного УЦ
      ↓
Цифровой сертификат

При подключении по HTTPS клиент проверяет сертификат.

Основные проверки:

Срок действия
       +
Имя
       +
Цифровая подпись
       +
Цепочка доверия
       +
Назначение
       +
Статус
       ↓
Решение о доверии

Сертификаты являются важным элементом защиты от определённых вариантов Man-in-the-Middle и используются в TLS, HTTPS, VPN, электронной подписи, корпоративных системах и других технологиях.

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

Заключение

Цифровые сертификаты являются одним из фундаментальных механизмов современной информационной безопасности.

Они позволяют решить важную проблему: как связать открытый ключ с определённым субъектом и убедиться, что этот ключ не был просто выдан неизвестным участником сети.

Основой доверия является инфраструктура открытых ключей:

Корневой УЦ
     ↓
Промежуточный УЦ
     ↓
Сертификат
     ↓
Открытый ключ
     ↓
TLS
     ↓
Защищённое соединение

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

Таким образом, сертификаты связывают изученные ранее темы — криптографию, аутентификацию, HTTPS, защиту трафика и противодействие Man-in-the-Middle — в единую систему доверенного сетевого взаимодействия.