У нас есть сервер IIS 2008R2 с сайтом, настроенным для запроса клиентских сертификатов. Наш тестовый клиент не работает, и мы пытаемся выяснить, почему.
В ходе этого мы установили новый сервер Server 2008 R2 (да, я знаю, что он старый, но это то, что запускает программное обеспечение), чтобы попытаться воспроизвести или определить способы устранения неполадок.
Один из путей, который мы исследуем, - это рукопожатие TLS. Тестовое приложение написано на .NET и с соответствующими System.Diagnostics При включенной отладке в файл журнала помещается следующая запись:
Информация о System.Net: 0: [22724] SecureChannel # 48979325 - У нас есть сертификаты, предоставленные пользователем. Сервер указал 10 эмитентов. Ищем сертификаты, соответствующие любому из издателей.
Мы не можем увидеть этот список эмитентов, поэтому мы взяли OpenSSL. Выполнение следующей команды:
openssl s_client -connect win2k8r2-1.hsl10690.test:443 -state -no_ticket -servername win2k8r2-1.hsl10690.test
Результатом является вывод, в котором говорится:
[...]
-----END CERTIFICATE-----
subject=/CN=testcert.hsl10690.test
issuer=/CN=Internal Dev CA 1
---
No client certificate CA names sent
---
SSL handshake has read 1013 bytes and written 329 bytes
[...]
Итак, у нас есть несоответствие, когда стек Microsoft заявил, что сервер указал 10 эмитентов, но OpenSSL сообщает, что сервер не отправил имена CA.
В случае действующей системы журналы System.Diagnostics сообщают о 130 с лишним издателях, указанных сервером, но OpenSSL по-прежнему возвращает ноль.
Мы считаем, что проблема в том, что поставляемый нами сертификат клиента не соответствует одному из издателей (но мы подтвердили, что корень находится в хранилище доверенных сертификатов сервера, и мы проверили сертификат вне сервера). На реальном сервере мы видим это в журналах после "Сервер указал ..."сообщение:
System.Net Information: 0 : [36484] SecureChannel#33675143 - We have user-provided certificates. The server has specified 133 issuer(s). Looking for certificates that match any of the issuers.
ProcessId=20372
DateTime=2018-12-20T13:33:39.9042036Z
System.Net Information: 0 : [36484] SecureChannel#33675143 - Left with 0 client certificates to choose from.
ProcessId=20372
DateTime=2018-12-20T13:33:39.9052036Z
во время теста, где все работает, он говорит:
System.Net Information: 0 : [22724] SecureChannel#48979325 - We have user-provided certificates. The server has specified 10 issuer(s). Looking for certificates that match any of the issuers.
ProcessId=22100
DateTime=2018-12-21T13:52:23.3718249Z
System.Net Information: 0 : [22724] SecureChannel#48979325 - Selected certificate: [Version]
V3
[Subject]
Как мы можем узнать, какие сертификаты возвращены сервером, и если мы обнаружим, что эмитент отсутствует в списке, что могло помешать включению корневого каталога? Не исключаю, что мы упустили что-то очевидное, но мы этого еще не видели.
Наконец-то мы нашли ответ на этот вопрос: виноват KB931125. А статья в блоге описывает базу знаний как предназначенную только для клиентских целей, но отправленную на серверы, в результате чего список CA, отправленный IIS, будет усечен. Это на самом деле не объясняет, почему мы не могли увидеть переданный список CA с помощью OpenSSL, но в конечном итоге это привело нас к основной причине.
Статья в блоге указывает на дальнейшая статья MSDN который описывает проблему более подробно:
Эти проблемы могут возникнуть, если сервер TLS / SSL содержит много записей в списке доверенных корневых сертификатов. Сервер отправляет клиенту список доверенных центров сертификации, если выполняются следующие условия:
- Сервер использует протокол Transport Layer Security (TLS) / SSL для шифрования сетевого трафика.
- Сертификаты клиента требуются для аутентификации во время процесса подтверждения аутентификации.
Этот список доверенных центров сертификации представляет центры, от которых сервер может принимать сертификат клиента. Для аутентификации сервером клиент должен иметь сертификат, который присутствует в цепочке сертификатов корневого сертификата из списка серверов. Это связано с тем, что сертификат клиента всегда является сертификатом конечного объекта в конце цепочки. Сертификат клиента не входит в цепочку.
В настоящее время максимальный размер списка доверенных центров сертификации, поддерживаемых пакетом безопасности Schannel, составляет 16 КБ в Windows Server 2008, Windows Server 2008 R2 и Windows Server 2012.
Также регистрируется запись в журнале событий, в которой говорится (что мы пропустили, когда впервые посмотрели на это):
При запросе аутентификации клиента этот сервер отправляет клиенту список доверенных центров сертификации. Клиент использует этот список для выбора сертификата клиента, которому доверяет сервер. В настоящее время этот сервер доверяет такому количеству центров сертификации, что список слишком расширился. Таким образом, этот список был усечен. Администратор этой машины должен проверить центры сертификации, которым доверяют для аутентификации клиентов, и удалить те, которым на самом деле доверять не нужно.
В статье MSDN перечислено исправление:
Удалите следующий раздел реестра:
HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ SystemCertificates \ AuthRoot \ Certificates
Для этого выполните следующие действия:
- Запустить редактор реестра
- Найдите следующий подраздел реестра: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ SystemCertificates \ AuthRoot
- Щелкните правой кнопкой мыши и удалите ключ, который называется «Сертификаты».