Статус: Активный участник
Группы: Участники
Зарегистрирован: 14.03.2011(UTC) Сообщений: 152  Откуда: Санкт-Петербург Сказал «Спасибо»: 1 раз
Поблагодарили: 7 раз в 5 постах
|
Есть клиентский сертификат, выданный неким УЦ. У данного УЦ есть два кросс сертификата, выданных корневым УЦ. Первый кросс получен на корневом сертификате "Главный УЦ 1". Второй кросс получен на корневом сертификате "Главный УЦ 2". Клиентский сертификат: Subject: CN=Вася Issuer: CN=Любимый УЦ Signature: xxxxxx Первый кросс сертификат: Subject: CN=Любимый УЦ Issuer: CN=Главный УЦ 1 Signature: yyyyyy Второй кросс сертификат: Subject: CN=Любимый УЦ Issuer: CN=Главный УЦ 2 Signature: zzzzzz Первый корневой сертификат: Subject: CN=Главный УЦ 1 Issuer: CN=Главный УЦ 1 Signature: aaaaaa Второй корневой сертификат: Subject: CN=Главный УЦ 2 Issuer: CN=Главный УЦ 2 Signature: bbbbbb И тут возникает главный вопрос. Система строит цепочку сертификатов в любой последовательности: Вариант 1: 1) Клиентский сертификат 2) Первый кросс сертификат 3) Первый корневой сертификат Вариант 2: 1) Клиентский сертификат 2) Второй кросс сертификат 3) Второй корневой сертификат На самом деле вариантов гораздо больше, так как в системе оказывается 3 действующих корневых сертификата "Главный УЦ 1". Все представленные цепочки будут построены системой. Но только одна может является гарантированно правильной. Это когда подпись сертификата клиента проходит проверку на открытом ключе кросс сертификата и подпись кросс сертификата проходит проверку на открытом ключе корневого сертификата. Вопрос. Как задать параметры CERT_CHAIN_PARA для функции CertGetCertificateChain, чтобы получить реальную цепочку? Как с этой задачей справляется JCP? Отредактировано пользователем 21 июля 2015 г. 1:24:40(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 14.03.2011(UTC) Сообщений: 152 Откуда: Санкт-Петербург Сказал «Спасибо»: 1 раз
Поблагодарили: 7 раз в 5 постах
|
Внесу ясность с примерами на уровне окошек в Windows.
Устанавливаем в систему два корневых сертификата, "Главный УЦ 1" и "Главный УЦ 2".
В проводнике открываем сертификат пользователя. Как мы и ожидаем, цепочки нет.
Устанавливаем сертификат доверенного УЦ "Любимый УЦ" от издателя "Главный УЦ 1".
В проводнике открываем сертификат пользователя. Цепочка построена.
Удаляем сертификат доверенного УЦ "Любимый УЦ" от издателя "Главный УЦ 1".
Устанавливаем сертификат доверенного УЦ "Любимый УЦ" от издателя "Главный УЦ 2".
В проводнике открываем сертификат пользователя. Цепочка построена.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники
Зарегистрирован: 24.11.2009(UTC)
Сообщений: 965
Откуда: Crypto-Pro
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 174 раз в 152 постах
|
А почему только одна гарантировано правильная? Из вашего описания все три правильные, если считать что кросы сделаны правильно. При условии что все сертификаты стоят в хранилище то предсказать какая из цепочек вернется нельзя. Какая первая построится до самоподписаного корневого который есть в хранилище корневых и по ней проверятся все подписи + проверки на отзыв та и вернется. Что в JCP что в CSP.
PS: При этом если в сертификатах есть AuthorityKeyIdentifier с серийниками то построение цепочек может быть чуть сложнее )). Для Java еще будет зависит от типа и версии JDK. |
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 14.03.2011(UTC) Сообщений: 152 Откуда: Санкт-Петербург Сказал «Спасибо»: 1 раз
Поблагодарили: 7 раз в 5 постах
|
По моему, только одна является гарантированно правильной.
Можно, конечно, предположить, что ключевая пара в доверенных сертификатах одинаковая.
В этом случае надо проверять обе цепочки.
Списки отзывов издаются УЦ для каждого доверенного сертификата.
"Любимый УЦ" от издателя "Главный УЦ 1" имеет свою точку распространения и свой набор CRL файлов.
"Любимый УЦ" от издателя "Главный УЦ 2" имеет свою точку распространения и свой набор CRL файлов.
Надо поднять оба набора CRL (основной и инкрементный).
В CRL файлах присутствует атрибут AuthorityKeyIdentifier. Это облегчает сопоставление списка отзыва (CRL) сертификату издателя (subject: CN=Любимый УЦ).
Тогда возникает резонный вопрос, как получить все возможные "правильные"" цепочки?
В сертификате клиента ведь нет атрибута AuthorityKeyIdentifier издателя. Или всё таки есть?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,719  Сказал «Спасибо»: 500 раз
Поблагодарили: 2054 раз в 1594 постах
|
Автор: miser  По моему, только одна является гарантированно правильной.
Можно, конечно, предположить, что ключевая пара в доверенных сертификатах одинаковая.
В этом случае надо проверять обе цепочки.
Списки отзывов издаются УЦ для каждого доверенного сертификата.
"Любимый УЦ" от издателя "Главный УЦ 1" имеет свою точку распространения и свой набор CRL файлов.
"Любимый УЦ" от издателя "Главный УЦ 2" имеет свою точку распространения и свой набор CRL файлов.
Надо поднять оба набора CRL (основной и инкрементный).
В CRL файлах присутствует атрибут AuthorityKeyIdentifier. Это облегчает сопоставление списка отзыва (CRL) сертификату издателя (subject: CN=Любимый УЦ).
Тогда возникает резонный вопрос, как получить все возможные "правильные"" цепочки?
В сертификате клиента ведь нет атрибута AuthorityKeyIdentifier издателя. Или всё таки есть?
Конечно, одинаковая должна быть. Есть в издаваемых сертификатах, идентификатор ключа ЦС. |
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,719 Сказал «Спасибо»: 500 раз
Поблагодарили: 2054 раз в 1594 постах
|
 identifikator kljucha.png (40kb) загружен 62 раз(а). |
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,719 Сказал «Спасибо»: 500 раз
Поблагодарили: 2054 раз в 1594 постах
|
Автор: miser
Тогда возникает резонный вопрос, как получить все возможные "правильные"" цепочки?
1. Из проверяемого сертификата (пользователь\промежуточный) - получить идентификатор ключа ЦС (idkey) 2. В нужном хранилище (промежуточные\корневые) найти все сертификаты с idkey 3. Повторить для каждого сертификата из п.2 действия из п1. и п2. до нахождения корневого (idkey ключа ЦС = idkey ключа субъекта) |
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 14.03.2011(UTC) Сообщений: 152 Откуда: Санкт-Петербург Сказал «Спасибо»: 1 раз
Поблагодарили: 7 раз в 5 постах
|
Идентификатор ключа субъекта (idkey), это значение хеш функции SHA1 над открытым ключом в сертификате. Но мы говорим, что "ключевая пара в доверенных сертификатах одинаковая". Значит, "Идентификатор ключа субъекта" будет одинаковый. Что же их отличает, эти ключи ? 1) "Любимый УЦ" от издателя "Главный УЦ 1" 2) "Любимый УЦ" от издателя "Главный УЦ 2" Да, у них серийные номера разные. И в разделе "идентификатор ключа центра сертификации" надо брать серийный номер ключа издателя. Далее, проверять совпадение номеров выявленного доверенного/корневого сертификата. Для пущей гарантии, можно перепроверить и строку издателя. Вот и получается, что у нас реально будет только одна "правильная" цепочка сертификатов. Отредактировано пользователем 21 июля 2015 г. 14:29:16(UTC)
| Причина: добавли пример сертификатов УЦ
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,719 Сказал «Спасибо»: 500 раз
Поблагодарили: 2054 раз в 1594 постах
|
Автор: miser Идентификатор ключа субъекта (idkey), это значение хеш функции SHA1 над открытым ключом в сертификате.
Но мы говорим, что "ключевая пара в доверенных сертификатах одинаковая". Значит, "Идентификатор ключа субъекта" будет одинаковый.
Что же их отличает, эти ключи ?
1) "Любимый УЦ" от издателя "Главный УЦ 1"
2) "Любимый УЦ" от издателя "Главный УЦ 2"
Да, у них серийные номера разные. И в разделе "идентификатор ключа центра сертификации" надо брать серийный номер ключа издателя. Далее, проверять совпадение номеров выявленного доверенного/корневого сертификата. Для пущей гарантии, можно перепроверить и строку издателя.
Вот и получается, что у нас реально будет только одна "правильная" цепочка сертификатов. Почему? |
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 14.03.2011(UTC) Сообщений: 152 Откуда: Санкт-Петербург Сказал «Спасибо»: 1 раз
Поблагодарили: 7 раз в 5 постах
|
В сертификате есть раздел "Итентификатор ключа центра сертификации" (AuthorityKeyIdentifier). Этот раздел состоит из нескольких полей. Код:
The AuthorityKeyIdentifier object.
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] IMPLICIT KeyIdentifier OPTIONAL,
authorityCertIssuer [1] IMPLICIT GeneralNames OPTIONAL,
authorityCertSerialNumber [2] IMPLICIT CertificateSerialNumber OPTIONAL }
KeyIdentifier ::= OCTET STRING
Встречный вопрос. Почему при анализе проверяется только идентификатор ключа? Ведь можно взять серийный номер. В сертификатах "CN=Любимый УЦ" идентификатор ключа одинаковый, а серийные номера разные. Отредактировано пользователем 22 июля 2015 г. 1:51:34(UTC)
| Причина: Не указана
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
