Почему Windows Cipher-Suite от Windows ограничен определенными сертификатами SSL?

Проблема: Windows Server 2008 R2 будет поддерживать только следующие комплекты ssl-шифров при использовании определенных сертификатов на сервере:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

Это предотвращает подключение клиентов XP к серверу, так как API шифрования XP не поддерживает никакие шифры AES по умолчанию.
В результате в журналах сервера появляются следующие ошибки при попытке подключения с помощью Internet Explorer или удаленного рабочего стола. (так как они используют Microsoft CAPI)

Schannel Error 36874 «Соединение TLS 1.0 было получено от удаленного клиентского приложения, но сервер поддерживает наборы шифров, поддерживаемых клиентом. Запрос на соединение SSL не выполнен».
Schannel Error 36888 «Было сгенерировано следующее фатальное предупреждение: 40. Состояние внутренней ошибки - 1204»

Если сертификат, используемый на сервере, был сгенерирован с использованием опции Legacy Key в форме запроса сертификата, закрытый ключ для этого сертификата будет храниться в устаревшей платформе Microsoft Cryptographic API. Когда веб-сервер пытается обработать запросы, используя свою новую платформу Cryptographic Next Generation (CNG), создается впечатление, что что-то, связанное с закрытым ключом RSA, хранящимся в устаревшей платформе, недоступно новой платформе. В результате использование наборов шифров RSA строго ограничено.

Решение.
Создайте запрос сертификата с помощью шаблона ключа CNG в мастере запроса нестандартного сертификата.

MMC | Диспетчер сертификатов локального компьютера | Папка личных сертификатов | (правый клик) | Все задачи -> Расширенные операции | Создать пользовательский запрос | «Приступить без политики регистрации» | выберите "(без шаблона) ключ CNG" | приступить к заполнению запроса сертификата в соответствии с вашими потребностями.

Проверка того, что ключ находится в нужном месте:
http://msdn.microsoft.com/en-us/library/bb204778(VS.85).aspx
http://www.jensign.com/KeyPal/index.html

Инструменты для проверки правильности комплектов шифров:
http://pentestit.com/2010/05/16/ssltls-audit-audit-web-servers-ssl-ciphers/
https://www.ssllabs.com/

Настройки набора шифров SSL:
http://support.microsoft.com/kb/245030
http://blogs.technet.com/b/steriley/archive/2007/11/06/changing-the-ssl-cipher-order -в-интернет-исследователь-7-на-окна-vista.aspx

Это заняло у нас неделю, чтобы выяснить. Надеюсь, это спасет кого-то от неприятностей.

Получил точно такой же вопрос сам, и этот пост сэкономил мне кучу времени, так что спасибо всем!

Решение Гэри на месте, но мне удалось решить эту проблему, просто преобразовав PFX в PEM, а затем снова вернувшись в PFX, используя openssl. Новый PFX импортировал сертификат в IIS точно так же, с той разницей, что я вижу отсутствующие шифры.

Вот как:

openssl pkcs12 -in mycert.pfx -out mycert.cer -nodes

Затем разделите файл cer на три: ключ, сертификат и промежуточный сертификат [s].

openssl pkcs12 -export -out mycert-new.pfx -inkey mycert.key \
-in mycert.crt -certfile mycert-intermediate.crt

Затем, если вы импортируете новый файл .pfx в IIS, он будет использовать все шифры, которые вы ожидаете увидеть.

Поэтому нет необходимости переоформлять сертификат.

Спасибо, ваш пост мне помог, хотя моя проблема была не совсем такой.

Однако причиной была ошибка конфигурации API-интерфейса WINHTTP SERVER с моей стороны. Мой IP-адрес изменился, и когда я поместил новый сертификат сервера в компьютер «MY», я проигнорировал код возврата ALREADY_EXISTS для HttpSetServiceConfiguration.

Поэтому я использовал предыдущий сертификат TLS сервера, который имел неправильное общее имя и не совпадал с моим новым именем сервера.

Если вы не выполните HttpDeleteServiceConfiguration () или командную строку «netsh http delete sslcert 0.0.0.0:8443» правильно, вы получите неприятную ошибку с этими симптомами:

1) В TLS ваш клиентский Hello сразу же встречается с пакетом TCP с вашего сервера с установленными битами флага Ack и Reset. (Предупреждение о сбое рукопожатия, я думаю?)

2) Средство просмотра событий получает сообщение «Сгенерировано следующее фатальное предупреждение: 40. Состояние внутренней ошибки - 107.»

«Запрос на соединение SSL 3.0 получен от удаленного клиентского приложения, но ни один из наборов шифров, поддерживаемых клиентским приложением, не поддерживается сервером. Запрос на соединение SSL не выполнен».

Поэтому, прежде чем вы начнете гоняться за несоответствием набора шифров, убедитесь, что вы действительно используете сертификат сервера, с которым хотите использовать:

         netsh http show sslcert

и проверьте значения хешей!

Это может быть проблема KeySpec = 2 - AT_SIGNATURE

certutil -verifystore -v Мой «Отпечаток сертификата» для проверки значения KeySpec. Если его 2, вам нужно будет экспортировать сертификат в виде файла PFX, а затем запустить certutil -importpfx AT_KEYEXCHANGE, чтобы исправить это.