2

Я нуб, рассматривающий центры сертификации. Я следовал этой статье некоторое время назад, чтобы настроить свой собственный центр сертификации и с его помощью настроить мою собственную сеть freelan VPN:https://github.com/freelan-developers/freelan/wiki/X509-certificates-generation

В общем, все, что мне нужно было сделать, это позвонить:

openssl req -new -x509 -extensions v3_ca -keyout key/ca.key -out crt/ca.crt -config ca.cnf

Проблема в том, что срок действия моего сертификата ca.crt , который я считаю открытым ключом для ca.key истек в соответствии с openssl . Я использовал этот сертификат для подписи других ключей, хотя и не хотел бы проходить это снова.

Есть ли способ, которым я могу просто создать новый файл ca.crt с более длительным сроком годности?

Я не помню, нужно ли было где-то устанавливать дату истечения срока действия ca.crt , но я не верю, что сделал, потому что она действительна только в течение 1 месяца. Я хотел бы знать, ожидается ли это и рекомендуется ли это или фактически ошибка, которую я сделал по пути? Как долго должен быть действителен сертификат ca.crt ?

Я нашел в сети разные команды, но не уверен, какая из них мне подходит, например: https://stackoverflow.com/questions/13295585/openssl-certificate-verification-on-linux https://serverfault.com/questions/306345/сертификации, орган-корневого сертификата экспирации-и-обновление

|источник

2 ответа2

4

Как я могу обновить свой ключ подписи центра сертификации?

У вас есть две проблемы для решения. Во-первых, это непрерывность сертификатов конечного объекта (сервера и пользователя). Во-вторых, это смена Root CA.

Есть ли способ, которым я могу просто создать новый файл ca.crt с более длительным сроком годности?

Да, но смотрите детали ниже.

Первая проблема - непрерывность сертификатов конечных объектов (сервер и пользователь) - в основном решается с помощью того же открытого ключа, когда вы переворачиваете свой корневой ЦС.

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

Вторая проблема, связанная с корневым центром сертификации, должна возникать из-за истечения срока ее действия. Это та же проблема, что и при повторной сертификации корневого ЦС, поскольку хэш изменен с SHA-1 на SHA-256 для соответствия базовым требованиям CA/Browser. Ряд CA сделали это в реальной жизни.

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

Чтобы пролонгировать ЦС, вам нужно создать "эквивалентный" сертификат корневого ЦС (или максимально приближенный к эквивалентному). Способ, которым пользовательские агенты однозначно идентифицируют сертификат, описан в RFC 4158, Инфраструктура открытых ключей Internet X.509: Построение пути сертификации.

Сокращение от RFC 4158 - это пара { Subject Distinguished Name, Serial Number }, которую можно использовать для уникальной идентификации сертификата в магазине. Как CA или Эмитент, вы должны гарантировать, что серийные номера являются уникальными, даже если вы проходите повторную сертификацию.

Сертификаты конечного объекта имеют дополнительные способы уникальной идентификации, включая Идентификатор ключа авторизации (AKID). Фактически, сертификат сервера может использовать хэш { Отличительного имени субъекта, серийный номер } в качестве своего AKID (если я правильно помню).

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

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

Напомним, вот вам элементы действий:

  • Использовать тот же открытый ключ для CA
  • Используйте одно и то же отличительное имя для CA
  • Использовать новый серийный номер для CA
  • Установите недавно выпущенный CA на всех клиентских машинах
  • Не переиздавать сертификаты конечных объектов
|источник
1

Согласно https://serverfault.com/questions/306345/certification-authority-root-certificate-expiry-and-renewal должна работать следующая последовательность:

openssl req -new -key key/ca.key -out key/newca.csr
openssl x509 -req -days 3650 -in key/newca.csr -signkey key/ca.key -out crt/newca.crt
|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .