핸드셰이크도 성공하고 인증서도 유효한데 왜 Chrome이 연결을 거부하나요?

HTTP/2가 TLS 자체보다 더 엄격한 하한을 두기 때문입니다. 핸드셰이크는 끝났고 인증서도 통과했으니 그 부분은 문제없고, 같은 연결로 HTTP/1.1은 멀쩡히 오갑니다. 하지만 TLS 위에 얹힌 HTTP/2는 추가 요건을 겁니다(RFC 9113 §9.2): 최소 TLS 1.2, 그리고 Appendix A 블록리스트에 *없는* 암호 스위트. Chrome은 핸드셰이크 중 ALPN으로 'h2'를 협상한 뒤, 실제로 맺어진 연결이 그 요건을 충족하는지 확인합니다. 충족하지 못하면 HTTP/2가 금지하는 연결로 HTTP/2를 말하느니 ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY로 연결을 끊어버립니다.

같은 사이트가 다른 브라우저나 HTTP/1.1에서는 잘 열리는 이유는요?

제약이 TLS가 아니라 HTTP/2에만 걸리기 때문입니다. HTTP/1.1로 폴백한 클라이언트에는 암호 블록리스트가 없어요 — RFC 9113 Appendix A는 프로토콜이 h2일 때만 적용되니까요 — 그래서 Chrome이 HTTP/2에 대해 거부하는 바로 그 약한 암호가 HTTP/1.1 요청에는 아무 문제 없이 통과합니다. 어떤 클라이언트·설정은 조용히 HTTP/1.1로 내려가 페이지가 열리고, Chrome은 h2를 선호한 뒤 규칙을 강제하죠. 그래서 'curl에선 되는데'나 '폰에선 되는데'는 여기선 헛다리입니다 — 그 요청들은 HTTP/2 암호 규칙의 심사를 받지 않았으니까요.

한 사이트가 아니라 회사에서 모든 HTTPS 사이트에 뜹니다. 무슨 뜻인가요?

그 패턴은 특정 서버가 아니라 당신의 네트워크를 가리킵니다. TLS를 검사하는 중간 장비 — SSL 복호화를 하는 회사 방화벽이나 HTTPS를 검사하는 백신 — 가 중간에 앉아 트래픽을 복호화한 뒤 자기 TLS 설정으로 브라우저에 재암호화합니다. 그게 HTTP/2가 블록리스트에 올린 암호로 재암호화하면 그 뒤의 모든 h2 사이트가 똑같이 실패합니다. Palo Alto의 SSL 복호화가 문서화된 방아쇠입니다. 한 사이트만 실패하면 오리진의 암호 순서 문제, *전부* 실패하면 당신과 서버 사이의 장비 문제입니다.

조회수: 17

ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY 해결

ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY는 TLS가 HTTP/2 기준에 못 미친다는 뜻입니다. TLS 버전·암호 스위트·검사 장비를 점검하세요. 무료 SSL 진단으로 바로 확인.

내 도메인에 이 문제가 있는지 지금 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.

문제

Chrome(또는 Chromium 계열 브라우저)이 사이트를 ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY로 로드하지 못합니다. 헷갈리는 건 밑단이 멀쩡해 보인다는 점입니다: 자물쇠의 암호화는 완료됐고, 인증서는 유효하며, 브라우저를 HTTP/1.1로 강제로 내리면 페이지가 대개 잘 열립니다. 이 오류는 나쁜 인증서나 도달 불가 서버의 문제가 아닙니다. HTTP/2가 너무 약하다고 판단한 TLS 연결 위에서 실행되기를 거부하는 것입니다.

증상

Chrome/Edge가 net::ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY를 냅니다 — 개별 에셋보다 페이지 전체에 뜨는 경우가 많습니다.
인증서는 유효하고 만료되지 않았습니다 — ERR_CERT_* 오류도, 만료 경고도 없습니다.
HTTP/1.1로 귀결되는 브라우저·클라이언트에서, 그리고 깨끗한 네트워크의 curl에서 자주 잘 됩니다.
한 사이트가 아니라 모든 HTTPS 사이트에 뜨면, 로컬 문제라는 강한 신호입니다.

이 오류의 진짜 의미

TLS 위의 HTTP/2(h2 프로토콜)는 평범한 HTTPS보다 연결에 더 까다롭습니다. RFC 9113 §9.2가 하한을 정합니다: h2 연결은 TLS 1.2 이상을 써야 하고, §9.2.2는 긴 암호 스위트 목록 — Appendix A의 블록리스트 — 을 금지합니다. 취지는 순방향 비밀성(forward secrecy)입니다: HTTP/2는 사실상 임시 키 교환(ECDHE 또는 DHE)에 AEAD 암호를 짝지을 것을 요구합니다. 정적 RSA 키 교환은 AES-GCM을 실어 나르더라도 제외라서, TLS_RSA_WITH_AES_128_GCM_SHA256과 TLS_RSA_WITH_AES_256_GCM_SHA384는 사람들이 강하다고 여기는 “AES-256” 암호임에도 둘 다 블록리스트에 있습니다.

이걸 걸리게 하는 순서는 이렇습니다. TLS 핸드셰이크 중 서버와 브라우저가 ALPN으로 h2에 합의합니다 — 서버가 “네, HTTP/2 합니다”라고 한 거죠. 동시에 TLS 버전과 암호 스위트에도 합의합니다. 그 조합이 HTTP/2의 하한을 어기면 — TLS 1.2 미만이거나 블록리스트 암호이면 — 명세는 준수 클라이언트가 INADEQUATE_SECURITY 오류(코드 0xc)를 내고 거부해야 한다고 합니다. Chrome은 그걸 ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY로 표출합니다.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH와의 구분이 진단의 전부입니다. 그 오류는 양쪽이 쓸 수 있는 버전·암호를 하나도 공유하지 못해 핸드셰이크가 아예 실패했다는 뜻입니다. 이 오류는 핸드셰이크가 성공했다 — 공통 암호를 찾았다 — 는 뜻이고, 다만 그게 HTTP/2가 허용하지 않는 암호였을 뿐입니다. 연결 자체는 멀쩡하고, 그 위에서 도는 프로토콜이 거부하는 겁니다. 그러니 당신은 깨진 TLS 스택을 찾는 게 아닙니다. 선택된, 약하지만-작동하는 암호를 찾고, 그걸 서버가 골랐는지 중간의 무언가가 강제했는지를 가려내는 겁니다.

가장 흔한 원인 3가지

서버가 HTTP/2를 광고하면서도 블록리스트 암호를 선호 - 전형적인 오리진 쪽 원인입니다. 서버가 ALPN으로 h2를 제시하면서 암호 우선순위 목록의 맨 위에 정적 RSA 스위트(예: TLS_RSA_WITH_AES_256_GCM_SHA384)를 둡니다. 브라우저는 서버의 1순위를 협상해 블록리스트 암호를 받고 포기합니다. 수정은 암호 순서입니다: ECDHE/DHE AEAD 스위트를 앞으로 올리고 RSA 키 교환 스위트를 뒤로 내리거나 제거하세요. Microsoft의 지침도 HTTP/2 블록리스트 암호는 순서의 맨 아래에 있어야 하며 그렇지 않으면 HTTP/2 협상이 실패한다고 명시합니다.
TLS를 검사하는 중간 장비가 약한 암호로 재암호화 - SSL 복호화를 하는 회사 방화벽이나 “HTTPS 검사” 백신이 연결을 가로채 자기 암호 설정으로 브라우저에 새 TLS 세션을 건네는데, 그 설정이 실제 오리진보다 오래된 경우가 많습니다. 블록리스트 암호를 고르면 모든 h2 사이트가 똑같이 깨집니다. 지문은 광범위함입니다: 한 사이트가 아니라 전부죠. Palo Alto의 SSL 복호화에 정확히 이런 보고가 문서화돼 있습니다. 수정은 장비 쪽(복호화 프로파일 업데이트)이거나, 테스트로는 그 장비가 없는 네트워크에서 확인하는 것입니다.
TLS 1.2 미만으로 협상하는 레거시 TLS 종단 장비 - HTTP/2를 광고하면서도 여전히 TLS 1.1(또는 1.0)로 연결을 맺는 낡은 로드밸런서·리버스 프록시·SSL 오프로드 장비는 버전 하한을 직접 위반합니다. TLS 1.2가 거의 보편화된 지금은 드물지만, 임베디드 장비와 얼어붙은 OpenSSL 빌드는 아직 그럽니다. 수정은 종단 장비의 최소 TLS 버전을 1.2로 올리고 최신 스위트를 제시하는지 확인하는 것입니다.

DechoNet으로 진단하기

SSL 진단은 서버가 당신 네트워크 바깥에서 실제로 제시하는 TLS 버전과 암호 스위트를 보여줍니다. 정적 RSA나 그 밖의 블록리스트 스위트가 선호되거나 최고 TLS 버전이 1.2 미만이면 그게 원인이고 — 문제가 브라우저가 아니라 오리진임을 증명합니다.
HTTP 진단은 당신 기기 바깥에서 사이트를 완전히 가져옵니다. 브라우저는 실패하는데 여기서 깨끗이 가져오면 서버가 아니라 로컬 TLS 검사 장비를 지목하는 것입니다.
포트 진단은 443 도달 가능성을 확인해, 진짜 연결 장애와 프로토콜 수준의 거부를 갈라냅니다.

해결 체크리스트

오리진이냐 네트워크냐부터 가르세요. 외부 SSL 진단과 외부 HTTP 진단을 돌리세요. 외부에선 깨끗한데 당신 브라우저에서만 깨지면 로컬 TLS 검사 방화벽·백신을 의심하세요.
제시된 암호를 읽으세요. TLS_RSA_WITH_*(정적 RSA 키 교환) 스위트가 맨 위에 있거나 최고 TLS 버전이 1.1/1.0이면 그게 위반입니다.
오리진에서 암호 우선순위를 재정렬해 ECDHE/DHE AEAD 스위트(HTTP/2가 지원을 요구하는 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 등)를 앞으로 올리고 정적 RSA 스위트를 내리거나 제거하세요. 최소 TLS 버전을 1.2로 올리세요.
중간 장비 문제라면 SSL 복호화·HTTPS 검사 프로파일이 HTTP/2 호환 암호를 제시하도록 업데이트·재설정하거나 해당 사이트를 예외 처리하세요.
SSL 진단을 다시 돌려 선호 스위트가 TLS 1.2+의 임시-AEAD 암호인지 확인한 뒤 Chrome에서 새로고침하세요.

에스컬레이션 시점

외부 SSL 진단이 오리진이 블록리스트 암호를 선호한다고 하면, 웹 서버·로드밸런서·CDN의 TLS 설정을 담당하는 쪽에 넘기세요 — 애플리케이션 버그가 아니라 암호 순서 수정입니다.
외부 HTTP·SSL 진단은 깨끗한데 당신 브라우저가 여러 사이트에서 실패하면, 네트워크의 TLS 검사를 운영하는 쪽에 올리세요: 그 재암호화가 HTTP/2가 거부하는 암호를 협상하고 있습니다.
종단 장비가 TLS 1.2 미만으로 연결을 맺고 있다면, 이 오류와 무관하게 긴급 설정 항목으로 다루세요 — HTTP/2 클라이언트만이 아니라 모두에게 폐기된 프로토콜 버전을 서빙하고 있는 것입니다.