Windows Server 2019 및 TLS 1.2의 IIS에 문제가 있습니다.
ROOT CA를 교체했으며 신뢰할 수 있는 루트 인증서가 새로 설치되었습니다.
이제 true로 설정된 IIS일부 사이트가 있습니다 .require ssl
이제 Firefox를 사용하는 두 가지 시나리오가 있습니다.
TLS가 필요한 모든 사이트의 GET 및클라이언트에서(파이어폭스)OLD ROOT CA에서 발급한 인증서를 보냅니다.여전히 유효하며 http200/ok입니다.
하지만
만약에클라이언트에서(Firefox/Chrome 등도 동일) NEW ROOT CA에서 발급한 인증서를 보냅니다(또한 유효함). 서버로부터 403.7을 받습니다. (브라우저에서는 볼 수 없으며 인증서를 다시 요청합니다)
여기에 왜 12가 표시되는지 모르겠습니다. 응답은 즉각적이며 ON CLIENT에서는 403.7이 표시되지 않습니다. 연결 재설정이 표시됩니까?
디버그를 더 시도하는 방법은 무엇입니까?
그리고 가장 이상한 점은 다음과 같습니다.
새 루트 CA에서 발급한 동일한 인증서를 받았지만 우편 배달부로부터 200/ok를 받은 경우 이유를 알아내는 방법은 무엇입니까?
두 번째로 이상한 점은 다음과 같습니다.
다른 Windows Server 2019 서버에서 동일한 사이트를 호스팅하는 경우 require ssl두 인증서 모두 괜찮습니다.
따라서 이것은 새로운 인증서 CA/발급자와 관련된 하나의 서버 문제입니다.
----편집하다------
또 하나 이상한 점 :
동일한 가져오기를 수행하지만 서버에서 서버 IP 또는 로컬 호스트를 통해 동일한 새 인증서를 보내면 괜찮습니다.
그러면 REMOTE PC 브라우저에서 이동할 때만 이 문제가 발생하므로 몇 가지 netsh 문제에 대해 생각하고 있습니까?
더 확인해야 할 것이 무엇인지 모르겠습니다.
그리고 또한
새로운 루트 CA는 컴퓨터나 클라이언트 또는 서버 모두에 설치되지 않으며 중간에 있는 mmc>certs 컴퓨터의 신뢰할 수 있는 루트 CA에서도 볼 수 있습니다.
IIS에서는 새/이전 루트 CA에서 발급한 엔드포인트 URL과 일치하는 https 바인딩에 대한 SSL 인증서만 구성됩니다. 차이는 없습니다. 브라우저에서 연결이 재설정되고 postman에서 확인됩니다. 또한 체인을 확인할 수 있도록 서버에서 이 새 CLIENT 인증서를 가져오면 인증서 체인이 정상이고 신뢰할 수 있습니다.
IMHO 동일한 클라이언트 인증서를 사용하여 localhost에서 작동하는 경우 IIS 설정은 100% 정상이므로 다른 설정이 있어야 합니까? 어쩌면 netsh에 뭔가가 있을까요? 또한 확인했으며 잘 작동하는 두 번째 컴퓨터와 동일합니다.
더 확인해야 할 사항이나 문제가 있는 부분에 대해 조언해 주세요.
답변1
또한 사이트의 인증서를 새로운 루트 CA로 교체했습니까? 루트 CA를 변경하면 전체 인증서 체인이 변경되므로 인증서 자체에도 이를 반영해야 합니다.
테스트를 위해 새 루트 CA에서 새 인증서를 발급하고 이를 관련 사이트의 SSL 바인딩으로 가져옵니다. 또한 인증서를 변경한 후에는 브라우저 캐시를 지우고 iis를 다시 시작하십시오.
또 다른 더 복잡한 옵션은 현재 인증서를 내보내고 텍스트 파일로 열고 디코딩한 후 새 루트 CA가 있는지 확인하는 것입니다.