![공유 구성 및 중앙 집중식 인증서를 사용하는 Auzre 웹 팜에서 SSL 오류](https://rvso.com/image/1402624/%EA%B3%B5%EC%9C%A0%20%EA%B5%AC%EC%84%B1%20%EB%B0%8F%20%EC%A4%91%EC%95%99%20%EC%A7%91%EC%A4%91%EC%8B%9D%20%EC%9D%B8%EC%A6%9D%EC%84%9C%EB%A5%BC%20%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94%20Auzre%20%EC%9B%B9%20%ED%8C%9C%EC%97%90%EC%84%9C%20SSL%20%EC%98%A4%EB%A5%98.png)
[질문이 좀 길었다면 죄송합니다. 관련성이 있는 경우를 대비해 추가 정보가 많이 있습니다.]
개요
Azure에 있는 4개 VM의 부하 분산 팜에서 SSL에 문제가 있습니다. HTTPS 요청이 팜의 첫 번째 서버로 이동하면 모든 것이 정상입니다. 다른 3개 중 하나에 도착하면 호출이 실패합니다. Chrome에서는 SSL 프로토콜 오류가 발생하며 IE와 Firefox에서는 페이지를 표시할 수 없다는 메시지만 표시됩니다.
설정
Azure에 4개의 Windows Server 2012 VM이 있습니다(단순 테스트용 소규모 인스턴스). VM은 동일한 클라우드 서비스 및 가용성 집합에 있습니다. 포트 80 및 443에 로드 밸런싱된 엔드포인트가 추가되었습니다(직접 서버 반환은아니다이 항목에서는 활성화됩니다). 4개의 컴퓨터는 모두 동일한 PowerShell 스크립트를 통해 설정되었으며 두 가지 예외를 제외하고 완전히 이 방식으로 구성되었습니다.
각 서버의 IIS 구성은 DFS를 통해 그룹의 첫 번째 서버에서 각 서버로 복제되는 공유 구성을 사용하도록 설정됩니다. 이는 각 서버에 대해 수동으로 구성되었으며 정상적으로 작동합니다.
DFS는 첫 번째 서버에서 다른 서버로 webs 폴더를 복제하는 데에도 사용됩니다.
또한 배포 스크립트를 작성한 후 "새로운" 중앙 집중식 인증서 기능을 발견했기 때문에 이 기능도 4개의 서버에 수동으로 설치 및 구성되었습니다. 인증서 파일을 저장하기 위해 별도의 서버에 있는 공유를 사용하고 있습니다.
인증서 요청은 첫 번째 서버에서 생성되었으며 SSL.com을 사용하여 주소에 대한 무료 90일 SSL을 받았습니다 subdomain.domain.com
. Azure 주소를 가리키기 subdomain
위해 DNS에 CNAME 레코드를 추가했습니다 .domain.com
cloudapp
SSL 인증서를 첫 번째 서버로 가져온 다음 subdomain.domain.com.pfx
(비밀번호와 함께) 다시 내보내고 인증서 파일 공유에 복사했습니다. 4개 서버 모두에서 중앙 집중식 인증서를 확인할 때 구성의 비밀번호가 잘못되었음을 나타내는 오류 아이콘 없이 인증서가 제대로 나열됩니다.
마지막으로 서버 1의 바인딩을 변경하여 호스트 이름이 있는 https를 추가했습니다 subdomain.domain.com
.서버 이름 표시 필요그리고중앙 인증서 저장소 사용옵션이 확인되었습니다. 다른 서버를 확인하면 예상대로 전파된 바인딩이 표시됩니다.
문제
요청이 처리된 서버의 이름을 간단히 표시하는 기본 페이지를 추가했습니다. 에 액세스하는 여러 IE 창을 셸하면 http://subdomain.domain.com
다양한 서버 이름이 인쇄되어 IIS 구성 및 웹 파일이 올바르게 배포되고 있으며 Azure 부하 분산 장치도 해당 작업을 수행하고 있음을 보여줍니다. 실제로 정말 멋지다고 생각했습니다.
그러나 HTTPS를 통해 시도하면 문제가 발생합니다. 첫 번째 서버에 도달한 요청만 성공하고 나머지는 테스트하는 브라우저에 따라 "이 페이지를 표시할 수 없습니다" 또는 "SSL 프로토콜 오류" 메시지와 함께 충돌이 발생하고 화상을 입습니다. 서버 1에서는 페이지가 정상적으로 표시되고 인증서를 볼 수 있으며 인증서 오류가 없습니다.
나는 이것이 어딘가에 있는 서버의 구성 문제라고 확신하지만 도대체 그것이 무엇인지 알 수 없습니다. 과거에 IIS6과 함께 물리적 비클러스터형 Windows 2003 서버를 사용했기 때문에 제가 하고 있는 대부분의 작업은 저에게 새로운 것입니다.
더욱 당황스러운 점은 밤새 4개의 VM을 종료했고, 오늘 아침에 서비스를 다시 시작했을 때 이제 서버 2가 서버 1 외에 SSL 요청에도 분명히 응답한다는 것입니다. 하지만 그렇다고 해도 어제도 완전히 종료했고 그 후에도 여전히 서버 1만 작동했습니다.
IIS 로그 파일에는 실패한 SSL 요청이 표시되지 않으며 서버 1과 2의 포트 80에 대한 200개 묶음과 포트 443에 대한 200과 304의 혼합만 표시됩니다.
Google 검색으로 일부 실사를 수행했지만 아무 것도 밝혀지지 않았습니다. 사실, 내가 한 일과 정반대의 일이 효과가 있을 것입니다.
이 문제를 해결하는 데 도움이 되는 조언을 주시면 감사하겠습니다.
답변1
IIS의 중앙 인증서 저장소와 관련된 대부분의 문제를 해결하는 몇 가지 단계를 공유하고 싶었습니다. 중앙 집중식 인증서 저장소(CCS)는 SSL 인증서 요청을 CCS로 전달하는 데 사용하는 가짜 인증서 바인딩을 생성합니다. 이 바인딩이 없거나 동일한 IP 주소에 여러 바인딩이 있는 경우 클라이언트가 SSL 지원 웹 사이트에 연결하려고 하면 브라우저 오류가 발생합니다.
다음 설정을 고려하십시오. IP 주소 172.16.0.41
와 중앙 인증서 저장소가 활성화된 IIS 서버에는 두 개의 도메인이 포함되어 있습니다. www.adomain.com
그리고 www.bdomain.com
. PFX 인증서 패키지는 각 도메인에 대한 IIS 중앙 인증서 저장소에 설치됩니다.
일반적으로 두 가지 오류가 있습니다.
문제 1
브라우저가 웹사이트에 연결하면 잘못된 인증서가 공유됩니다. 예를 들어 www.adomain.com
처음 방문하면 올바른 인증서가 제공되지만 브라우저가 를 방문하면 www.bdomain.com
에 대한 인증서가 www.adomain.com
반환되어 브라우저에 잘못된 인증서 오류가 표시됩니다.
해결책
이 문제의 원인은 일반적으로 여러 웹사이트가 동일한 IP 주소에 바인딩되어 있고 웹사이트 중 하나 이상이 활성화되지 않았기 때문입니다.서버 이름 식별 필요. 동일한 IP 및 PORT를 공유하는 모든 웹 사이트에 대해 이 설정을 활성화하지 않으면 IIS는 어떤 인증서를 제공할지 결정할 수 없으므로첫 승리정책이 적용되는 것으로 보입니다.
이는 동일한 IIS 서버에서 호스팅되는 다른 웹사이트에 대한 후속 요청이 잘못된 인증서를 반환한다는 의미입니다.
해결 단계
각 웹사이트가 로 설정되어 있는지 확인하세요
Require Server Name Identification
. IIS 관리자에서 각 웹사이트를 클릭하고 바인딩...->HTTPS 바인딩 선택->편집 선택->확인을 선택Require Server Name Identification
하고 이Use Centralized Certificate Store
항목도 선택되어 있는지 확인하면 됩니다.서버의 바인딩을 확인하십시오. 관리자 권한 명령 상자에서 실행
netsh http show sslcert
CCS에 대한 바인딩이 있어야 합니다.
SSL Certificate bindings:
-------------------------
Central Certificate Store : 443
Certificate Hash : (null)
Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name : (null)
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
인증서 해시 와의 바인딩은 (null)
CCS 통과 바인딩이 있음을 나타냅니다. 서버의 IP 주소와 SSL 포트( 172.16.0.41:443
이 시나리오에서는)를 수신하는 다른 바인딩이 있는 경우 이를 제거해야 합니다.
바인딩을 제거하려면 를 입력합니다
netsh http delete sslcert <binding>
. 우리 시나리오에서는 이것이 가능하며netsh http delete sslcert 172.16.0.41:443
바인딩을 제거해야 합니다. CCS(null)
패스스루 바인딩을 제거하면 안 됩니다. 이 바인딩이 없으면 다음을 참조하세요.문제 2아래에.iis를 재설정
iisreset
하고 웹 서버의 각 도메인에 연결합니다. 올바른 인증서를 공유해야 합니다. 2단계를 반복하고IP:PORT
SSL 포트 및 웹 서버 IP에 대한 특정 바인딩이 없는지 확인하여 바인딩을 확인할 수도 있습니다.
문제 2
중앙 집중식 인증서 저장소가 활성화되어 있음을 확인한 후에도 인증서에 대한 가시성이 있고 모든 웹 사이트가 이를 사용하도록 바인딩되어 있지만 브라우저가 웹 사이트에 연결하면 오류가 발생 Page Cannot be displayed
합니다 invalid encryption
. 원하는 웹사이트가 표시되지 않습니다.
IE(Edge)에서는 일반적으로 브라우저에서 적절한 암호화 유형이 활성화되어 있는지 확인하라는 제안으로 나타납니다.
iisreset
서버를 재부팅하거나 재부팅해도 문제가 해결되지 않습니다 .
해결책
이는 CCS 통과 바인딩 생성 시 버그인 것으로 보입니다. 인증서에 대한 수신 요청이 자동으로 삭제되도록 CCS 기능이 활성화되면 웹 서버에서 생성되지 않습니다.
해결 단계
먼저 중앙 집중식 인증서 저장소가 활성화되어 있는지 확인하고 해당 경로에 있는 모든 인증서를 볼 수 있습니다. 이렇게 하려면
IISManager
서버 노드->중앙 집중식 인증서(관리 섹션 아래)->기능 설정 편집...을 선택하고 구성 및 활성화되었는지 확인하세요.공통 인증서를 사용하는 모든 웹사이트가 CCS에 바인딩되어 있는지 확인하세요. IIS 관리자에서 각 웹사이트를 클릭하고 바인딩...->HTTPS 바인딩 선택->편집 선택->확인을 선택
Require Server Name Identification
하고 이Use Centralized Certificate Store
항목도 선택되어 있는지 확인하면 됩니다.CCS 바인딩이 생성되었는지 확인하세요. 달리다
netsh http show sslcert
. 결과가 비어 있거나(null)
통과 인증서가 없는 경우(CCS 바인딩 모양은 문제 1의 2단계 참조) CCS 바인딩이 활성화되지 않은 것입니다.SSL Certificate bindings: -------------------------
IIS 관리자에서 CCS를 사용하는 웹 사이트 하나를 선택하고 바인딩...->HTTPS 바인딩 선택->편집 선택->을 클릭하고선택 취소
Use Centralized Certificate Store
그리고선택 취소Require Server Name Identification
.
드롭다운 에서 SSL certificate
서버 기본 WMSVC
인증서를 선택하고 을 클릭합니다 OK
. 창문을 열어 두세요 Site Bindings
.
관리자 권한 명령 프롬프트로 다시 전환하고 를 실행합니다
netsh http show sslcert
. 그러면 다음과 같은 바인딩이 생성됩니다.SSL Certificate bindings: ------------------------- IP:port : 172.16.0.41:443 Certificate Hash : 64498c920fecb31b8f7ccbdac2fa2baa2ec4f19a Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914} Certificate Store Name : My Verify Client Certificate Revocation : Enabled Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check : Enabled Revocation Freshness Time : 0 URL Retrieval Timeout : 0 Ctl Identifier : (null) Ctl Store Name : (null) DS Mapper Usage : Disabled Negotiate Client Certificate : Disabled
창 으로 돌아가서
Site Bindings
4단계의 변경 사항을 되돌립니다. 및를 활성화Require Server Name Indication
하고Use Centralized Certificate Store
을 클릭합니다OK
.관리자 권한 명령 프롬프트로 다시 전환하고
netsh http show sslcert
다시 한 번 실행하면 - 신이 당신에게 미소를 지으면 - 중앙 집중식 인증서 저장소 바인딩이 존재하여 현재 바인딩을 대체해야 합니다.SSL Certificate bindings: ------------------------- Central Certificate Store : 443 Certificate Hash : (null) Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914} Certificate Store Name : (null) Verify Client Certificate Revocation : Enabled Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check : Enabled Revocation Freshness Time : 0 URL Retrieval Timeout : 0 Ctl Identifier : (null) Ctl Store Name : (null) DS Mapper Usage : Disabled Negotiate Client Certificate : Disabled
(null)
위의 인증서 바인딩이 해당 값 과 함께 표시되면 제대로 Certificate Hash
작동한 것이며 이제 CSS 통과가 활성화되어야 합니다.
- 브라우저를 실행하고 보안 소켓(HTTPS)을 통해 서버의 도메인에 연결을 시도하면 모든 것이 정상일 것입니다.
중요 사항
웹팜의 각 웹 서버에서 이 프로세스를 반복해야 합니다. 프로세스를 자동화하고 확인하려면 PowerShell을 통해 수행할 수 있어야 합니다.
패스스루 바인딩이 생성되면 무기한 유지됩니다(노드에서 중앙 집중식 인증서 지원을 비활성화하지 않는 한).
여담으로; 이 링크에는 CCS가 기술 수준에서 작동하는 방식에 대한 정보가 포함되어 있어 읽어 볼 가치가 있습니다.https://blogs.msdn.microsoft.com/kaushal/2012/10/11/central-certificate-store-ccs-with-iis-8-windows-server-2012/
도움이 되었기를 바랍니다.