IIS 7에서 여전히 기존 SSL 인증서 제공


27

IIS7에 새 SSL 인증서를 설치하고 이전 인증서를 제거하고 새 인증서에 대한 바인딩을 설정했습니다. 따라서 https는 이제 새 인증서에만 바인딩됩니다.

IIS7 (및 Windows 2008 Server 자체)을 다시 시작하고 다음 명령을 사용하여 인증서를 확인했습니다.

netsh http show sslcert

예상대로 새 인증서 만 표시되었습니다.

certutil -store MY

이것은 또한 내가 예상했던 것처럼 이전 인증서가 아닌 새 인증서 만 보여주었습니다.

또한 mmc를 열고 인증서를 확인했는데 이전 인증서가 아닌 새 인증서 만 볼 수 있습니다.

또한 관리자 권한이있는 계정을 사용하고 있습니다.

그러나-모든 컴퓨터에서 브라우저를 열고 https 사이트로 이동하면 여전히 이전 인증서를 사용하고 있습니다. 브라우저에서 이전 인증서를 제거해도 새 인증서가 아닌 이전 인증서가 계속 전송됩니다.

내가 잘못 가고있는 곳에서 누군가 나를 도울 수 있습니까? 기존 팬텀 인증서를 어떻게 퇴장시킬 수 있습니까?

답변:


28

먼저 아마 당신과 같은 몇 가지 포인트

  • 인증서가 만료되어 인증서를 업데이트하려고했습니다.
  • 동일한 IP에 여러 도메인이 바인딩되어 있습니다. SAN 인증서가되지만 관련이 없을 수 있습니다.
  • 중앙 인증서 저장소를 사용하려고했습니다. 다시 말하지만 이것은 대부분의 대답과 관련이 없다고 생각합니다.
  • 인증서를 이미 업데이트하려고했지만 새 날짜가 표시되지 않았습니다.
  • 이전 인증서가 이미 만료 된 경우 지금 당황 할 수 있습니다. 심호흡하십시오 ...

먼저 https://www.digicert.com/help/DigiCert 도구를 다운로드하여 다운로드하는 것이 좋습니다 . 온라인에서도 사용할 수 있습니다.

웹 사이트에 입력 https://example.com하면 만료 날짜와 지문 (MS가 인증서 해시라고 함)이 표시됩니다. 실시간 조회를 수행하므로 브라우저 (또는 중간 서버)가 무언가를 캐싱하는지 여부를 걱정할 필요가 없습니다.

중앙 집중식 인증서 저장소를 사용하는 경우 .pfx 파일이 최신 버전인지 100 % 확인하고 싶은 경우 상점 디렉토리로 이동하여 다음 명령을 실행하십시오.

C:\WEBSITES\SSL> certutil -dump www.example.com.pfx

만료 날짜와 해시 / 지문이 표시됩니다. 분명히이 만료 날짜가 틀린 경우 아마도 잘못된 인증서를 파일 시스템으로 내보냈을 것이므로 먼저 수정하십시오.

CCS를 사용중인 경우이 certutil 명령이 업데이트 된 인증서의 예상 만료 날짜를 제공한다고 가정하면 계속 진행할 수 있습니다.

다음 명령을 실행하십시오 :

netsh http show sslcert > c:\temp\certlog.txt
notepad c:\temp\certlog.txt

여기에 많은 것들이있을 수 있으므로 텍스트 편집기에서 쉽게 열 수 있습니다.

이 파일에서 잘못된 해시 digicert.com(또는 Chrome에서 가져온 지문)를 검색하려고합니다.

나에게 이것은 다음을 산출했다. IP가 내 도메인 이름이 아닌 IP에 바인딩되어 있음을 알 수 있습니다. 이게 문제 야. 이것이 (확실하지 않은 이유로) 방금 업데이트 한 IIS의 바인딩 세트보다 우선하는 것 같습니다 example.com.

IP:port                      : 10.0.0.1:443
Certificate Hash             : d4a17e3b57e48c1166f18394a819edf770459ac8
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

이 바인딩의 출처를 모르고 있습니다. 기본 사이트에는 SSL 바인딩이 없지만이 서버는 몇 년 전이며 뭔가 잘못되어 붙어 있다고 생각합니다.

따라서 삭제하고 싶을 것입니다.

안전을 위해 다음 항목을 먼저 실행하여이 항목 하나만 삭제하고 싶을 것입니다.

C:\Windows\system32>netsh http show sslcert ipport=10.0.0.1:443

SSL Certificate bindings:
-------------------------

IP:port                      : 10.0.0.1:443
Certificate Hash             : d4a17e3b57e48c1166f18394a819edf770459ac8
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

이제 이것이 '잘못된'지문인지 확인했으며 다음 명령을 사용하여 삭제할 수있는 단일 레코드가 예상됩니다.

C:\Windows\system32>netsh http delete sslcert ipport=10.0.0.1:443

SSL Certificate successfully deleted

이제 Digicert로 돌아가서 명령을 다시 실행하면 예상 인증서 지문이 표시되기를 바랍니다. 확인해야 할 것이 있으면 모든 SAN 이름을 확인해야합니다.

아마 여기에 IISRESET을 설정하고 싶을 수도 있습니다.

마지막 참고 사항 : 중앙 집중식 인증서 저장소를 사용하고 있고 인증서가 여기에서 인증서를 가져오고 있는지 걱정하지 않는지 여부를 결정하려는 잘못된 동작이 표시되는 경우 이는 귀하의 잘못이 아닙니다. 때로는 새 파일을 즉시 가져 오는 것처럼 보이지만 오래된 파일은 캐시합니다. 변경을 한 후 SSL 바인딩을 열고 다시 저장하면 100 %가 아닌 재설정됩니다.

행운을 빕니다 :-)


3
당신은 사이먼의 사이먼입니다. 우리의 경우 서버가 만료 된 인증서를 '캐시'한 [::1]:443반면 IIS에서 인증서를 업데이트하면의 레코드 만 업데이트되었습니다 0.0.0.0:443. 고맙습니다!
tuespetre

1
이것은 같은 IP에서 여러 도메인의 문제를 해결했습니다. 중앙 인증 저장소를 사용하지 않습니다.
크리스 F 캐롤

1
나는 이것을 몇 번 사용해야했습니다. PLESK 웹 호스팅 관리 소프트웨어는 때때로 인증서 바인딩을 망쳐 놓고 문제가되는 바인딩을 제거하기 위해 위의 netsh 명령이 필요합니다. 어떤 버전이 영향을 받는지 확실하지 않지만 Windows Server 2016에서 현재 버전의 PLESK Onyx를 사용하고 있습니다.
BenSwayne

제 경우에는 호스트 이름과 포트였습니다. 따라서 호스트 이름으로 필터링하고 삭제하려면 "netsh http show sslcert hostnameport = www.example.com : 443"및 "netsh http delete sslcert hostnameport = www.example.com : 443"
Karthik Jayapal

14

IIS에서 사이트에 바인딩 된 인증서를 확인하십시오. 사이트를 마우스 오른쪽 버튼으로 클릭하고 바인딩 편집을 선택할 수 있습니다. 여기에 SSL 인증서와 연관된 포트 443에 대한 바인딩이 표시되어야합니다. 그것은 여전히 ​​오래된 것을 가리키고 있습니다.


확인했고 포트 443에 대한 바인딩의 인증서는 이전 인증서가 아닌 새 인증서입니다. 제안 해 주셔서 감사합니다.
joechip

1
이상하게도 이런 일이 없었습니다. 이전 인증서를 제거하지는 않지만. 여전히 기존 인증서를 어떻게 받고 있습니까? 만료되었다는 표시입니까?
Tatas

예, 브라우저에서 인증서 세부 정보 (만료 날짜 등)와 IIS7이 제공 한 이전 인증서를 확인할 수 있습니다.
joechip

1
나는 이것을 Chrome에서 보았습니다. Chrome은 이전 인증서를 캐싱하여 사용자에게 표시합니다.
TomTom

3

방금 해결했습니다. 서버는 실제로 ISA 서버 뒤에 있었으므로 ISA 서버에 새 SSL 인증서를 설치해야했습니다.


3

나는 같은 문제가 있었고 바인딩도 확인했다. IIS에는 2 개의 앱이 설치되어있었습니다. 하나는 새 인증서를 사용하고 다른 하나는 이전 인증서를 사용했습니다.

수정하려면 서버에서 인증서를 완전히 제거해야합니다 (다시 부팅 할 수 있음).

IIS 관리자-> (IIS 트리 루트)-> 서버 인증서 아이콘에서 이전 인증서를 선택하고 조치 분할 창에서 제거를 클릭하십시오.


1
마찬가지로 우리는 실제로 이전 인증서를 참조하는 추가 STOPPED 사이트를 보유하고 있으며 새 사이트를 사용하도록 해당 사이트를 업데이트하면 실제 라이브 사이트가 새 인증서를 표시하기 시작했습니다!
액션 Dan

1

IPv6 업그레이드 중에이 문제가 발생했습니다. 실제로 웹 서버 기반 서비스가 아닌 HTTP를 통해 서비스에 액세스하려고 할 경우 IIS에서 리디렉션을 제공했습니다. 실제 서비스 (음성 서버)를 IPv6으로 업데이트했지만 IPv6 주소를 포함하도록 리디렉션에 대한 바인딩을 업데이트하지 못했습니다.

이로 인해 오래된 인증서가있는 모든 사이트에 대해 글로벌 결의로 장애 조치가 실패했습니다. 캐치가 단순히 404를 모두 수행했기 때문에 실제로 사이트가 작동하지 않는 것처럼 보였으며 실제로 사이트가 잘못된 사이트에 부딪 쳤습니다.


0

누군가 여전히이 문제에 걸려 넘어 질 경우. 내 것으로 이동하여 해결되었습니다

C:\inetpub\wwwroot

그런 다음 web.config 파일을 찾아 메모장을 사용하여 열고

<httpRedirect enabled="true" destination="http://foo.company.org" />

IIS 서버의 로컬 호스트 또는 루트 사이트에 저장하고 다시 액세스하십시오.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.