Основы инфраструктуры открытых ключей PKI в криптографии

LinuxBeginner
Практиковаться сейчас

Введение

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

Вы получите практический опыт работы с утилитой командной строки openssl для выполнения основных функций PKI. Вы выступите в роли собственного Центра Сертификации (Certificate Authority, CA), выпустите сертификат для веб-сервера, проверите цепочку доверия сертификата и, наконец, отзовете этот сертификат. Все операции будут выполняться в каталоге ~/project.

Понимание основ PKI

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

Инфраструктура открытых ключей (PKI)

PKI — это структура, предназначенная для повышения безопасности в электронных коммуникациях. Она использует криптографию с открытым ключом для связывания открытых ключей с соответствующими идентификаторами пользователей посредством Центра Сертификации (Certificate Authority, CA). Эта привязка устанавливается посредством процесса регистрации и выдачи.

Центр Сертификации (CA)

Центр Сертификации — это доверенная организация, которая выдает цифровые сертификаты. CA выступает в роли доверенной третьей стороны, которой доверяют как субъект (владелец) сертификата, так и сторона, полагающаяся на этот сертификат. Основная роль CA заключается в цифровой подписи и публикации открытого ключа, привязанного к данному пользователю.

Цифровой Сертификат

Цифровой сертификат — это электронный документ (часто соответствующий стандарту X.509), который содержит:

  • Открытый ключ владельца.
  • Идентифицирующую информацию владельца (например, имя или доменное имя).
  • Информацию и цифровую подпись эмитента (CA).
  • Срок действия (дата начала и окончания).
  • Уникальный серийный номер.

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

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

Цепочка доверия (или цепочка сертификатов) — это последовательность сертификатов, начинающаяся с сертификата конечного объекта (например, для example.com) и заканчивающаяся сертификатом корневого CA.

  1. Сертификат Корневого CA (Root CA Certificate): Это самоподписанный сертификат от высшего органа — Корневого CA. Эти сертификаты предварительно установлены в "хранилище доверия" вашего браузера или операционной системы.
  2. Сертификат(ы) Промежуточного CA (Intermediate CA Certificate(s)): Крупные CA часто используют промежуточные CA для выдачи сертификатов конечным пользователям, тем самым защищая корневой ключ. Промежуточный сертификат подписывается корневым CA.
  3. Сертификат Конечного Объекта (End-Entity Certificate): Это сертификат, выданный конкретному серверу или пользователю. Он подписывается промежуточным CA (или напрямую корневым CA в более простых конфигурациях).

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

На следующем шаге вы создадите свой собственный Корневой CA.

Создание центра сертификации

На этом шаге вы выступите в роли Центра Сертификации (CA) и создадите его основные компоненты: закрытый ключ и самоподписанный корневой сертификат. Все команды будут выполняться в терминале, а все файлы будут созданы в вашем текущем каталоге, ~/project.

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

openssl genpkey -algorithm RSA -out ca.key

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

Выполните следующую команду для генерации сертификата. Мы используем аргумент -subj для неинтерактивной передачи информации о субъекте сертификата.

openssl req -x509 -new -nodes -key ca.key -sha256 -days 365 -out ca.pem -subj "/C=US/ST=California/L=MountainView/O=MyLab/CN=MyLabRootCA"

Разберем эту команду:

  • req: Утилита для создания запросов на подпись сертификата (CSR) и самих сертификатов.
  • -x509: Выводит самоподписанный сертификат вместо CSR.
  • -new: Создает новый сертификат.
  • -nodes: "No DES", что означает, что закрытый ключ не будет зашифрован парольной фразой. Это сделано для упрощения в нашей лабораторной работе.
  • -key ca.key: Указывает закрытый ключ, который будет использоваться для подписи.
  • -sha256: Использует алгоритм хеширования SHA-256 для подписи.
  • -days 365: Устанавливает срок действия сертификата на 365 дней.
  • -out ca.pem: Указывает выходной файл для нового сертификата.
  • -subj "/C=.../CN=...": Предоставляет сведения о субъекте. CN (Common Name, Общее Имя) является основным идентификатором, который для CA — это его имя.

Теперь у вас есть закрытый ключ CA (ca.key) и корневой сертификат (ca.pem). Вы можете просмотреть содержимое вашего нового сертификата CA:

openssl x509 -in ca.pem -text -noout

Прокрутите вывод и обратите внимание, что поля Issuer (Эмитент) и Subject (Субъект) идентичны, что подтверждает его самоподписанность.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            ...
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, ST = California, L = MountainView, O = MyLab, CN = MyLabRootCA
        Validity
            Not Before: ...
            Not After : ...
        Subject: C = US, ST = California, L = MountainView, O = MyLab, CN = MyLabRootCA
        Subject Public Key Info:
            ...

Выпуск серверного сертификата

На этом шаге вы смоделируете запрос сертификата от владельца сервера. Вы сгенерируете закрытый ключ и Запрос на Подпись Сертификата (CSR) для сервера, а затем используете ваш CA из предыдущего шага для подписи CSR и выпуска действительного сертификата.

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

openssl genpkey -algorithm RSA -out server.key

Далее создайте Запрос на Подпись Сертификата (CSR). CSR — это блок закодированного текста, содержащий открытый ключ и другую информацию, которая будет включена в сертификат, такую как название организации и доменное имя. CSR отправляется в CA для подписи.

openssl req -new -key server.key -out server.csr -subj "/C=US/ST=California/L=MountainView/O=MyWebServer/CN=example.com"

Обратите внимание, что для сертификата сервера CN (Common Name, Общее Имя) должно совпадать с доменным именем сервера, в данном случае, example.com.

Теперь, выступая в роли CA, вы подпишете CSR сервера (server.csr) закрытым ключом вашего CA (ca.key). Это действие создает окончательный сертификат сервера (server.crt).

openssl x509 -req -in server.csr -CA ca.pem -CAkey ca.key -CAcreateserial -out server.crt -days 300 -sha256

Рассмотрим новые опции:

  • x509 -req: Указывает OpenSSL обработать CSR.
  • -in server.csr: Входной файл CSR.
  • -CA ca.pem: Сертификат CA, который будет использоваться в качестве эмитента.
  • -CAkey ca.key: Закрытый ключ CA для подписи.
  • -CAcreateserial: Создает и управляет файлом серийного номера (ca.srl), который необходим для обеспечения того, чтобы каждый сертификат, выданный CA, имел уникальный серийный номер.
  • -days 300: Срок действия для сертификата сервера. Он должен быть короче срока действия сертификата CA.

Наконец, проверьте только что созданный сертификат сервера.

openssl x509 -in server.crt -text -noout

В выводе обратите внимание на поля Issuer (Эмитент) и Subject (Субъект). Issuer должен быть вашим CA (MyLabRootCA), а Subject — вашим сервером (example.com). Это подтверждает, что сертификат был корректно выдан вашим CA.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: ...
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, ST = California, L = MountainView, O = MyLab, CN = MyLabRootCA
        Validity
            Not Before: ...
            Not After : ...
        Subject: C = US, ST = California, L = MountainView, O = MyWebServer, CN = example.com
        ...
    Signature Algorithm: sha256WithRSAEncryption
         ...

Проверка цепочки сертификатов

На этом шаге вы узнаете, как проверить цепочку сертификатов. Это процесс, который клиент (например, веб-браузер) выполняет для определения надежности сертификата сервера. Клиент проверяет, был ли сертификат подписан CA, которому он доверяет.

Вы можете использовать команду openssl verify для выполнения этой проверки. Вам необходимо сообщить OpenSSL, каким CA вы доверяете, предоставив корневой сертификат.

Выполните следующую команду для проверки server.crt по отношению к вашему корневому сертификату ca.pem:

openssl verify -CAfile ca.pem server.crt

Вывод должен быть следующим:

server.crt: OK

Этот статус OK подтверждает, что:

  1. Сертификат server.crt действительно был подписан закрытым ключом, соответствующим открытому ключу в ca.pem.
  2. Срок действия сертификата не истек.

Теперь посмотрим, что произойдет, если у проверяющего (верификатора) нет нашего CA в списке доверенных CA. Вы можете смоделировать это, выполнив команду verify без опции -CAfile.

openssl verify server.crt

На этот раз команда завершится ошибкой, похожей на следующую:

C = US, ST = California, L = MountainView, O = MyWebServer, CN = example.com
error 20 at 0 depth lookup: unable to get local issuer certificate
error server.crt: verification failed

Ошибка "unable to get local issuer certificate" (невозможно получить локальный сертификат эмитента) означает, что система не смогла найти сертификат эмитента (MyLabRootCA) в своем хранилище доверенных сертификатов по умолчанию. Это демонстрирует, почему для клиентов крайне важно иметь корневой сертификат CA для установления цепочки доверия.

Имитация отзыва сертификата

На этом шаге вы узнаете, как отозвать сертификат. Отзыв — это критически важный процесс, который применяется, когда закрытый ключ сертификата скомпрометирован или сертификат больше не нужен до истечения его естественного срока действия. Управление этим осуществляется с помощью Списка Отозванных Сертификатов (CRL — Certificate Revocation List).

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

Для управления отзывом openssl нуждается в небольшом конфигурационном файле, чтобы знать, где искать файлы базы данных CA (index.txt и serial). Скрипт настройки для этой лаборатории уже создал необходимый каталог (my-ca) и файлы. Теперь создайте конфигурационный файл.

Используйте команду cat для создания my-ca.conf:

cat << EOF > my-ca.conf
[ ca ]
default_ca = CA_default

[ CA_default ]
dir = ./my-ca
database = \$dir/index.txt
serial = \$dir/serial
private_key = ca.key
certificate = ca.pem
default_md = sha256
policy = policy_anything
crl_extensions = crl_ext
default_crl_days = 30

[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

[ crl_ext ]
authorityKeyIdentifier=keyid:always
EOF

Этот конфигурационный файл сообщает OpenSSL, как работать в качестве Центра Сертификации (CA). Вот что делает каждый раздел:

  • default_ca = CA_default: Указывает на основной раздел конфигурации CA.
  • dir = ./my-ca: Рабочий каталог CA для файлов базы данных.
  • database = $dir/index.txt: База данных сертификатов (отслеживает выданные/отозванные сертификаты).
  • serial = $dir/serial: Файл серийного номера для уникальных идентификаторов сертификатов.
  • private_key = ca.key: Закрытый ключ CA для подписи сертификатов.
  • certificate = ca.pem: Собственный сертификат CA.
  • default_md = sha256: Алгоритм хеширования для подписей (SHA-256).
  • policy = policy_anything: Правила проверки сертификатов.
  • crl_extensions = crl_ext: Опции форматирования CRL.
  • default_crl_days = 30: Срок действия CRL (30 дней).
  • countryName = optional: Код страны.
  • stateOrProvinceName = optional: Штат/провинция.
  • localityName = optional: Город/местоположение.
  • organizationName = optional: Название организации.
  • organizationalUnitName = optional: Отдел.
  • commonName = supplied: Доменное имя/имя сервера (требуется).
  • emailAddress = optional: Адрес электронной почты.
  • authorityKeyIdentifier=keyid:always: Включает идентификатор CA в CRL для проверки.

Этот конфигурационный файл является "руководством по эксплуатации" для вашего CA. Он указывает OpenSSL, где искать ключи, как хранить сертификаты и какие правила следовать при выпуске и отзыве сертификатов.

Теперь отзовем сертификат сервера (server.crt). Эта команда найдет серийный номер сертификата и пометит его как отозванный в файле базы данных index.txt.

openssl ca -config my-ca.conf -revoke server.crt

Вы увидите вывод, подтверждающий отзыв.

После отзыва необходимо сгенерировать и опубликовать обновленный CRL.

openssl ca -config my-ca.conf -gencrl -out my-ca.crl

Это создает файл my-ca.crl, который содержит список отозванных сертификатов.

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

openssl verify -CAfile ca.pem -CRLfile my-ca.crl -crl_check server.crt

Теперь команда завершается неудачей с четким сообщением:

C = US, ST = California, L = MountainView, O = MyWebServer, CN = example.com
error 23 at 0 depth lookup: certificate revoked
error server.crt: verification failed

Ошибка "certificate revoked" (сертификат отозван) подтверждает, что наш процесс отзыва прошел успешно. Клиент, проверяя CRL, правильно определил, что сертификат для example.com больше не является надежным.

Резюме

Поздравляем! Вы успешно завершили эту лабораторию по основам Инфраструктуры Открытых Ключей (PKI). Вы получили практический опыт в выполнении фундаментальных операций, которые обеспечивают безопасность цифровых коммуникаций.

В этой лаборатории вы научились:

  • Понимать основные концепции PKI, Центров Сертификации (CA) и цепочек доверия.
  • Создавать собственный простой Корневой CA путем генерации закрытого ключа и самоподписанного сертификата.
  • Выпускать сертификат сервера, подписывая Запрос на Подпись Сертификата (CSR) ключом вашего CA.
  • Проверять цепочку доверия сертификата с помощью команды openssl verify.
  • Отзывать сертификат и подтверждать его отозванный статус путем генерации и использования Списка Отозванных Сертификатов (CRL).

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