[SectigoBlog]Microsoft IIS(및 기타 Windows 기반 서버)에서 SSL/TLS 인증서 체인이 구형 클라이언트(레거시 브라우저나 오래된 OS)에서 신뢰되지 않는 문제
1. 문제의 핵심 원인
일반적으로 Apache나 Nginx 같은 서버는 관리자가 직접 "중간 인증서(Intermediate Certificate)"를 지정하여 클라이언트에게 줄 체인을 고정할 수 있습니다. 하지만 Microsoft IIS는 이 권한이 서버(OS)에게 있습니다.
서버의 자동 판단: Windows 서버는 자신의 '신뢰된 루트 저장소'를 기준으로 어떤 인증서 체인을 클라이언트에게 보낼지 스스로 결정합니다.
최신 루트 선호: 서버의 저장소가 최신 상태라면, 서버는 가장 최근에 발행된(최신) 루트 인증서로 이어지는 짧은 체인을 선택합니다.
호환성 결여: 문제는 이 '최신 루트'가 오래된 핸드폰이나 업데이트가 안 된 PC(레거시 클라이언트)에는 등록되어 있지 않다는 점입니다. 원래는 '교차 인증(Cross-Certification)'을 통해 구형 클라이언트도 인식할 수 있는 긴 체인을 보내야 하는데, IIS가 이를 무시하고 최신 체인만 고집하면서 "신뢰할 수 없는 연결" 오류가 발생하게 됩니다.
2. Sectigo가 지목한 특정 사례
Sectigo의 새로운 루트 인증서인 R46 및 E46이 서버에 있을 때 주로 발생합니다.
서버는 이 최신 R46/E46 루트를 신뢰하므로 이를 사용해 체인을 만듭니다.
하지만 구형 클라이언트는 R46/E46을 모르고, 오직 예전 루트인 USERTrust만 알고 있습니다.
IIS가 USERTrust까지 이어지는 교차 체인을 보내주지 않기 때문에 구형 클라이언트에서 접속 에러가 납니다.
3. 해결 방법 (Workaround)
Sectigo와 Microsoft는 서버가 최신 루트를 체인 생성에 사용하지 못하도록 강제하는 방법을 제안합니다.
최신 루트를 '신뢰되지 않음'으로 이동:
서버의
인증서 저장소(certlm.msc)에서 문제가 되는 최신 루트(Sectigo R46, E46 등)를 '신뢰되지 않은 인증서(Disallowed Certificates)' 저장소로 이동시킵니다.이렇게 하면 IIS는 해당 루트를 "사용할 수 없는 것"으로 판단하고, 대신 구형 클라이언트와 호환되는 USERTrust 교차 체인을 찾아 클라이언트에게 보내게 됩니다.
레지스트리 수정 (.reg 파일):
Sectigo는 이 작업을 수동으로 하기 어려운 관리자들을 위해 자동으로 루트 위치를 조정해주는 레지스트리 파일(
IISFix-MoveSectigoSelfSignedRoots-Disallowed.reg)을 제공합니다.
루트 자동 업데이트 비활성화 (권장되지 않음):
Windows의 '루트 인증서 자동 업데이트' 기능을 끄는 방법도 있지만, 이는 전체 보안 업데이트에 영향을 줄 수 있어 최후의 수단으로만 고려됩니다.
4. PKI 전문가의 조언
이 현상은 "인증서 자체의 결함"이 아니라 "Windows 서버의 체인 구성 로직" 때문에 발생합니다.
영향도: 만약 귀사의 서비스가 오래된 Android 기기, 임베디드 장비, 또는 업데이트가 중단된 Windows 7 이하 사용자를 지원해야 한다면 이 조치는 필수적입니다.
주의사항: 레지스트리 수정이나 저장소 변경 후에는 반드시 IIS 서비스를 재시작하거나 서버를 리부팅하여 변경된 체인이 적용되는지 확인해야 합니다.
확인 도구:
SSL Labs같은 외부 스캔 도구로 접속하여 "Certification Paths" 섹션을 확인했을 때, 의도한 대로 교차 인증 체인(USERTrust까지 이어지는 경로)이 표시되는지 확인하십시오.
이 문제는 Sectigo뿐만 아니라 다른 글로벌 CA(Digicert 등)들이 새로운 루트로 전환할 때 IIS 환경에서 공통적으로 겪는 고질적인 문제입니다. 제공된 레지스트리 수정을 적용하는 것이 가장 빠르고 확실한 해결책입니다.
출처
https://www.sectigo.com/knowledge-base/detail/Microsoft-IIS-Certificates-not-trusted-widely
