Как я могу убедиться, что CSR не зависит от отозванного закрытого ключа?

Содержание

Вопрос или проблема
Ответ или решение
1. Хранение хешей открытых ключей
2. Проверка на основании CRL и OCSP
3. Организационные Процессы
Заключение

Вопрос или проблема

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

Существует ли технический способ на стороне CA (помимо организационных процессов), чтобы гарантировать, что закрытый ключ, использованный для генерации CSR, не использовался в уже аннулированном сертификате? Тогда идея заключалась бы в том, чтобы отклонить CSR, указав, что закрытый ключ не может быть доверен.
Этот вопрос касается сертификатов RSA или ECC.

Для RSA каждый закрытый ключ имеет только один открытый ключ. CSR содержит открытый ключ, который может позволить CA проверить, какие серийные номера были аннулированы, и отклонить новые CSR, содержащие этот открытый ключ. Так что технически это возможно, но нужно учесть, насколько это разумно. Индивидуум может создать столько закрытых ключей, сколько пожелает.

Для получения дополнительной информации о том, почему у закрытого ключа должен быть только один открытый ключ, пожалуйста, смотрите: https://stackoverflow.com/questions/9375044/can-we-have-multiple-public-keys-with-a-single-private-key-for-rsa

Вы можете, сохраняя хеши открытых ключей. Напомним, что закрытый/открытый ключ имеют отношение 1:1. Вы можете сгенерировать хеш открытого ключа с помощью
openssl req -in csr.txt -noout -pubkey | sha256sum.

me@linux:~ $ openssl req -in csr.txt -noout -pubkey
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAhPMown8tbyJKu0YfJFo3
TuJ3NywNsqdVcjdCC01FJlPvCeK0Ur7j0L1WGEbVzl38xzZW92E6OhAoOubcpjxM
yZThL/6PLC9cAxYGwB8ZzG+HS9ogo8BCOA3QVXVPkXl3PPqde/nBWvQpz2xHpkwg
7V6n/V1CTNcPP9MySuDPOVrQCtC9PC8qm8LBX5L0FL4Dy350dEhG6vAJY5U/P9cf
1jYhZypuCRuTjFJ7ON1RP40z+KCnnmSyLih59nijuiHy/gn+AayWdTuYbJBA6hen
GjmD9UxR+bU8u6Z7cPbohuyn88aPw7dbWoaT/CCWtWsKIYo8epbH0nbzx0gUI5wb
zQIDAQAB
-----END PUBLIC KEY-----
me@linux:~ $ openssl req -in csr.txt -noout -pubkey | sha256sum
59c6aa130a480f1139af7ebaa5a1c3fd7e8dec8907bc711a15626de6333f2892  -

Ответ или решение

Чтобы гарантировать, что запрос на сертификат (CSR) не использует отозванный закрытый ключ, вам нужно учитывать несколько техник и методов, доступных на стороне центра сертификации (CA). Важным моментом является то, что законы криптографии утверждают, что на каждый закрытый ключ существует только один открытый ключ. Это значит, что если некий ключ был использован для генерации сертификата, то мы можем проверить, был ли этот сертификат отозван, используя CRL (Certificate Revocation List) или протокол OCSP (Online Certificate Status Protocol).

Вот несколько ключевых аспектов и шагов, которые помогут вам избежать ситуации, когда CSR будет зависеть от отозванного закрытого ключа:

1. Хранение хешей открытых ключей

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

openssl req -in csr.txt -noout -pubkey | sha256sum

Этот хеш можно сохранить в базе данных ключей. При поступлении нового CSR CA может быстро проверить, существует ли уже хеш такого открытого ключа в списке отозванных.

2. Проверка на основании CRL и OCSP

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

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

3. Организационные Процессы

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

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

Заключение

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