Проблема: 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. Когда веб-сервер пытается обрабатывать запросы, используя свою новую платформу криптографического следующего поколения (CNG), оказывается, что что-то, связанное с закрытым ключом RSA, хранящимся в устаревшей структуре, недоступно для новой платформы. В результате использование наборов шифров RSA сильно ограничено.
Решение:
Сгенерируйте запрос сертификата с помощью шаблона CNG Key в мастере настраиваемого запроса сертификата.
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-in-internet-explorer-7-on-windows-vista.aspx
На это у нас ушла неделя. Я надеюсь, что это избавит кого-то от таких же проблем.
У меня точно такая же проблема, и этот пост сэкономил мне массу времени, так что спасибо всем!
Решение Гэри подходит, но мне удалось решить проблему, просто преобразовав PFX в PEM, а затем снова вернувшись в PFX с помощью openssl. Новый PFX импортировал сертификат в IIS точно так же, с той разницей, что я вижу недостающие шифры.
Вот как:
openssl pkcs12 -in mycert.pfx -out mycert.cer -nodes
Затем разделите файл cer на три: ключ, сертификат и промежуточный сертификат [ы].
openssl pkcs12 -export -out mycert-new.pfx -inkey mycert.key \
-in mycert.crt -certfile mycert-intermediate.crt
Затем, если вы импортируете новый файл .pfx в IIS, он будет использовать все шифры, которые вы ожидаете увидеть.
Так что не нужно перевыпускать сертификат.
Спасибо, ваш пост мне помог, хотя моя проблема была не совсем такой.
Однако причиной была ошибка конфигурации WINHTTP SERVER API с моей стороны. Мой IP-адрес изменился, и когда я поместил новый сертификат сервера в машину "MY", я проигнорировал код возврата ALREADY_EXISTS для HttpSetServiceConfiguration.
Поэтому я использовал предыдущий сертификат TLS сервера, который имел неправильное общее имя и не совпадал с моим новым именем сервера.
Если вы не выполните HttpDeleteServiceConfiguration () или командную строку «netsh http delete sslcert 0.0.0.0:8443» правильно, вы получите неприятную ошибку со следующими симптомами:
1) В TLS ваше Client 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, чтобы исправить это.