Есть standalone WCF-служба с одним концом webHttpBinding. Пытаюсь запилить аутентификацию клиента по сертификату. В процессе ручкания WCF должен посылать клиенту список Сертификатных Авторитетов, которые он готов от клиента принять. Он посылает... но почему-то из 250 сертификатов имеющихся в хранилище Доверенных корневых центров сертификации (одинаковое количество для пользователя и для компьютера) он высылает по какой-то непонятной мне причине лишь 132.
При этом в хранилище имеются несколько похожих сертификатов, например (1) Certipost E-Trust Primary Normalized CA, (2) Certipost E-Trust Primary Qualified CA и (3) Certipost E-Trust TOP Root CA — все три корневые, и я не могу найти, чем они отличаются, однако, в сторону клиента WCF этот сервер высылает отчего-то лишь два из этих трех.
Ничего нагуглить не удалось по этому поводу. Остается лишь найти в исходниках WCF то место, где этот список сертификаторв в процессе handshake формируется (ума не приложу пока, где его искать). Может, кто чего знает и сможет подсказать?
Здравствуйте, fortnum, Вы писали:
F>Ничего нагуглить не удалось по этому поводу. Остается лишь найти в исходниках WCF то место, где этот список сертификаторв в процессе handshake формируется (ума не приложу пока, где его искать). Может, кто чего знает и сможет подсказать?
Оказывается, WCF ни в чем не виноват Дошел до некой штуки, называемой SSPI, а там есть функция AcceptSecurityContext с возможным параметром ASC_REQ_MUTUAL_AUTH. Вот она, похоже, этот список корневых сертификатов (в сторону клиента) дальше и формирует.
Здравствуйте, fortnum, Вы писали:
F>Дошел до некой штуки, называемой SSPI. Вот она, похоже, этот список корневых сертификатов (в сторону клиента) дальше и формирует.
Вообще тухло как-то. Есть в доках на SSPI страница с описанием процесса handshake для TLS. Так там про список сертификатов, который сервер должен клиенту передавать на стадии CertificateRequest (в случае взаимной аутентификации) не сказано вообще ничего.
1. The client sends a "Client hello" message to the server, along with the client's random value and supported cipher suites.
2. The server responds by sending a "Server hello" message to the client, along with the server's random value.
3. The server sends its certificate to the client for authentication and may request a certificate from the client. The server sends the "Server hello done" message.
4. If the server has requested a certificate from the client, the client sends it.
Что удивительно, на Википедии тоже такие подробности отсутствуют, без каких бы то ни было уточнений: "The server requests a certificate from the client, so that the connection can be mutually authenticated, using a CertificateRequest message".
К сожалению, и там упоминание только одной строкой: Request message includes: (1) The type of certificate required (typically RSA or DSS); (2) A list of acceptable CAs.
А вот каким макаром, по каким принципам он этот list of acceptable CAs должен формировать, и как именно формирует его провайдер TLS для SSPI, вот это загадка. Самое обидное, что клиенту этот список вовсе, похоже, не пофиг. Если CA клиентского сертификата в список не входит, обычно клиент свой сертификат не посылает, и соединение тут же рвется.
Здравствуйте, fortnum, Вы писали:
F>А вот каким макаром, по каким принципам он этот list of acceptable CAs должен формировать, и как именно формирует его провайдер TLS для SSPI, вот это загадка. Самое обидное, что клиенту этот список вовсе, похоже, не пофиг. Если CA клиентского сертификата в список не входит, обычно клиент свой сертификат не посылает, и соединение тут же рвется.
Вывод? Сервер не передает клиенту этот сертификат (хоть они оба помещены в хранилище доверенных корневых) в списке CertificateRequest message. И дамп это показывает!.. Почему?
Здравствуйте, fortnum, Вы писали:
F>В процессе ручкания WCF SSPI (или HTTP.SYS) должен посылать клиенту список Сертификатных Авторитетов, которые он готов от клиента принять. Он посылает... но почему-то из 250 сертификатов имеющихся в хранилище Доверенных корневых центров сертификации (одинаковое количество для пользователя и для компьютера) он высылает по какой-то непонятной мне причине лишь 132.
Попробовал на другом компе — посылает! Из 46 сертификатов, установленных в хранилище Доверенных корневых центров сертификации, посылает 36. Не знаю, что он там режет, но, главное, он там имя моего корневого сертификата высылает. На моем компе все по-прежнему. Сертификаты на другой комп ставил те же самые — ничего не менял. Там работает, у меня — нет
PS. Но на том компе так же проблема. Chrome и IE (Firefox еще не проверял) диалог выбора сертификата клиента при обращении по https показывают, сертификат я выбираю, но... ничего не происходит. Wireshark при этом показывает (видно по задержкам), что после получения ServerHello клиент (браузер) соединение с сервером тут же рвет — через [FIN]. Даже не дожидается выбора мной сертификата в окне. Зачем окно с сертификатами показывает? После выбора сертификата снова пытается коннектится к серверу через ClientHello, но номер сессии "0", т.е. вообще как бы с начала. При этом, если убрать Mutual Authentication, все работает нормально, т.е. сертификату сервера они доверяют. Да и зачем иначе показывать окно выбора сертификатов?
PPS. На моем компе окна выбора сертификатов не возникает. Браузер молча шлет свои Certificates, но с нулевой длиной списка.
F>PPS. На моем компе окна выбора сертификатов не возникает. Браузер молча шлет свои Certificates, но с нулевой длиной списка.
А не может так оказаться, что эти сертификаты добавлены под конкретным пользователем или по какой-то иной причине ты не имеешь доступа к их приватному ключу и, как следствие, не можешь использовать для цифровой подписи и дешифрирования трафика?
"Хаос всегда побеждает порядок, поскольку лучше организован." (с) Терри Пратчетт
Здравствуйте, Albeoris, Вы писали:
F>>PPS. На моем компе окна выбора сертификатов не возникает. Браузер молча шлет свои Certificates, но с нулевой длиной списка. A>А не может так оказаться, что эти сертификаты добавлены под конкретным пользователем или по какой-то иной причине ты не имеешь доступа к их приватному ключу и, как следствие, не можешь использовать для цифровой подписи и дешифрирования трафика?
Да похоже на то, что они все добавлены "для Локального компьютера", т.к. количество их в хранилищах Доверенных корневых центров (ДКЦ) локального компьютера и текущего пользователя одинаковы. Сертификаты в ДКЦ компьютера проецируются на ДКЦ пользователя, а обратно, если добавить их в ДКЦ пользователя, уже нет. Но это установлено мной экспериментальным путем, потому утверждать не возьмусь — нет документации, я не нашел.
Есть забавная странность. Если один и тот же сертификат добавить сначала в хранилище ДКЦ пользователя, а затем в хранилище ДКЦ компьютера, то в ДКЦ пользователя, где представлена, по сути, смесь из сертификатов пользователя и компьютера, отличить сертификат истинно пользователя от сертификата спроецированного из ДКЦ компьютера визуально, кажется, невозможно: если добавить тот же самый сертификат в ДКЦ компьютера, в ДКЦ пользователя их становится два Находясь в ДКЦ оснастки пользователя, отличить один от другого никак нельзя. То есть, если хочешь удалить из этих двух тот, который был добавлен под пользователя, то придется гадать 50/50
Я не спец в этих вопросах, но вроде приватные ключи у всех сертификатов в хранилище ДКЦ отсутствуют, что, как я понимаю, логично. Иначе, их бы кто-нибудь рано или поздно умудрился оттуда достать в момент осуществления подписи. Они нужны лишь для проверки подписей сертификатов следующего нижнего уровня, которые были подписаны корневым.
Что-то совсем идей нет. Нашел два примечательных сертификата: (1) Starfield Root Certificate Authority — G2 и (2) Starfield Services Root Certificate Authority — G2. Оба в Доверенных корневых центрах локального компьютера, и оба гуглятся, вроде, как оказались у меня от Microsoft. Оба абсолютно одинаковы. Ни в оснастке не могу найти ни малейшей разницы, ни другим способом (перевел их openssl x509 -text в расшифрованный из ASN.1 читабельный текстовый вид и сравнил по содержимому, строчка за строчкой, символ за символом) — отличаются только и только названием (и то, одним в нем словом).
Но один http.sys передает в списке клиенту, а другого в упор не замечает. Я их даже пробовал удалять, предварительно экспортировав. При удалении того, что http.sys клиенту в списке высылает, он из списка исчезает. При импорте возвращается обратно. К удалению и обратному импорту другого http.sys остается абсолютно равнодушен.
Похоже, причину надо искать в чем-то еще, а не в самих сертификатах или в хранилищах.
Здравствуйте, fortnum, Вы писали:
F>Похоже, причину надо искать в чем-то еще, а не в самих сертификатах или в хранилищах.
Кажется, нашел! Дело в штуке, которая называется Certificates Trust List (CTL). Пока еще не вникал, что это за зверь. Лишь здесь поиском по аргументу sslctlidentifier у netsh http нашел нижеследующее (но уже почти уверен, что проблема в этом):
One would assume that Certificate Trust List (CTL) will limit the list of Trusted Certificate Authorities (CA's) being sent to the client during the initial SSL handshake. However, IIS 6.0/7.0 using CTL's you cannot limit the list of CA's sent back to the client during the SSL/TLS handshake. That means you can't use CTL's to limit the list of certificates that Internet Explorer is showing. IE will show all the certificates irrespective of whether the issuing CA is a part of the CTL or not.
Здравствуйте, fortnum, Вы писали:
F>>Похоже, причину надо искать в чем-то еще, а не в самих сертификатах или в хранилищах. F>Кажется, нашел! Дело в штуке, которая называется Certificates Trust List (CTL). Пока еще не вникал, что это за зверь.
Только у меня комп не в домене, а netsh http show sslcert показывает, что ни один порт к CTL вообще не привязан. В оснастке так же нет соответствующих папок. По функционалу очень похоже на CTL — список CA, пригодных для аутентификации клиента, чем-то ограничен, но сути найти пока не получается.
Здравствуйте, fortnum, Вы писали:
F>Только у меня комп не в домене, а netsh http show sslcert показывает, что ни один порт к CTL вообще не привязан. В оснастке так же нет соответствующих папок. По функционалу очень похоже на CTL — список CA, пригодных для аутентификации клиента, чем-то ограничен, но сути найти пока не получается.
You may also see 403.7 due to an update to the trusted Root CA list. This creates a list that is too large based on the size limit we enforce, the result being truncation of the list when this is sent to the client during the client certificate handshake. The limit is based on data size not CA count so there is no way to say this happens at a certain count of trusted CA’s. To resolve this we need to delete some of the expired and unused/unknown trusted root certificates from the Trusted Root Certification Authorities list until it is working again.
Проверил — так и есть! 12.5 кб, если список в текстовый файл скопировать. За длинные имена сертификатов сечь по попе надо А еще UNICODE этот разбухает. Турки, вон, одно с другим совместили: не знаю, зачем мне этот сертификат и откуда он взялся, но выглядит в посылке он именно так (348 байт на 1 сертификат):
/CN=T\xC3\x9CRKTRUST Elektronik Sertifika Hizmet Sa\xC4\x9Flay\xC4\xB1c\xC4\xB1s\xC4\xB1/C=TR/L=ANKARA/O=(c) 2005 T\xC3\x9CRKTRUST Bilgi \xC4\xB0leti\xC5\x9Fimve Bili\xC5\x9Fim G\xC3\xBCvenli\xC4\x9Fi Hizmetleri A.\xC5\x9E./x500UniqueIdentifier=SEC-830101-9V9/L=Alvaro Obregon/ST=Distrito Federal/C=MX/postalCode=01030/street=Insurgentes Sur 1940
А вообще, похоже, надо CTL'ы эти осваивать. Теперь понятно, для чего они, в частности, нужны
No way, what a shame, after investing so much time in coding all that stuff, IIS just ignore it... I am disappointed.
Не совсем, правда, понял, как HTTP.sys связан с тем, что IIS 5/6/7 игнорирует CTL (там дальше по ссылке):
In IIS 5.0 Post MS04-011 update and IIS 6.0/7.0 using CTL's you cannot limit the list of CA's sent back to the client during the SSL/TLS handshake. i.e. you can't use CTL's to limit the list of certificates that Internet Explorer is showing. IE will show all the certificates irrespective of whether the issuing CA is a part of the CTL or not.
Ведь standalone WCF сервер IIS не использует. Наверное, дело как раз не в IIS, а в HTTP.sys. Но последний не входит в "пакет" установки IIS...
We know that the server sends the list of Distinguished CA names as a part of SERVER HELLO. The RFC never mandates the list of Distinguished CA Names should contain Root CAorIntermediate CA certificates.
This can lead to a problem where few systems require Root CA's while few require Intermediate CA's to be present in the list sent in the SERVER HELLO. This makes the communicating parties incompatible on certain occasions.
Both the implementations are debatable.
On one hand the list sent by the server cannot exceed a certain limit (on windows the size is 12,228 bytes). If exceeded, the auth will fail.
The list of Intermediate CA's always exceeds the list of Root CA by 2-3 folds or even higher. This is one of the reasons why some systems send the ROOT CA's in the list of Distinguished CA Names.
On the other hand, the Intermediate CA names are readily available in the client certificate provided by the user, so it makes it easier during the certificate chain validation, therefore some systems prefer this over the previous one. Both have their own merits.
One example I have personally encountered is Apple's Safari browser communicating to a site hosted on IIS 7 or higher which requires Client Certificate for authentication. Safari expects a list of Intermediate CA's in the SERVER HELLO. On the other hand, IIS sends only Root CA's in that list. As a result the authentication fails as the client is unable to provide a client certificate to the server.
Дошел до некой штуки, называемой SSPI, а там есть функция AcceptSecurityContext с возможным параметром ASC_REQ_MUTUAL_AUTH. Вот она, похоже, этот список корневых сертификатов (в сторону клиента) дальше и формирует.
Из 46 сертификатов, установленных в хранилище Доверенных корневых центров сертификации, посылает 36. Не знаю, что он там режет, но, главное, он там имя моего корневого сертификата высылает. На моем компе все по-прежнему. Сертификаты на другой комп ставил те же самые — ничего не менял. Там работает, у меня — нет 
После выбора сертификата снова пытается коннектится к серверу через ClientHello, но номер сессии "0", т.е. вообще как бы с начала. При этом, если убрать Mutual Authentication, все работает нормально, т.е. сертификату сервера они доверяют. Да и зачем иначе показывать окно выбора сертификатов?
