SSL 관련 문제 해결(서버 인증서) - Internet Information Services

아티클
07/30/2024

적용 대상: 인터넷 정보 서비스 6.0, 인터넷 정보 서비스 7.0 이상 버전

개요

이 문서는 IIS(인터넷 정보 서비스)와 관련된 SSL(Secure Sockets Layer) 문제를 해결하는 데 도움이 됩니다. 서버 인증을 위한 서버 인증서를 다루며 클라이언트 인증서를 다루지 않습니다.

클라이언트 인증서 섹션이 "필요"로 설정된 다음 문제가 발생하는 경우 이 문서는 참조해야 하는 문서가 아닙니다. 이 문서는 SSL 서버 인증서 문제 해결을 위한 것입니다.

모든 인증서는 공개 키(암호화에 사용됨) 및 프라이빗 키(암호 해독에 사용됨)로 구성됩니다. 프라이빗 키는 서버에만 알려져 있습니다.

HTTPS의 기본 포트는 443입니다. SSL 핸드셰이크 중에 SSL 핸드셰이크 및 서버 인증 프로세스에 정통한 것으로 가정합니다.

이 문제 해결사에 사용되는 도구

다양한 시나리오를 해결하는 데 사용되는 도구는 다음과 같습니다.

SSLDiag
네트워크 모니터 3.4 또는 Wireshark

시나리오

HTTPS를 통해 웹 사이트를 탐색하는 동안 다음 오류 메시지가 표시됩니다.

메시지를 보여 주는 브라우저 페이지의 스크린샷. Internet Explorer에서 웹 페이지를 표시할 수 없습니다.

확인해야 하는 첫 번째 필수 구성 요소는 HTTP를 통해 웹 사이트에 액세스할 수 있는지 여부입니다. 그렇지 않은 경우 이 문서에서 다루지 않는 별도의 문제가 있을 수 있습니다. 이 문제 해결사를 사용하기 전에 HTTP에서 웹 사이트가 작동해야 합니다.

이제 HTTP를 통해 웹 사이트에 액세스할 수 있고 HTTPS를 찾아보려고 할 때 이전 오류 메시지가 표시된다고 가정해 보겠습니다. SSL 핸드셰이크가 실패했기 때문에 오류 메시지가 표시됩니다. 다음 몇 가지 시나리오에서 자세히 설명하는 여러 가지 이유가 있을 수 있습니다.

시나리오 1

서버 인증서에 해당하는 프라이빗 키가 있는지 확인합니다. 인증서 대화 상자의 다음 스크린샷을 참조하세요.

인증서 대화 상자의 두 스크린샷. 프라이빗 키가 없습니다. 다른 하나는 프라이빗 키가 인증서에 해당한다는 메시지를 보여 줍니다.

해결

프라이빗 키가 누락된 경우 기본적으로 프라이빗 키인 프라이빗 키가 포함된 인증서를 가져와야 합니다. PFX 파일. 다음은 프라이빗 키를 인증서와 연결하기 위해 실행하려고 시도할 수 있는 명령입니다.

C:\>certutil - repairstore my "[U+200E] 1a 1f 94 8b 21 a2 99 36 77 a8 8e b2 3f 42 8c 7e 47 e3 d1 33"

certutil 구문을 보여 주는 명령 콘솔의 스크린샷

연결에 성공하면 다음 창이 표시됩니다.

명령이 성공적으로 완료되었다는 메시지를 보여 주는 명령 콘솔의 스크린샷.

이 예제에서는 1a 1f 94 8b 21 a2 99 36 77 a8 8e b2 3f 42 8c 7e 47 e3 d1 33 인증서의 지문입니다. 지문을 가져오려면 다음을 수행합니다.

인증서를 엽니다.
세부 정보 탭을 선택합니다.
아래로 스크롤하여 지문 섹션을 찾습니다.
지문 섹션을 선택하고 아래 텍스트를 클릭합니다.
Ctrl+A를 수행하고 Ctrl+C를 선택하여 복사합니다.

세부 정보 탭을 보여 주는 인증서 대화 상자의 스크린샷. 지문 값이 강조 표시됩니다.

참고 항목

명령이 certutil 항상 성공하는 것은 아닙니다. 이 작업이 실패하면 CA(인증 기관)에서 프라이빗 키가 포함된 인증서를 가져와야 합니다.

시나리오 2

이 시나리오에서는 웹 사이트에 프라이빗 키가 설치된 서버 인증서가 있다고 간주합니다. 그러나 시나리오 1에 표시된 오류는 계속 표시됩니다. 여전히 HTTPS를 통해 웹 사이트에 액세스할 수 없습니다.

해결

서버에 SSL 진단 도구를 다운로드하여 설치합니다.
프라이빗 키가 포함된 인증서가 있고 웹 사이트에 계속 액세스할 수 없는 경우 이 도구를 실행하거나 시스템 이벤트 로그에서 SChannel 관련 경고 또는 오류를 확인합니다.

SSLDiag 도구를 실행하는 동안 다음과 같은 오류 메시지가 표시 될 수 있습니다.

이 인증서에 해당하는 프라이빗 키가 있지만 CryptAcquireCertificatePrivateKey가 실패했습니다.

또한 시스템 이벤트 로그에 다음과 같은 SChannel 경고가 표시됩니다.
```
Event Type: Error 
Event Source: Schannel 
Event Category: None 
Event ID: 36870 
Date: 2/11/2012 
Time: 12:44:55 AM 
User: N/A 
Computer: 
Description: A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x80090016. 
```
이 이벤트 또는 오류는 인증서의 프라이빗 키를 획득하는 데 문제가 있음을 나타냅니다. 따라서 다음 단계를 시도하여 경고를 해결합니다.
먼저 MachineKeys 폴더에 대한 사용 권한을 확인합니다 . 모든 프라이빗 키는 MachineKeys 폴더 내에 저장되므로 필요한 권한이 있는지 확인합니다.

사용 권한이 있고 문제가 아직 해결되지 않은 경우 인증서에 문제가 있을 수 있습니다. 손상되었을 수 있습니다. 다음 SChannel 이벤트 로그에 0x8009001a 오류 코드가 표시 될 수 있습니다.

Event Type: Error 
Event Source: Schannel 
Event Category: None 
Event ID: 36870 
Date: 2/11/2012 
Time: 12:44:55 AM 
User: N/A 
Computer: 
A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x8009001a.

웹 사이트가 테스트 인증서와 함께 작동하는지 확인합니다.
기존 인증서의 백업을 가져온 다음 자체 서명된 인증서로 바꿉다.
HTTPS를 사용하여 웹 사이트에 액세스해 보세요. 작동하는 경우 이전에 사용한 인증서가 손상되어 새 작업 인증서로 바꿔야 합니다. 경우에 따라 인증서가 아니라 발급자에서 문제가 발생할 수 있습니다. SSLDiag에서 다음 오류가 표시 될 수 있습니다.

CertVerifyCertificateChainPolicy 는 루트 CA 인증서가 신뢰할 수 있는 루트가 아닌 경우 실패 CERT_E_UNTRUSTEDROOT (0x800b0109)합니다.
이 오류를 해결하려면 서버의 내 컴퓨터 계정 아래에 있는 "신뢰할 수 있는 루트 CA" 저장소에 CA의 인증서를 추가합니다. 다음과 같은 오류가 발생할 수도 있습니다.

CertVerifyCertificateChainPolicy에서 오류 -2146762480(0x800b0110)를 반환했습니다.
오류를 해결하려면 다음 단계를 수행하여 인증서의 사용 유형을 확인합니다.
1. 인증서를 엽니다.
2. 세부 정보 탭을 선택합니다.
3. 속성 편집을 선택합니다.
4. 일반 탭에서 이 인증서에 대한 모든 용도 사용 옵션이 선택되어 있는지 확인하고 가장 중요한 것은 서버 인증이 목록에 있어야 한다는 것입니다.

시나리오 3

처음 두 시나리오는 인증서의 무결성을 확인하는 데 도움이 됩니다. 인증서에 문제가 없음을 확인한 후에는 상당한 문제가 해결됩니다. 그러나 웹 사이트가 HTTPS를 통해 여전히 액세스할 수 없는 경우 어떻게 해야 할까요? 웹 사이트의 HTTPS 바인딩을 확인하고 수신 대기 중인 포트 및 IP를 확인합니다.

해결

다음 명령을 실행하여 웹 사이트에서 사용하는 SSL 포트에서 수신 대기 중인 다른 프로세스가 없는지 확인합니다.
```
netstat -ano" or "netstat -anob
```
해당 포트에서 수신 대기하는 다른 프로세스가 있는 경우 해당 프로세스가 해당 포트를 사용하는 이유를 확인합니다.
IP 포트 조합을 변경하여 웹 사이트에 액세스할 수 있는지 확인합니다.

시나리오 4

이제 웹 사이트에 적절한 작업 인증서가 설치되어 있고 이 웹 사이트의 SSL 포트를 사용하는 다른 프로세스가 없는지 확인할 수 있습니다. 그러나 HTTPS를 통해 웹 사이트에 액세스하는 동안 "페이지를 표시할 수 없습니다" 오류가 계속 표시될 수 있습니다. 클라이언트가 SSL 협상을 연결하고 시작하면 HTTP.sys 해당 SSL 구성에서 클라이언트가 연결된 "IP:Port" 쌍을 검색합니다. HTTP.sys SSL 구성에는 SSL 협상이 성공하기 전에 인증서 해시와 인증서 저장소 이름이 포함되어야 합니다. 문제가 있을 수 있습니다.HTTP.SYS SSL Listener

HTTP.sys 등록된 인증서 해시가 NULL이거나 잘못된 GUID를 포함할 수 있습니다.

해결

다음 명령을 실행합니다.

IIS 6: "httpcfg.exe query ssl"
IIS 7/7.5: "netsh http show ssl"

참고 항목

HttpCfg 는 Windows 지원 도구의 일부이며 설치 디스크에 있습니다.

다음은 작업 및 비작업 시나리오의 샘플입니다.

작업 시나리오

구성	설정
IP	0.0.0.0:443
해시	c09b416d6b 8d615db22 64079d15638e96823d
GUID	{4dc3e181-e14b-4a21-b022-59fc669b0914}
CertStoreName	MY
CertCheckMode	0
RevocationFreshnessTime	0
UrlRetrievalTimeout	0
SslCtlIdentifier	0
SslCtlStoreName	0
플래그	0

작동하지 않는 시나리오

구성	설정
IP	0.0.0.0:443
해시
GUID	{00000000-0000-0000-0000-000000000000}
CertStoreName	MY
CertCheckMode	0
RevocationFreshnessTime	0
UrlRetrievalTimeout	0
SslCtlIdentifier	0
SslCtlStoreName	0
플래그	0

작업 시나리오에서 볼 수 있는 해시 값은 SSL 인증서의 지문입니다. 작동하지 않는 시나리오에서는 GUID가 모두 0입니다. 해시에 값이 있거나 비어 있는 것을 볼 수 있습니다. 웹 사이트에서 인증서를 제거한 다음 실행 httpcfg query ssl하더라도 웹 사이트는 여전히 GUID를 모두 0으로 나열합니다. GUID가 "{0000...............000}"으로 표시되는 경우 문제가 발생합니다.

다음 명령을 실행하여 이 항목을 제거합니다.

httpcfg delete ssl -i "IP:Port Number"

예시:

httpcfg delete ssl -i 0.0.0.0:443

IP 주소가 나열되는지 여부를 확인하려면 명령 프롬프트를 열고 다음 명령을 실행합니다.
```
IIS 6: httpcfg query iplisten
```
```
IIS 7/7.5: netsh http show iplisten
```
IP 수신 대기 목록이 비어 있으면 명령은 다음 문자열을 반환합니다.
```
HttpQueryServiceConfiguration completed with 1168.
```
명령이 IP 주소 목록을 반환하는 경우 다음 명령을 사용하여 목록에서 각 IP 주소를 제거합니다.
```
httpcfg delete iplisten -i x.x.x.x
```
참고 항목

명령을 사용하여 IIS를 다시 시작합니다 net stop http /y .

시나리오 5

이 모든 경우에 HTTPS에서 웹 사이트를 계속 탐색할 수 없는 경우 클라이언트 또는 서버에서 네트워크 추적을 캡처합니다. "SSL 또는 TLS"로 추적을 필터링하여 SSL 트래픽을 확인합니다.

다음은 작동하지 않는 시나리오의 네트워크 추적 스냅샷입니다.

추적 스냅샷을 보여 주는 필터 표시 창의 스크린샷

다음은 작업 시나리오의 네트워크 추적 스냅샷입니다.

성공한 추적의 스냅샷을 보여 주는 필터 표시 창의 스크린샷

네트워크 추적을 보는 방법의 방법입니다. 프레임 세부 정보를 확장하고 서버에서 선택한 프로토콜 및 암호화를 확인해야 합니다. 설명에서 "Server Hello"를 선택하여 해당 세부 정보를 봅니다.

작동하지 않는 시나리오에서 클라이언트는 TLS 1.1 및 TLS 1.2만 사용하도록 구성되었습니다. 그러나 웹 서버는 TLS 1.0까지 지원할 수 있는 IIS 6이므로 핸드셰이크가 실패했습니다.

레지스트리 키를 확인하여 사용하거나 사용하지 않도록 설정된 프로토콜을 확인합니다. 경로는 다음과 같습니다.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

"Enabled" DWORD는 "1"로 설정해야 합니다. 0으로 설정된 경우 프로토콜이 비활성화됩니다.

예를 들어 SSL 2.0은 기본적으로 사용하지 않도록 설정됩니다.

시나리오 6

모든 것이 확인되었으며 HTTPS를 통해 웹 사이트에 액세스하는 데 여전히 문제가 발생하는 경우 SSL 핸드셰이크가 실패하는 일부 업데이트일 가능성이 큽니다.

Microsoft는 Windows에서 SSL 구현에 대한 업데이트를 릴리스했습니다.

MS12-006: Vulnerability in SSL/TLS could allow information disclosure: January 10, 2012

이 업데이트는 Internet Explorer를 사용하거나 Internet Explorer를 사용하여 HTTPS 요청을 수행하는 애플리케이션을 사용하는 고객에게 영향을 미칠 수 있습니다.

실제로 SSL 3.0/TLS 1.0에서 정보 공개 취약성을 해결하기 위해 두 가지 변경이 있었습니다. MS12-006 업데이트는 클라이언트가 해당 동작을 요청할 때 공통 SSL 체인 블록 암호화를 사용하는 동안 추가 레코드를 보내는 schannel.dll 새 동작을 구현합니다. 다른 변경 내용은 Internet Explorer에 대한 12월 누적 업데이트(MS11-099)의 일부인 Wininet.dll 변경되었으므로 Internet Explorer에서 새 동작을 요청합니다.

문제가 있는 경우 서버에 연결하지 못하거나 불완전한 요청으로 나타날 수 있습니다. Internet Explorer 9 이상에서는 "Internet Explorer에서 웹 페이지를 표시할 수 없음" 오류를 표시할 수 있습니다. 이전 버전의 Internet Explorer는 빈 페이지를 표시할 수 있습니다.

Fiddler 는 HTTPS 요청을 캡처하고 서버에 전달할 때 추가 레코드를 사용하지 않습니다. 따라서 Fiddler를 사용하여 HTTPS 트래픽을 캡처하면 요청이 성공합니다.

레지스트리 키

MS12-006에 설명된 대로: SSL/TLS의 취약성은 정보 공개를 허용할 수 있습니다. 2012년 1월 10일, SendExtraRecord 레지스트리 값은 다음과 같습니다.

전역적으로 새 SSL 동작을 사용하지 않도록 설정합니다.
전역적으로 사용하도록 설정하거나
(기본적으로) 새 동작을 선택하는 SChannel 클라이언트에 사용하도록 설정합니다.

Internet Explorer 및 Internet Explorer 구성 요소를 사용하는 클라이언트의 경우 iexplore.exe 또는 다른 명명된 애플리케이션이 새 동작을 선택하는지 여부를 결정하는 FEATURE_SCH_SEND_AUX_RECORD_KB_2618444 FeatureControl 섹션에 레지스트리 키가 있습니다. 기본적으로 Internet Explorer에 대해 사용하도록 설정되며 다른 애플리케이션에서는 사용하지 않도록 설정됩니다.

다음을 통해 공유

개요