Windows Server 2025 / IIS 웹사이트에 HTTPS 인증서를 적용하고 갱신을 점검하는 방법

IIS에 HTTPS를 적용하려면 접속 이름에 맞는 인증서와 개인 키를 준비하고 사이트의 HTTPS 바인딩에 연결해야 합니다. 암호화 연결뿐 아니라 클라이언트의 신뢰 체인·이름 일치·만료·폐기 상태와 갱신 후 실제 바인딩까지 확인해야 합니다.

인증서의 이름·키·신뢰를 구분합니다

HTTPS는 TLS(전송 계층 보안)로 웹 통신을 보호합니다. 서버는 자신의 이름과 공개 키를 담은 인증서를 제시하며, 클라이언트는 인증서 이름·유효 기간·발급 체인 등을 검사합니다. 서버에는 해당 인증서와 짝을 이루는 개인 키가 있어야 합니다.

SAN(주체 대체 이름)은 인증서가 유효한 DNS 이름 등을 담습니다. 이름용 인증서에 IP 주소로 접속하면 일치하지 않을 수 있습니다. 내부 .test 이름은 공개 서비스의 도메인과 구분하고, 실제 서비스는 소유·관리하는 이름과 적절한 인증기관을 사용합니다. IIS HTTPS 설정 안내는 인증서와 바인딩 단계를 구분해 설명합니다.

격리 실습용 자체 서명 인증서를 만듭니다

WEB1의 LabSite와 DNS web.lab.example.test → 172.24.50.30이 준비되어 있어야 합니다. 여기서는 외부에 공개하지 않는 시험용 자체 서명 인증서를 만듭니다. 자체 서명은 클라이언트에 자동 신뢰되지 않으며 운영용 인증서 발급·검증을 대신하지 않습니다.

WEB1의 관리자 PowerShell에서 아래를 실행하고 표시된 지문을 기록합니다. 유효 기간 1개월은 실습용 선택입니다. New-SelfSignedCertificate 참조의 테스트 용도와 저장소를 확인하세요.

$labCertificate = New-SelfSignedCertificate -DnsName 'web.lab.example.test' -CertStoreLocation 'Cert:\LocalMachine\My' -FriendlyName 'LabSite HTTPS test' -NotAfter (Get-Date).AddMonths(1)
$labCertificate | Select-Object Subject,Thumbprint,NotAfter,HasPrivateKey

certlm.msc → 개인 → 인증서에서 이름·SAN·만료와 개인 키 보유를 확인합니다. 화면에 같은 이름의 인증서가 여러 개 있으면 지문으로 구분합니다. 시험을 반복해 필요 없는 인증서를 쌓지 말고 생성한 항목을 기록하세요.

8443 HTTPS 바인딩에 연결합니다

1. IIS 관리자 → WEB1 → 서버 인증서에서 새 인증서가 보이는지 확인합니다. 필요하면 새로 고칩니다.
2. LabSite → 바인딩 → 추가에서 종류 https, IP 172.24.50.30, 포트 8443을 지정합니다.
3. 호스트 이름을 web.lab.example.test로 입력하고 서버 이름 표시 필요(SNI)를 선택합니다.
4. 기록한 지문에 대응하는 LabSite HTTPS test 인증서를 선택하고 저장합니다.
5. 중복 바인딩이 없는지 확인하고 사이트 상태를 확인합니다.
6. WEB1의 방화벽에서 Domain 프로필·TCP 8443·원격 주소 172.24.50.0/24만 허용하는 Lab-IIS-HTTPS-8443 규칙을 만듭니다.

SNI(Server Name Indication)는 TLS 연결 시 클라이언트가 요청할 이름을 알려 주는 방식입니다. 같은 IP·포트에서 여러 인증서를 구분할 때 사용합니다. HTTPS 바인딩과 SNI 속성에 맞춰 이름과 인증서를 함께 지정합니다. 이 실습의 8443은 8080과 구분한 예시 포트이며 표준 HTTPS 기본 포트는 443입니다.

CLIENT1에서 신뢰와 실제 연결을 확인합니다

CLIENT1에서 https://web.lab.example.test:8443/으로 접속합니다. 자체 서명 인증서를 아직 신뢰하지 않으면 경고가 예상됩니다. 경고를 무시하는 것을 정상 검증으로 처리하지 말고, 표시된 인증서의 지문·이름·유효 기간을 먼저 확인합니다.

1. WEB1의 인증서 관리에서 이 시험 인증서만 개인 키 없이 .cer 형식으로 내보냅니다.
2. 신뢰할 수 있는 실습용 전달 경로로 CLIENT1에 공개 인증서를 옮깁니다. PFX 개인 키를 클라이언트에 배포하지 않습니다.
3. CLIENT1에서 파일의 지문을 WEB1에 기록한 값과 비교합니다.
4. 격리된 CLIENT1의 현재 사용자 → 신뢰할 수 있는 루트 인증 기관에 이 자체 서명 시험 인증서만 가져옵니다. 운영 PC나 도메인 전체 정책에는 배포하지 않습니다.
5. 브라우저를 다시 열고 같은 이름·8443 주소에서 경고 없이 연결되는지 확인합니다.

신뢰 저장소에 추가하는 것은 보안상 신뢰를 부여하는 작업입니다. 출처를 확인하지 못한 인증서를 추가하지 않습니다. 신뢰 추가 후에도 실패하면 접속 이름·SAN·시계·만료와 실제 제시된 인증서를 확인합니다. 브라우저나 조직 정책이 별도 인증서 정책을 적용하는지도 조사하세요.

Test-NetConnection -ComputerName web.lab.example.test -Port 8443

포트 연결 성공은 TLS 인증서 검증 성공과 다릅니다. 브라우저의 사이트 정보에서 실제 인증서 지문과 체인을 확인하고 시험 페이지 내용까지 확인해야 합니다.

갱신은 발급과 바인딩 확인까지 마쳐야 합니다

새 인증서를 발급받아 저장소에 넣어도 사이트가 기존 인증서를 계속 제시할 수 있습니다. 갱신 시에는 새 인증서의 키·이름·체인·만료를 점검하고 바인딩을 바꾼 뒤 외부 클라이언트에서 새 지문과 만료가 보이는지 확인하세요. 이전 인증서는 되돌리기 계획과 의존성을 확인하기 전 삭제하지 않습니다.

• 인증서와 바인딩의 담당자, 갱신 실행 방식과 실패 알림을 정합니다.
• 만료 전에 발급·승인·배포·검증을 끝낼 수 있는 시간을 확보합니다.
• 인증기관의 폐기 목록·상태 확인 경로가 클라이언트에서 도달 가능한지 확인합니다.
• 자동 갱신 도구를 쓰면 인증서 생성뿐 아니라 IIS 바인딩 갱신 결과도 감시합니다.

실습 정리는 HTTPS 바인딩과 8443 규칙을 먼저 확인한 뒤 시험 인증서 의존성을 제거하는 순서로 진행합니다. CLIENT1에 추가한 신뢰 항목도 기록한 지문으로 찾아 제거합니다. 이름이 비슷하다는 이유로 다른 루트 인증서나 서버 인증서를 지우지 않습니다. HTTP를 남길지 HTTPS로 전환할지는 검증·리디렉션·앱의 보안 요구를 함께 보고 결정하세요.