ERR_SSL_DECRYPT_ERROR_ALERT: Chrome 해결

문제

Chrome이 ERR_SSL_DECRYPT_ERROR_ALERT로 페이지를 거부하고, 본능적으로 — 인증서를 확인하고, 재발급하고, 만료를 보고 — 엉뚱한 길로 갑니다. 미신뢰·만료·이름 불일치로 걸린 인증서는 없습니다. 이 에러는 Chrome이 상대편에게서 치명적 decrypt_error 알림을 받았다는 뜻입니다: 핸드셰이크 어딘가에서 한쪽이 암호 검증을 했는데 실패한 것입니다. 연결이 끊기는 이유는 인증서가 무효라서가 아니라, 서명이나 Finished 메시지, 또는 재개 binder가 검증되지 않았기 때문입니다.

증상

• Chrome(또는 Chromium 계열)이 net::ERR_SSL_DECRYPT_ERROR_ALERT를 표시하며 페이지가 그려지기도 전에 실패합니다.
• 클라이언트 인증서를 요구하는 엔드포인트에서 매우 자주 나타납니다 — 회사 포털, 정부 사이트, mTLS로 보호된 API.
• 한 컴퓨터의 모든 HTTPS 사이트에 걸리기도 하는데, 이는 특정 서버가 아니라 로컬 보안 소프트웨어를 가리킵니다.
• curl이나 Firefox는 다르게 동작하기도 합니다 — 알림을 보게 되는지는 어느 쪽이 검증에 실패했는지와 경로에 무엇이 있는지에 달렸기 때문입니다.
• 인증서 자체는 어떤 외부 점검기에서도 멀쩡합니다 — 체인 유효, 미만료, 이름 정확.

이 에러가 실제로 뜻하는 것

TLS 핸드셰이크는 단순한 인증서 교환이 아니라 암호적 증명의 연속입니다. 각 측은 특정 메시지에 서명하거나 MAC을 붙여, 상대가 협상이 변조되지 않았고 각자 주장하는 개인키를 실제로 보유했음을 검증하게 합니다. 서버는 자기 키 교환에 서명하고(클라이언트 인증서가 있으면 당신의 CertificateVerify를 검증), 양측은 전체 핸드셰이크 전사의 해시에 대해 Finished 메시지를 계산하며, TLS 1.3 재개는 PSK binder를 더합니다. 이 검증 중 하나라도 실패하면, 검사하는 쪽이 치명적 decrypt_error 알림 — TLS 알림 코드 51 — 을 보내고 멈춥니다.

RFC 8446 §6.2가 TLS 1.3에서 명확히 밝힙니다: “핸드셰이크(레코드 계층이 아님) 암호 연산이 실패 — 서명을 올바르게 검증하지 못하거나 Finished 메시지 또는 PSK binder를 검증하지 못함.” RFC 5246 §7.2.2는 TLS 1.2 버전(서명 또는 Finished 검증 실패)을 줍니다. Chrome은 받은 알림을 net error ERR_SSL_DECRYPT_ERROR_ALERT(내부 -153)로 매핑합니다.

붙잡아 둘 가장 유용한 한 단어: 핸드셰이크. 이건 ERR_SSL_BAD_RECORD_MAC_ALERT가 아닙니다 — 그건 핸드셰이크가 끝난 뒤 암호화된 데이터의 레코드 계층 실패입니다. decrypt_error는 핸드셰이크 안, 암호적 증명에서 일어납니다. 그래서 해결책은 결코 “cipher suite를 바꿔라”나 “서버 인증서를 재발급하라”가 아닙니다 — 그건 핸드셰이크 협상·신뢰 문제이고, 둘 다 실패한 대상이 아닙니다. 실패한 건 한쪽이 서명한 무언가의 검증이고, 진단 질문은 누구의 서명이 왜 더 이상 검증되지 않는가입니다.

상위 3가지 원인

1. mTLS: 서버가 당신의 클라이언트 인증서 서명을 검증하지 못함. 클라이언트 인증서를 요구하는 엔드포인트에서 브라우저는 클라이언트 키로 CertificateVerify에 서명합니다. 서버가 이를 검증하지 못하면 — 키가 틀리거나 안 맞음, 클라이언트 인증서 손상, 서버가 안 받는 알고리즘, 잘못 서명한 스마트카드/PKCS#11 토큰 — decrypt_error로 중단합니다. 전형적 케이스이고, 지문은 그 사이트가 클라이언트 인증서를 요구(또는 프롬프트)한다는 점입니다. 서버가 당신의 증명을 거부하는 것이지 그 반대가 아닙니다.
2. TLS 가로채기 중간장비가 핸드셰이크를 어긋나게 함. HTTPS 검사 백신, 회사 프록시, DLP 장비가 핸드셰이크를 중간에서 재협상합니다. 서명된 메시지를 손상시키거나 전사 해시 또는 재개 binder를 잘못 처리하면, Finished나 서명 검사가 실패하고 한쪽이 decrypt_error를 냅니다. 지문은 폭 — 그 한 컴퓨터/LAN에서 무관한 여러 HTTPS 사이트에 걸립니다.
3. 서버 쪽 서명 또는 재개 버그. 서버 자체의 서명 경로가 깨진 경우: 고장난 HSM이나 암호 오프로드 카드, 버그 있는 TLS 종단, 재개 시 실패하는 잘못된 TLS 1.3 세션 티켓/PSK binder 구현. 여기 지문은 여러 클라이언트에 걸리거나, 새 연결이 아니라 재개된 연결에 특히 맞물린다는 점입니다.

DechoNet으로 진단하기

• SSL 점검은 네트워크 바깥에서 클라이언트 인증서 없이 서버에 완전한 TLS 핸드셰이크를 돌립니다. 깨끗이 완료되고 유효한 체인을 돌려주면 서버의 일반 핸드셰이크와 서명은 건강하다는 뜻입니다 — 즉 당신 실패는 클라이언트 인증서 구간(mTLS)이거나 로컬 경로의 무언가이지 오리진의 기본 TLS가 아닙니다. 이 갈림만으로 원인의 절반이 사라집니다.
• HTTP 점검은 사이트를 완전히 바깥에서 가져옵니다. 외부 fetch는 깨끗한데 내 브라우저만 알림을 던지면, 문제는 내 컴퓨터 경로 — 로컬 프록시나 TLS 가로채기 보안 제품 — 에 있습니다.

해결 체크리스트

• 레코드가 아니라 핸드셰이크 실패임을 확인하세요: decrypt_error(이 에러)는 핸드셰이크 도중, bad_record_mac은 그 이후 뜹니다. 해결책이 다릅니다 — 이 에러에 네트워크 손상을 쫓지 마세요.
• 사이트가 클라이언트 인증서를 요구하나요? 그렇다면 mTLS로 다루세요: 올바른 클라이언트 인증서를 내밀고 있는지, 키가 맞는지, 스마트카드/토큰이 제대로 서명하는지 확인하세요. 최상위 원인입니다.
• 외부 SSL 점검을 돌리세요. 외부는 깨끗한데 브라우저만 깨지면 → 문제는 클라이언트 인증서 구간이나 로컬 경로이지 서버 핵심 TLS가 아닙니다.
• 한 컴퓨터의 여러 HTTPS 사이트에서 실패하면 HTTPS 검사 백신이나 회사 프록시를 끄고 재시도하세요. 그걸로 해소되면 가로채기 계층이 핸드셰이크를 어긋나게 하는 것 — 고치거나 재설정하세요.
• 여러 클라이언트에 걸리거나 재개된 세션에서만이면 서버 쪽을 보세요: TLS 세션 재개/티켓을 끄고 테스트하고, HSM이나 하드웨어 암호 오프로드에 서명 결함이 없는지 확인하세요.
• 변경할 때마다 SSL 점검을 다시 돌려 핸드셰이크가 끝까지 완료되는지 확인하세요.

에스컬레이션 시점

• 엔드포인트가 클라이언트 인증서를 요구하고 당신 것이 올바른데도 서버가 계속 decrypt_error를 보내면, 그 서버의 mTLS 운영자에게 넘기세요: 신뢰 저장소, CA 설정, 서명 알고리즘 정책이 유효한 클라이언트 인증서를 거부하고 있을 수 있습니다.
• 외부 SSL 점검은 건강한 서버를 보이는데 한 컴퓨터가 어디서나 실패하면, 그 엔드포인트의 보안 소프트웨어 관리자에게 넘기세요 — 가로채는 프록시나 백신이 거의 확실히 핸드셰이크를 어긋나게 하고 있고, 그들만 TLS 처리를 고칠 수 있습니다.
• 실패가 여러 클라이언트나 재개된 연결에만 걸리면, TLS 종단 소유자(CDN, 로드밸런서, 장비 벤더)에게 핸드셰이크 서명 또는 세션 재개 버그로 넘기세요 — 외부 핸드셰이크 결과가 인증서와 체인은 멀쩡하다는 증거가 됩니다.