Примитивы ротации

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

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

Здесь пара ключей была сгенерирована в определенный момент времени. Создаются два CSR и отправляются в два разных корневых центра (Root A и Root B). В результате получаются два отдельных сертификата (потенциально с разными сроками действия) с одним и тем же субъектом и одним и тем же ключевым материалом подложки.

Перекрестное подписание не обязательно должно происходить одновременно; между первым и вторым сертификатом может быть разрыв в несколько лет. Кроме того, нет ограничений на количество перекрестно подписанных "дубликатов" (используется с тем же субъектом и ключом) сертификатов: они могут быть перекрестно подписаны многими различными корневыми сертификатами.

Вышеописанный процесс приводит к созданию двух путей доверия: любой из root A или root B (или оба) может существовать в хранилищах доверия клиента, и листовой сертификат будет подтвержден правильно. Поскольку для обоих промежуточных сертификатов (C и D) используется один и тот же ключевой материал, поле подписи выданного листового сертификата будет одинаковым вне зависимости от того, к какому из промежуточных сертификатов было произведено обращение.

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

Эта конструкция документирована и используется в нескольких местах:

Для создания сертификата с перекрестной подписью в StarVault используйте конечную точку /intermediate/cross-sign. Здесь при создании перекрестной подписи для всех сертификатов B, которые должны быть подтверждены сертификатом A, укажите значения (key_ref, все части Subject и т. д.) для сертификата B во время промежуточной генерации. Затем подпишите этот CSR (используя конечную точку /issuer/:issuer_ref/sign-intermediate) ссылкой на cert A и предоставьте необходимые значения из cert B (например, части Subject). cert A может находиться вне StarVault. Наконец, импортируйте кросс-подписанный сертификат в StarVault с помощью конечной точки /issuers/import/cert.

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

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

Чтобы исправить это, обновите поле manual_chain у эмитентов, включив в него цепочки обеих пар. Например, если даны intA, подписанный rootA, и intB, подписанный rootB, как его кросс-подписанная версия, можно сделать следующее:

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

В этом процессе в определенный момент времени генерируется и хранится одна пара ключей. CSR (с теми же запрошенными полями) создается на основе этого общего ключевого материала и подписывается одним и тем же эмитентом в разные моменты времени, сохраняя все критические поля (субъект, эмитент и т. д.). Хотя количество перевыпусков ключа строго не ограничено, в определенный момент безопасность потребует ротации ключевого материала вместо постоянного перевыпуска.

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

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

Чтобы создать перевыпущенный корневой сертификат в StarVault, используйте конечную точку /issuers/generate/root/existing. Это позволит сгенерировать новый корневой сертификат с существующим ключевым материалом (через параметр запроса key_ref). Если процесс прошел успешно, то при чтении эмитента (через GET /issuer/:issuer_ref) оба эмитента (старый и перевыпущенный) будут отображаться в поле ответа ca_chain друг друга (если это не запрещено значением manual_chain).

Создание перевыпущенного промежуточного сертификата в StarVault состоит из трех шагов:

Если процесс перевыпуска промежуточного сертификата прошел успешно, то при чтении эмитента (через GET /issuer/:issuer_ref) оба эмитента (старый и перевыпущенный) будут иметь одинаковое поле ответа ca_chain, за исключением первой записи (если это не запрещено значением manual_chain).