특정 SSL 인증서에서 Window의 SSL Cipher-Suite가 제한되는 이유는 무엇입니까?

14

문제 : Windows Server 2008 R2는 서버에서 특정 인증서를 사용할 때 다음 SSL 암호화 제품군 만 지원합니다.

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

XP 암호화 API는 기본적으로 AES 암호를 지원하지 않기 때문에 XP 클라이언트가 서버에 연결하지 못합니다.
결과적으로 Internet Explorer 또는 원격 데스크톱을 사용하여 연결을 시도 할 때 서버 로그에 다음 오류가 나타납니다. (Microsoft의 CAPI를 사용하기 때문에)

Schannel 오류 36874 "TLS 1.0 연결이 원격 클라이언트 응용 프로그램에서 수신되었지만 클라이언트가 지원하는 암호화 제품군이 서버에서 지원됩니다. SSL 연결 요청이 실패했습니다."
Schannel 오류 36888 "다음 치명적인 경고가 생성되었습니다. 40. 내부 오류 상태는 1204"입니다.

windows-server-2008-r2 ssl-certificate ssl

— 게리
소스

2

개리, 당신이 당신의 자신의 질문을 해결하면 답변으로 표시하십시오.

— Bernie White

14

서버에서 사용중인 인증서가 인증서 요청 양식의 레거시 키 옵션을 사용하여 생성 된 경우 해당 인증서의 개인 키는 Microsoft의 레거시 암호화 API 프레임 워크에 저장됩니다. 웹 서버가 새로운 CNG (Cryptographic Next Generation) 프레임 워크를 사용하여 요청을 처리하려고하면 레거시 프레임 워크에 저장된 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-on-windows-vista.aspx

이것을 알아내는 데 일주일이 걸렸습니다. 이것이 누군가에게 같은 문제를 해결하기를 바랍니다.

— 게리
소스

누구나 자체 서명 된 인증서에 대해이 작업을 수행하거나 문제를 해결하는 방법을 알고 있습니까?

— MGOwen

귀하의 작업과 결과 공유에 대해 대단히 감사합니다. Microsoft 지원 사례를 열었고 Microsoft 자체가 특정 클라이언트가 연결할 수없는 이유를 알 수 없었습니다. 설명하신대로 문제가 발생했습니다. 그러나 technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx 에 따르면 레거시 키 템플릿을 사용하여 최상의 호환성을 보관하는 것이 좋습니다. 훌륭한 일!

2

이 똑같은 문제가 발생 했으며이 게시물로 많은 시간을 절약 할 수 있었으므로 모두 감사합니다!

Gary의 솔루션이 자리 잡았지만 PFX를 PEM으로 변환 한 다음 openssl을 사용하여 다시 PFX로 다시 간단히 문제를 해결할 수있었습니다. 새로운 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로 가져 오면 예상되는 모든 암호가 사용됩니다.

따라서 인증서를 다시 발급 할 필요가 없습니다.

— 엔젤 아 바드 세르 데이라
소스

이 상황과 유사한 나를 위해 일하지만, 원래의 질문에 대한 반대의 부드러운 : R2는 윈도우 서버 2012에서 AD의 FS 역할 이 필요 CERT는 요청에 대한 레거시 API를 사용하도록 - 그러나 그것은 단지 2 AES 암호를 보여줍니다 위에 표시된! OpenSSL을 사용하여 키를 내보내고 다시 패키징하고 다시 가져 오면 동일하게 해결됩니다. 다른 프로토콜이 갑자기 작동하기 시작합니다. 감사합니다, @gelilloadbad!

— ewall

0

고맙게도 내 문제가 정확히 같지는 않지만 게시물이 도움이되었습니다.

그러나 그 원인은 WINHTTP SERVER API 구성 실수였습니다. 내 IP가 변경되었고 새 서버 인증서를 "MY"시스템에 넣을 때 HttpSetServiceConfiguration에 대한 ALREADY_EXISTS 리턴 코드를 무시했습니다.

그래서 잘못된 공통 이름을 가지고 있고 새 서버 이름과 일치하지 않는 이전 서버 TLS 인증서를 사용했습니다.

HttpDeleteServiceConfiguration () 또는 명령 행 "netsh http delete sslcert 0.0.0.0:8443"을 올바르게 수행하지 않으면 다음과 같은 증상으로 심한 오류가 발생합니다.

1) TLS에서 클라이언트 Hello는 즉시 Ack 및 Reset 플래그 비트가 설정된 서버의 TCP 패킷을 만납니다. (핸드백 실패 경고라고 생각합니까?)

2) 이벤트 뷰어에 "다음 치명적 경고가 생성되었습니다. 40. 내부 오류 상태는 107입니다."

"원격 클라이언트 응용 프로그램에서 SSL 3.0 연결 요청을 받았지만 서버에서 클라이언트 응용 프로그램이 지원하는 암호화 제품군이 지원되지 않습니다. SSL 연결 요청이 실패했습니다."

암호 스위트 불일치를 추적하기 전에 실제로 사용하려는 서버 인증서를 사용 중인지 확인하십시오.

         netsh http show sslcert

그리고 해시 값을 확인하십시오!

— 앤드류 도버
소스

이 답변은 매우 명확하지 않으며 이해가되지 않습니다. "왜 특정 SSL 인증서에서 Window의 SSL Cipher-Suite가 제한됩니까?"에 직접 대답해야합니다. 그리고 Schannel 오류에 대한 설명을 따르십시오.

— Bernie White

0

이것은 KeySpec = 2-AT_SIGNATURE 문제 일 수 있습니다.

certutil -verifystore -v KeySpec 값을 확인하기위한 "인증서의 지문"입니다. 2이면 인증서를 PFX 파일로 내 보낸 다음 certutil -importpfx AT_KEYEXCHANGE를 실행하여 수정해야합니다.

— 남자 이름
소스

그것은 내 경우에도 문제였습니다. 실제로이 답변은 실제로 원인을 지적하려는 유일한 답변입니다. 그러나 대답은 AT_SIGNATURE가 비 ECDHE 암호화 제품군에 충분하지 않은 이유를 설명하는 데 도움이됩니다. 이러한 제품군의 경우 RSA가 인증 (서명)뿐만 아니라 키 교환에도 사용되기 때문입니다.

— Jakub Berezanski