호스트네임, 종속성, 소유권 목록화
방문자나 통합 시스템이 사용하는 모든 호스트네임을 나열하세요: apex(루트), www, 서브도메인, API, 자산 호스트, 포털, 지역명 등. 각 항목에 대해 TLS가 어디에서 종결되는지, 누가 변경할 수 있는지, 인증서 커버리지와 만료일, 갱신 방식, URL을 생성하는 종속성을 기록하세요. 요청된 호스트네임은 인증서의 Subject Alternative Name 목록에 포함되어야 합니다. CMS, CDN, 태그 관리자, 오브젝트 스토리지, 결제 공급자, 이메일 템플릿, 타사 임베드 등을 포함하세요; 이런 항목들은 최초 HTTPS 적용 후에도 흔히 HTTP URL을 도입합니다.
대표 www 또는 apex 호스트네임 하나를 선택하고, 다른 이름은 HTTPS를 통해 그 이름으로 직접 리디렉트하세요.
인증서와 현재 TLS 버전 배포
공용 요청에 응답하는 웹 서버, 리버스 프록시, CDN 또는 로드밸런서를 구성하세요. 인증서와 필요한 체인을 설치하고, 대상 이름에 바인딩한 뒤 호스팅 네트워크 외부에서 검증하세요. 브라우저는 체인·호스트네임·유효기간을 검사하며 공개 경고는 릴리스 차단 사유입니다. 기본값은 TLS 1.3으로 하고 호환성이 필요할 때만 TLS 1.2를 유지하세요. SSL 및 TLS 1.0·1.1은 비활성화하세요. 유지관리되는 플랫폼 권고를 따르고 복사한 레거시 암호 조합 목록에 의존하지 마세요. 서버와 TLS 라이브러리는 최신 패치 상태로 유지하세요.
개인키 접근을 제한하고 하나의 키를 공유하는 모든 시스템을 기록해 교체 시 모든 대상에 적용되도록 하세요.
HTTP를 한 번 리디렉트하고 HTTPS를 표준으로 만들기
각 HTTP URL에서 이에 대응하는 HTTPS URL로 서버 측 영구 리디렉트(일반적으로 301 또는 308)를 반환하세요. 리디렉트 체인은 피하세요. 지연과 장애 지점이 늘어납니다. 내부 링크, canonical 태그, 사이트맵, 구조화된 데이터, 소셜 태그, 이메일 및 애플리케이션이 생성하는 절대 링크에는 표준 HTTPS URL을 사용하세요. 홈페이지, 하위 페이지, 쿼리 URL, 오류 경로, 호스트네임 변형을 테스트하세요. TLS가 프록시에서 종료되는 경우, 애플리케이션이 HTTP와 HTTPS 사이에서 리디렉션 루프에 빠지지 않도록 신뢰할 수 있는 전달 프로토콜 처리를 구성하세요.
HTTP는 리디렉트 또는 인증서 검증을 완료하는 용도로만 남겨두고 별도의 공개 사이트 제공에는 사용하지 마세요.
혼합 콘텐츠를 근원에서 찾아 수정하기
혼합 콘텐츠는 HTTPS 페이지가 HTTP 또는 다른 안전하지 않은 프로토콜로 리소스를 요청하는 경우입니다. 브라우저는 일부 미디어를 업그레이드할 수 있지만 스크립트, 스타일시트, 프레임, fetch 호출, 폰트 등 위험한 요청은 차단합니다. 모든 참조를 테스트된 HTTPS URL, 자체 콘텐츠의 경우 상대 URL, 또는 승인된 대체안으로 교체하세요. 대표 템플릿을 크롤링하고 주요 사용자 여정을 진행하면서 개발자 도구를 검사하세요. CSS, JavaScript, CMS 블록, 자산 매니페스트, 태그 관리자 항목, 다운로드, 벤더 임베드를 확인하세요. 안전한 페이지는 HTTP 다운로드를 제공하지 않아야 합니다.
자동 업그레이드는 여전히 사용 불가하거나 지원되지 않는 타사 종속성을 남길 수 있으니 저장된 URL을 바로 고치세요.
갱신 자동화 및 인증서 복구 연습하기
갱신은 달력 알림이 아니라 자동화된 배포로 관리하세요. 인증서를 갱신하고 모든 서비스 계층에 배포한 후 서비스를 안전하게 다시 로드해야 합니다. 프로덕션 인증서가 만료되기 전에 동일한 검증 경로를 테스트하세요. 예를 들어 Let’s Encrypt는 90일짜리 인증서를 60일마다 갱신할 것을 권장합니다. 발급자와 플랫폼의 수명 주기를 따르세요. 인증서 이름, 발급자 계정, 챌린지 방식, 자동화, 키 위치, 대상, 비상 연락처를 인벤토리에 보관하세요. 배포 후에는 공개 엔드포인트에서 유효 기간을 확인하세요.
갱신 실패 시 DNS, 챌린지 라우팅, 권한, 발급자 접근, 속도 제한(rate limits), CDN에서 오리진으로의 배포를 점검하세요.
HTTPS 준비가 끝난 뒤에만 HSTS 사용
HTTP Strict Transport Security(줄여서 HSTS)는 해당 호스트를 다시 방문할 때 HTTPS를 사용하도록 브라우저에 지시하는 HTTPS 응답 헤더입니다. 이후 브라우저는 인증서 오류에 대해 방문자에게 우회 옵션을 제공하지 않습니다. HSTS는 프리로드 목록이 적용되지 않는 한 HTTPS 응답을 받은 뒤에 학습되므로 HTTPS로만 전송하고 HTTP 리디렉트를 유지하세요. 제한된 max-age로 시작하고 갱신 절차와 필요한 경로의 정상 동작을 확인한 뒤 기간을 늘리세요. 현재와 미래의 모든 서브도메인이 유효한 HTTPS를 제공할 수 있을 때까지 includeSubDomains는 추가하지 마세요. preload는 HSTS 명세의 일부가 아니며, 장기적 약속 여부를 별도로 검토해야 합니다.
max-age=0은 브라우저가 유효한 HTTPS 응답에 도달한 이후에만 적용됩니다. 접속할 수 없는 HTTPS 호스트는 복구할 수 없습니다.
전송 보안을 약화시키지 않고 릴리스·테스트·롤백하기
변경 전에 알려진 정상 인증서·엣지·리디렉트 구성을 캡처하세요. 롤백 승인자를 정하고, 가능하면 스테이징을 거치며, 한 번에 하나의 제어 항목 범주만 변경하세요. 변경 직후 여러 네트워크에서 공개 엔드포인트를 확인하고, 리디렉트를 따라가며, 인증서를 검사하고, 중요한 방문자 작업을 완료하세요. 대상 고객에게 중요한 브라우저와 클라이언트 그룹을 테스트하세요. 결제 또는 규제 대상 흐름은 결제 공급자와 자격 있는 보안 전문가에게 적용 요건 검토를 요청하세요. 변경으로 HTTPS가 중단되면 검증된 안전한 구성으로 복원하고, 고객 페이지를 HTTP로 제공하는 방식으로 해결하지 마세요.
다음 갱신이나 마이그레이션 진단을 쉽게 하기 위해 호스트네임, 시간, 클라이언트, 오류, 변경사항 및 결과를 캡처하세요.