HSTS 때문에 사이트 접속이 안 될 때 원인과 해결 방법

웹사이트 주소를 HTTP로 입력했는데 자동으로 HTTPS로 바뀌거나, 인증서 오류가 발생하면서 접속 버튼조차 나타나지 않는다면 HSTS 정책이 적용되었을 가능성이 있다. HSTS는 오류를 만드는 기능이 아니라 안전하지 않은 HTTP 연결을 차단하는 보안 장치다. 따라서 브라우저 기록부터 지우기보다 인증서와 서버 설정, 사용자 환경을 나누어 원인을 확인해야 한다.

1. HSTS가 HTTPS 연결을 강제하는 보안 원리

HSTS는 HTTP Strict Transport Security의 약자로, 웹사이트가 브라우저에 “앞으로 이 도메인은 HTTPS로만 접속하라”고 알리는 보안 정책이다. 서버는 정상적인 HTTPS 응답에 다음과 같은 헤더를 포함한다.

Strict-Transport-Security: max-age=31536000

max-age는 브라우저가 HTTPS 강제 정책을 기억할 시간을 초 단위로 지정한다. 위 값은 약 1년이다. 브라우저가 이 헤더를 저장하면 사용자가 http:// 주소를 입력해도 서버에 HTTP 요청을 보내기 전에 내부적으로 HTTPS 주소로 변경한다.

이 방식은 공격자가 HTTP 연결을 가로채 가짜 사이트로 유도하는 SSL 스트리핑 공격을 줄이는 데 효과적이다. 중요한 점은 HSTS 헤더가 정상적인 HTTPS 연결을 통해 전달될 때만 인정된다는 것이다. HTTP 응답에 같은 헤더를 넣어도 브라우저는 신뢰하지 않는다.

2. 브라우저에 저장되는 정책과 사전 탑재 목록

HSTS는 크게 동적 정책과 사전 탑재 정책으로 나뉜다. 동적 정책은 사용자가 사이트에 정상적으로 접속했을 때 서버의 HSTS 헤더를 브라우저가 저장한 것이다. 지정된 max-age 기간이 지나거나 서버가 유효한 HTTPS 연결을 통해 해제 헤더를 보내기 전까지 유지된다.

사전 탑재 정책은 브라우저 자체에 포함된 HSTS Preload 목록이다. 이 목록에 등록된 도메인은 사용자가 한 번도 방문하지 않았더라도 처음부터 HTTPS 연결이 강제된다. 일반적인 사이트 데이터 삭제만으로는 사전 탑재 정책을 제거할 수 없다.

일부 Chromium 계열 브라우저에서는 내부 HSTS 관리 화면을 통해 도메인의 동적 정책을 조회하거나 삭제할 수 있다. 다만 브라우저 버전에 따라 화면이 변경되거나 제공되지 않을 수 있으며, 사전 탑재된 도메인은 사용자가 삭제할 수 없다. 동적 정책을 지우더라도 서버가 다시 HSTS 헤더를 보내면 정책은 재등록된다.

3. HSTS와 인증서 오류가 함께 나타나는 이유

HSTS가 적용되지 않은 일반 사이트에서는 인증서가 만료되거나 신뢰되지 않을 때 사용자가 경고를 무시하고 접속할 수 있는 경우가 있다. 그러나 HSTS 도메인은 인증서 오류를 우회하는 선택지를 제한한다. 이는 공격자가 위조 인증서를 이용해 사용자를 속이는 것을 막기 위한 설계다.

대표적인 원인은 다음과 같다.

• 인증서 유효기간 만료
• 접속한 도메인과 인증서 이름 불일치
• 중간 인증서가 빠진 불완전한 인증서 체인
• 새 서버나 CDN에 잘못 연결된 인증서
• 일부 서브도메인에 HTTPS가 준비되지 않은 상태
• 백신·프록시·회사 보안장비의 HTTPS 검사
• PC 날짜와 시간이 크게 잘못된 경우

따라서 “HSTS 오류”처럼 보여도 실제 원인은 인증서 또는 TLS 설정일 가능성이 높다. HSTS를 끄는 것만으로는 근본적인 인증서 문제가 해결되지 않는다.

4. 일반 사용자가 먼저 확인할 조치

먼저 오류 화면에 표시된 인증서 오류 코드와 접속 도메인을 기록한다. www가 포함된 주소와 포함되지 않은 주소, 로그인용 서브도메인은 서로 다른 인증서를 사용할 수 있으므로 정확한 주소가 중요하다.

다음 순서대로 확인한다.

1. Windows의 날짜·시간·시간대가 자동으로 설정되어 있는지 확인한다.
2. 브라우저를 완전히 종료한 뒤 다시 실행한다.
3. 다른 브라우저 또는 시크릿 창에서 같은 주소를 확인한다.
4. 휴대전화의 모바일 데이터로 접속해 다른 네트워크에서도 같은지 비교한다.
5. VPN, 프록시와 백신의 HTTPS 검사 기능을 잠시 중지해 충돌 여부를 확인한다.
6. 공용 와이파이라면 먼저 해당 네트워크의 로그인 절차를 완료한다.
7. DNS가 이전 서버 주소를 가리키는지 확인하고 필요하면 DNS 캐시를 갱신한다.

모든 기기와 네트워크에서 동일하게 실패하면 서버 인증서나 HSTS 설정 문제일 가능성이 높다. 특정 PC에서만 실패한다면 저장된 브라우저 정책, 보안 프로그램, 루트 인증서 또는 DNS 환경을 의심할 수 있다.

브라우저 내부 HSTS 기록을 삭제하는 방법은 테스트용으로만 사용하는 것이 좋다. 인증서 경고를 강제로 무시하거나 브라우저 보안 기능을 비활성화하는 실행 옵션은 개인정보와 로그인 정보가 노출될 위험이 있어 권장하지 않는다.

5. 사이트 운영자가 확인해야 할 서버 설정

사이트 운영자는 HSTS 헤더보다 먼저 HTTPS가 모든 주소에서 완전하게 작동하는지 확인해야 한다. 인증서 유효기간, 도메인 이름, 중간 인증서 체인, 443 포트와 SNI 설정을 점검한다. CDN이나 리버스 프록시를 사용한다면 외부 인증서뿐 아니라 원본 서버 인증서와 암호화 모드도 확인해야 한다.

다음으로 HTTP 주소가 올바른 HTTPS 주소로 한 번만 리디렉션되는지 살펴본다. www와 비-www 주소 사이에서 반복 이동하는 리디렉션 루프가 없어야 한다. HSTS는 리디렉션 설정을 대신하는 기능이 아니므로 서버의 HTTP→HTTPS 이동도 정상적으로 구성해야 한다.

처음 적용하는 사이트라면 짧은 max-age로 테스트한 후 점차 기간을 늘리는 것이 안전하다.

Strict-Transport-Security: max-age=300

모든 서브도메인이 HTTPS를 지원할 때만 includeSubDomains를 추가해야 한다. 이 옵션을 성급하게 적용하면 개발용, 메일용 또는 오래된 서브도메인까지 HTTPS가 강제되어 접속이 중단될 수 있다. preload 역시 충분한 사전 점검 없이 사용하면 안 된다.

6. HSTS를 해제하거나 원상 복구하는 방법

운영자가 동적 HSTS 정책을 정상적으로 해제하려면 유효한 HTTPS 응답으로 다음 헤더를 전송해야 한다.

Strict-Transport-Security: max-age=0

브라우저가 이 응답을 정상적으로 받으면 저장된 동적 정책을 만료시킨다. 단순히 서버에서 HSTS 헤더를 삭제하는 것만으로는 이미 저장된 정책이 max-age 기간 동안 남을 수 있다.

인증서가 이미 만료되었다면 브라우저가 해제 헤더를 받기 전에 연결을 차단하므로 인증서를 먼저 복구해야 한다. 사전 탑재 목록에 등록된 도메인은 서버에서 max-age=0을 보내는 것만으로 모든 브라우저에서 즉시 해제되지 않는다. 별도의 제거 절차와 브라우저 업데이트 시간이 필요하므로 장기간 HTTPS를 유지할 준비가 된 도메인만 등록해야 한다.

설정 변경 후에는 새 브라우저 프로필, 모바일 네트워크와 여러 하위 도메인에서 반복 점검한다. HTTP 접속, HTTPS 접속, 인증서 체인, 리디렉션과 HSTS 헤더를 각각 나누어 검사해야 정확한 원인을 찾을 수 있다.

장단점 분석

HSTS의 가장 큰 장점은 사용자가 실수로 HTTP 주소를 입력해도 브라우저가 HTTPS로 바꾸고 인증서 경고 우회를 제한한다는 점이다. 로그인과 결제가 있는 사이트에서는 중간자 공격을 줄이는 강력한 보호 장치가 된다.

단점은 잘못된 인증서나 서브도메인 설정도 엄격하게 차단한다는 것이다. 특히 includeSubDomains와 preload를 성급하게 적용하면 단순한 설정 실수가 전체 서비스 중단으로 이어질 수 있다. 보안 효과가 높은 만큼 운영자의 인증서 관리 책임도 커진다.

사용자 평가 및 경험

사용자 경험을 살펴보면 브라우저 캐시를 삭제해도 문제가 해결되지 않았지만 PC 시간을 수정하거나 백신의 HTTPS 검사를 중지한 뒤 정상 접속된 사례가 있다. 반면 모든 기기에서 접속되지 않아 확인해 보니 사이트 인증서 갱신이 누락되었거나 중간 인증서가 빠져 있던 경우도 많다.

운영자 측에서는 HSTS를 먼저 적용한 뒤 일부 서브도메인이 차단되는 문제가 반복된다. 짧은 유지시간으로 충분히 테스트하고 인증서 자동 갱신을 확인한 뒤 기간을 늘렸을 때 안정적으로 운영되었다는 평가가 일반적이다.

나의 견해

HSTS 오류를 해결한다며 브라우저 보안을 해제하는 방식은 잠시 화면을 열어볼 수는 있어도 문제를 숨기는 조치에 가깝다. HSTS는 고장 난 기능이 아니라 인증서 문제를 더 엄격하게 드러내는 안전장치다. 사용자라면 다른 기기와 네트워크로 문제 범위를 먼저 구분하고, 운영자라면 인증서와 모든 서브도메인의 HTTPS 준비 상태를 확인한 뒤 HSTS를 적용해야 한다. 보안 설정은 강하게 만드는 것보다 되돌릴 수 있는 단계로 검증하면서 적용하는 것이 더 중요하다.