Добрый день.

Потребовалось организовать следующую схему:
Есть CA-1 и CA-2
Есть кросс-сертификат CA-1, выданный для CA-2.
Есть клиент, использующий сертификат, выданный на CA-2.
Есть сервер (Win 2008/IIS7), используемый организацией CA-1. Доверяет только сертификатам, с корнем CA-1 в цепочке доверия (в т.ч. (через кросс) доверяет сертификатам выданным на CA-2)
Хочется - организовать возможность входа на сервер по сертификату указанному выше клиенту.
Само собой одним клиентом CA-2 дело не ограничивается, могут быть и CA-3, CA-4 и т.д...

КриптоПро послыает certificate_authorities только корневые сертификаты + цепочку доверия для собственного SSL-сертификата.
У клиента не установлен сертификат CA-1, в итоге IE не предлагает выбрать имеющийся у клиента сертификат.
Я знаю, что можно убрать вообще этот список, поставив "Макс. количество сертификатов ЦС" = 0 в настройках КриптоПро, но этого делать не хочется, т.к. у клиента начинают отображаться для выбора вообще все имеющиеся у него сертификаты.

Было замечено, что если скопировать кросс-сертификат в хранишище корневых центров сертификации, то КриптоПро начинает отдавать его в списке certificate_authorities.
Собственно, это именно то поведение, которое нужно; и в этой теме хочется удостовериться, что действительно берутся все без разбора (кроме, видимо, протухших) сертификаты из хранилища доверенных ЦС, и нет ли каких-то планов изменить это?

Если такие планы есть - можно ли что-то предусмотреть, чтобы работала описанная выше схема?

Пока никто не отвечает я провел еще один эксперимент =)

Прочитав, в статье How Certificate Revocation Works что:
CryptoAPI attempts to build all possible certificate chains.

All possible certificate chains are built using locally cached certificates. If none of the certificate chains ends in a self-signed certificate, CryptoAPI then selects the best possible chain and attempt to retrieve issuer certificates specified in the authority information access extension to complete the chain. This process is repeated until a chain to a self-signed certificate is built.

After CryptoAPI builds a certificate chain up to a trusted root authority certificate, it will check for certificate revocation. The validation will continue from the root CA certificate to the entity certificate presented to the application. If there are multiple certificate chains that terminate in a trusted root authority certificate, then CryptoAPI will validate each chain until it finds a chain that is not revoked.

Я предположил, что нечто подобное может происходить и при выборе сертификата для авторизации в браузере.
Решил проделать подобный трюк на RSA сертификатах.
Сделал два корня и кросс между ними. Корень2, Корень1 и кросс для Корня2, выданный на Корне1 (Кросс1).
Серт клиента выпустил на Корне2.
На сервере поставил Корень1. Сервер (IIS7) отдает Корень1 в certificate_authorities (все остальные корни были удалены из хранилища)
На клиенте поставил Корень2, Корень1 и Кросс1.
На клиенте для клиентского сертификата строится короткая цепочка (до Корня2).
Однако в браузере клиентский сертификат предлагается для выбора (а значит цепочка до Корня1 строится через Кросс1).

Я конечно, понимаю, что вероятность построения правильной цепочки была не 100% и, возможно, мне просто повезло, но на RSA все заработало с первого раза, в отличие от ГОСТовских сертификатов.
Вопрос - действительно ли КриптоПро влияет на алгоритм выбора сертификата для клиентской авторизации?

И если ответ - да, а в случае с RSA действительно проверяются все возможные цепочки - то возможно ли поменять алгоритм в КриптоПро?

Это нужно для всех нас, т.к. с появлением Аккредитованных УЦ, на серверах, в основном, будут стоять корни Минкомсвязи и кроссы других УЦ. И для того, чтобы клиенты других УЦ могли нормально авторизоваываться на сервере - сейчас необходимо удалять с компьютера корни соответствующего УЦ, и ставя корни Минкомсявзяи и кроссы. УЦ, имеющим много клиентов непросто все это будет делать. К тому же клиент может себе случайно все снова сломать, просто поставив обратно корень своего УЦ.

При наличии в доверенных корневых - корневого УЦ - цепочка сразу строится по нему,
игнорируя наличие в промежуточных цепочки: кросс-сертификат УЦ\УЦ 1С\

Да, я все это знаю (правда, я обычно перезапускаю службу http). Однако, как я написал в первом посте, это не помогает.

Вот на сервере стоят "UC SKB Kontur (Root)" (в Trusted roots) и "UC SKB Kontur (K10)" (в Intermediate CAs):



Как видите, если сертификат стоит в промежуточных на сервере, то его нет среди издателей в поле certificate_authorities сообщения CertificateRequest.


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

Вот, давайте на конкретном примере.
Есть портал ФСФМ: https://portal.fedsfm.ru:8081/account/login.aspx



У них стоит корень УЦ 1 ИС ГУЦ. Отлично, значит, если у них стоят кроссы моего УЦ, то меня пустит к ним.
Удаляю корень своего УЦ, захожу на портал. IE предлагает мне выбрать клиентский сертификат (корень УЦ 1 ИС ГУЦ и кроссы моего УЦ у меня уже стоят), я выбираю и меня пускают (а значит, у них точно стоит наш кросс)
Ставлю обратно корень моего УЦ. Захожу на https://portal.fedsfm.ru:8081/account/login.aspx и меня тут же отбривают ошибкой "403 - запрещено. Доступ запрещен.", т.к. IE не предъявил сертификат, потому что моего УЦ нет в доверенных корневых на сервере и IE не из чего выбирать.

Вопрос простой - как мне попасть https://portal.fedsfm.ru:8081/account/login.aspx, при условии, что корневой сертификат моего УЦ стоит у меня в хранилище довереренных корневых сертификатов?

И действительно ли, выбором сертификата подходящего для клиентской аутентификации (в учетом certificate_authorities сообщения CertificateRequest) рулит конкретный криптопровайдер с конкретным алгоритмом выбора; и в стандартном виндовом криптопровадере при этом реализован перебор всех возможных цепочек доверия, или мне просто повезло в моих экспериментах, которые я описал в посте выше?

Отредактировано пользователем 15 октября 2013 г. 7:39:07(UTC)  | Причина: Не указана

Да, правильно, я ошибся. Корень у них "Головной удостоверяющий центр" и именно он стоит в Root'ах.



Они похоже, стоят на сервере(в хранилище CA), иначе бы мой сертификат не прошел проверку, и меня бы IIS не пустил.



Речь ведь о том, что на сервере стоят ГУЦ - в Root, УЦ 1 ИС ГУЦ - в CA, кросс моего УЦ - в CA? Тогда, логично, что сервер пришлет клиенту только DN ГУЦ.
И с первым и вторым вариантами в этом случае понятно - в первом случае цепочка до ГУЦ строится; во втором - нет.

А вот как раз третий вариант (когда клиент может построить 2 цепочки) и интересует. Кто является тем самым разработчиком клиентского ПО в случае с IE? Вы или MS (с его CryptoAPI)?

Напомню, что чуть выше я писал, что я эксперементировал с RSA сертификатами (с помощью openssl сгенерировал два самоподписанных сертификата, выпустил на них клиентские сертификаты и сделал кроссы).
И в этом случае пункт 3 работал (Клиент мог построить 2 цепочки: напрямую к самоподписанному, и через кросс, на сервере стоял кросс корень, на котором этот кросс был выпущен).