Доброе утро.
Различия (насколько я знаю) минимальны. Сначала общий обзор без отечественной специфики: кросс-сертификат обычно формируется когда у
2 одноуровневых УЦ уже есть корневые сертификаты и чтобы создать общее пространство доверия между клиентами двух УЦ создается
пара кросс-сертификатов, то есть корневой сертификат одного УЦ преобразуется в запрос и направляется в другой УЦ. И наоборот. При этом если у клиента УЦ 1 есть только корневой сертификат УЦ 1, этот клиент тем не менее может доверять сертификатам выпущенным УЦ 2, так как УЦ 1 создал "переходной мостик" (кросс-сертификат) и присоединил пространство доверия УЦ 2 к своему. И наоборот, через второй кросс клиент УЦ2 сможет доверять сертификату выданному УЦ1. Получится как бы общее пространство доверия, но с несколькими корнями. Состав кросс сертификата определяет УЦ, который его выпустил, то есть один из пары кроссов может отличаться от другого не только по открытому ключу и владельцу, но и по составу расширений.
Аналогично применяется когда УЦ один, но возникла необходимость сменить закрытый ключ УЦ - например, при переходе доменного УЦ с sha-1 на sha-2 производится аналогичная процедура - создается пара кросс-сертификатов. При смене алгоритма правда есть дополнительные ограничения - новые сертификаты не должны подписываться старым ключом после смены алгоритма. Клиентские сертификаты будут действовать если есть хотя бы один его корневой (либо старый либо новый).
Важная деталь, что в норме кросс-сертификат действует в промежуток, в котором перекрываются даты действия корневых сертификатов и для успешного формирования пары (и потом для проверки цепочки) текущая дата должна попадать в этот промежуток. Это вполне очевидно, но все же про это можно легко забыть и упустить. На своем доменном УЦ при смене алгоритма я этого не учел и у меня сформировался один кросс из пары, так как для другого дата оказалась недопустимой. При возврате даты ситуация повторилась - один из пары, повторил еще раз - вышла пара. Плюс первый раз когда алгоритм не сменился. В итоге у меня получилось 5 корневых сертификатов и маленькая тележка кроссов. Конечные есть только у первого и последнего.
Следовательно, через кросс цепочка построится только в тот же промежуток когда он действует. Например, сертификат УЦ 1 действует с 2018 до 2033 года, сертификат УЦ 2 действует с 2021 до 2035 года, при этом кросс будет действовать с 2021 до 2033 года и сертификаты УЦ 2 действующие до 2034 года не смогут пройти проверку после окончания кросса если нет корневого сертификата УЦ 2. Равно как и сертификаты выданные УЦ 1 до начала кросса.
Подчиненный УЦ изначально не имеет корневого сертификата (не создает своего пространства доверия), а подает запрос на сертификат в корневой УЦ (в единое пространство доверия). Состав сертификата подчиненного УЦ определяется корневым УЦ. При этом корневой его изначально вписывает в период действия своего сертификата, то есть нет каких-либо сертификатов выданных подчиненным УЦ до момента выпуска сертификата подчиненного УЦ. Не существует тех промежутков дат как до и после кросса, в которые могут быть выданы конечные сертификаты. Если конечно подчиненный УЦ позднее не сделает на своем ключе отдельный корневой сертификат и не укажет срок действия дольше.
Применительно к отечественным УЦ сразу становится понятно почему регулятор перешел от схемы кросс-сертификатов на схему подчиненных УЦ. Правда, с датами все еще интереснее - сформировали кросс как-то нестандартно? Или тоже вышел один из пары?
Пока в детали не смотрел - поиск на портале УФО с 2 ограничениями по дате выдает пустой список: типа с 1 июля 2021 по 1 января 2022 ничего не выпускалось. Хотя если просто поставить с 1 июля 2021 что-то есть, среди 2022 попадался сентябрь 2021.
Отредактировано пользователем 8 февраля 2022 г. 10:56:06(UTC)
| Причина: Не указана
