OpenSSL: подписать корневой сертифкат?

Question

[Alukardd]

Здравствуйте!


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


Можно ли? И как?

Answer 1

[Maximus43]

Что-то вы путаете. Если новый «корневой» сертификат подписать старым корневым сертификатом, то это будет обычный промежуточный сертификат. Ничего этим вы не выиграете. Срок действия изданных сертификатов не может быть больше, чем сертификат подписанта.
Корневой сертификат можно переиздать со старым ключом, тогда у нового корневого сертификата будет такой же AKI (Authority Key Identifier), что и у старого. Это позволит использовать новый корневой сертификат для подписи новых сертификатов, которые будут валидны со старым корневым сертификатом.
Уточните, что конкретно вы хотите?

Comments

[Alukardd]

Опачки, походу народ в своих изысканиях (схему не я рожал), забыл пару вещей… Спасибо!
Сейчас попробую проверить, походу намечается полный **здецкосяк.

[Alukardd]

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

А вы попробуйте ;-) Я только что выпустил такой, и причём на данное число он законно считается валидным. Что произойдет когда истечёт родитель это другой вопрос, причём лично наш, т.к. проверяющее ПО самописное и будет вести себя так как ему скажут.

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

[Maximus43]

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

Корневой сертификат всегда подписан сам собой, иначе это не корневой сертификат.

[Alukardd]

Нет возможности прописать 2 корневых сертификата физически, а не программно.
Хорошо, а промежуточный может сам себя перевыдать и подписать предыдущим? Чисто программные ограничения есть?
Интересует в том числе и с точки зрения не только openssl, но и M$ ADCS, если знакомы с таковым.

[Maximus43]

Все програмные продукты, на базе которых развертывают PKI инфраструктуру соблюдают примерно одинаковый набор правил. OpenSSL стоит немного особняком, так как это не полноценный PKI, а набор инструментов, которыми можно выполнять криптографические операции.
Важно понимать, что подпись одного сертификата другим порождает цепочку. Корневой сертификат — это начало цепочки, он как бы замкнут сам на себя. Один и тот же сертификат можно подписать несколькими подписантами (корневыми или промежутчоными, без разницы), тогда получится два сертификата с одинаковым AKI, т.е. они будут валидны относительно нескольких подписантов, плюс все сертификаты ниже по цепочке могут верифицироваться относительно нескольких корневых сертификатов. В терминологии PKI это называется «cross-certification».
Если же вы промежуточный сертификат подпишите старым промежуточным сертификатом, то вы просто нарастите цепочку сертификатов, которая все равно будет упираться в один и тот же корневой сертификат. «Сам себя перевыдать» — это использовать старый закрытый ключ? Это просто породит дополнительное звено в цепочке, где два последних CA имеют одинаковый AKI. Не самая лучшая комбинация.
Вы опишите детальнее, в чем у вас проблема. Может тогда смогу предложить решение.

[Alukardd]

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

Цель такова, что самая верхняя единица (вернее сказать тот сертификат, который будет прошит клиентским устройствам), должен в будущем перевыпускаться самостоятельно с подписанием своей предыдущей итерации. Смена закрытого ключа обязательна!
Вариант как я понял тут один, и тот если такое возможно: создать корневой УЦ и выпустить сертификат разово, далее его можно будет навсегда забыть. Создать ему подчинённый ЦС, и вот как раз-таки этот сертификат и прошить клиентским устройствам. А далее от этого подчинённого УЦ и строить всю PKI как будто это корневой УЦ. Только вот последующие сертификаты он должен подписывать не тем УЦ, что был создан как корневой, а своим предыдущим.

Надеюсь, что смог объяснить суть.

Answer 2

[Сардар]

Зачем? У предыдущего истекает срок, его подпись игнорируется. К тому же вы выпускаете корневой CA, которому доверяют по умолчанию при любых условиях.

Comments

[Alukardd]

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

Собственно давайте вернёмся к вопросу — как это сделать, а не зачем это делать.

Answer 3

[AnViar]

Теоретически:
1. Генерируем новый секретный ключ
2. Создаём запрос на сертификат
3. Геннерируем новый сертификат, используя старый сертификат, старый ключ и запрос нового сертификата.
Практически — не уверен, что всё будет хорошо с истекшим сертификатом.

Comments

[Alukardd]

Старый сертификат не будет истекшим, просто требуется его периодическая замена.
Да, именно такие мысли у меня и есть, на самом деле вопросы начались не с OpenSSL, а с грёбанного M$ ADCS. И походу там именно программные ограничение на возможность быть корневым УЦ при наличии подписанного сертификата.

[AnViar]

Maximus43 интересную идею подкинул. Я такого не знал. Попробуйте.

Answer 4

[Maximus43]

Честно говоря, я так и не понял суть. :-)
Понял, что вы собираетесь создать корневой ЦС в режиме Off-line root. Потом вы создаете промежуточный ЦС, подписанный корневым, и этим ЦС будете подписывать сертификаты конечных устройств. Или вы просто загрузите сертификат (публичный ключ) промежуточного ЦС на свои устройства, чтобы они, видимо, проверяли сертификаты конечных пользователей.
А вот дальше я совсем ничего не понял. Кто должен подписывать сертификаты? Сертификаты для кого? Что значит предыдущий УЦ?

Comments

[Alukardd]

Давайте абстрагируемся от того что будет за пределами тех УЦ о которых идёт речь. Там будет достаточно сложная самописная система для их использования. Я опишу лишь шапку, в которую входят УЦ. После всего сказанного Вами и ещё некоторыми уважаемыми людьми, схема приобрела следующий вид, который и хочется что бы работал.
— корневой off-line УЦ
— подчинённый off-line УЦ (*)
— +2 подчинённых on-line УЦ подписанных подчинённым off-line УЦ, они и будут работать с пользователями/устройствами.
Такова иерархия УЦ.

Надо что бы второй и последующие сертификаты подчинённого УЦ (тот что отмечен звёздочкой) подписывались не корневым (его надо использовать лишь раз и тот фиктивно), а им самим. Т.е. во все клиентские устройства будет прошит именно сертификат подчинённого УЦ (*). И они будут с ним работать как с самой верхней точкой иерархии.
При этом, на всё том же злополучном подчинённом off-line УЦ (*), при каждом перевыпуске сертификата должна происходить обязательная перегнерация закрытого ключа!

[Maximus43]

Я примерно понял, что вы хотите. Не понял зачем, но это дело ваше. :-)
Тут расклад такой: подписывать подчиненый ЦС (со звездочкой) им самим нельзя, он просто превратится в корневой, который вы потом перевыпустить с новым ключом не сможете, так как все сертификаты ниже потеряют цепочку.
Чтобы валидация происходила нормально, проверяющей стороне в любом случае нужен корневой сертификат, и это ваш корневой off-line в схеме. Он может не выпускать листы отзыва (CRL), но он должен быть и иметь длительный срок действия (30 лет). Затем вы можете перевыпускать подчиненный ЦС (*) сколько угодно раз и с новым закрытым ключом. Которым потом подписывать издающие ЦС, а те будут выпускать конечные сертификаты. Если цепочка будет строиться до корневого ЦС, то валидация пройдет. В устройства придется прописывать корневой ЦС. Действительность подчиненного ЦС (*) и его версий (с новыми ключами) можно регулировать листом отзыва корневого ЦС.
Вся эта система достаточна нетривиальна в разрезе PKI. Я бы на вашем месте обратился к специалистам, которые бы получили более полную информацию о вашей системе и ограничениях, и предложили бы оптимальное решение в соответствии с принципами PKI.

[Alukardd]

Спасибо за помощь и попытки вникнуть!
Я скажу даже более, мы пообщались с начальником отдела разработки КриптоПро ;-) Всё равно конечного решения пока нету…
Я ещё поговорю с теми людьми кто проектировал это решение и попробуем прийти к конечной мысли вновь. Я всего-лишь админ ;-)

[Alukardd]

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