ERR_BAD_SSL_CLIENT_AUTH_CERT 해결

Problem

Chrome이 사이트 로드를 거부하고 ERR_BAD_SSL_CLIENT_AUTH_CERT를 띄웁니다. 이건 서버의 인증서에 대한 흔한 “연결이 비공개로 설정되어 있지 않습니다” 경고가 아닙니다. 서버가 당신에게 인증서를 요구했고 — 이 사이트는 mutual TLS를 씁니다 — 브라우저가 내민 클라이언트 인증서가 없거나 만료됐거나 서버가 신뢰하지 않는 것이었습니다. 핸드셰이크가 클라이언트 인증 단계에서 죽은 겁니다.

Symptoms

• 특정 사이트에서만 뜹니다: 내부 관리자 패널, 은행·정부 포털, mTLS 규칙이 걸린 Cloudflare 엔드포인트, Kubernetes 대시보드, VPN·zero-trust 게이트웨이.
• “그래도 진행” 링크가 없습니다 — 서버 인증서 경고와 달리 무시하고 넘어갈 수 없습니다.
• 올바른 인증서가 설치된 동료의 기기에서는 같은 URL이 잘 됩니다.
• 반대로: 갑자기 모든 HTTPS 사이트에서 깨진다면, 사이트가 아니라 로컬 가로채기를 가리킵니다.
• 같은 호스트로의 curl이 필요하거나 부적합한 인증서에 대한 TLS alert로 실패합니다.

What This Error Actually Means

평범한 TLS 핸드셰이크에서는 서버가 인증서를 보내고 클라이언트가 검증합니다. Mutual TLS는 두 번째 다리를 더합니다. 핸드셰이크 명세(TLS 1.3, RFC 8446 §4.3.2)에 따라 서버는 CertificateRequest 메시지를 보내 클라이언트도 인증하라고 요구할 수 있습니다. 이제 당신이 인증서를 제시해야 하고, 서버는 자신이 받아들일 CA 집합에 대해 그걸 검증합니다. 브라우저가 아무것도 안 보내거나, 만료된 걸 보내거나, 서버가 모르는 CA가 서명한 걸 보내거나, 짝이 되는 개인키 없는 걸 보내면, 서버는 치명적 alert로 핸드셰이크를 중단합니다. Chrome은 그걸 ERR_BAD_SSL_CLIENT_AUTH_CERT로 표면화합니다.

어디를 봐야 할지 정하는 결정적 구분은 누구의 인증서가 실패했느냐입니다. 모든 ERR_CERT_* 오류는 서버 인증서에 대한 불평입니다. 이건 당신 인증서에 대한 불평입니다. 서버 자신의 인증서는 흠 하나 없을 수 있고, 사이트는 나머지 세상에겐 완벽히 멀쩡할 수 있고, 그런데도 이 오류가 나는 건 사이트가 당신에게 원하는 자격증명이 없거나 부적합하기 때문입니다.

그래서 우회도 없습니다. 서버 인증서 경고는 “맺을 순 있는데 맺어야 할지 모르겠다”는 뜻입니다. 클라이언트 인증 실패는 보안 채널이 아예 세워지지 않았다는 뜻 — 연결이 핸드셰이크 중간에 잘렸습니다. 폴백할 비보안 버전이 없습니다.

Top 3 Causes

1. 클라이언트 인증서가 없거나, 엉뚱한 걸 선택 - 사이트가 mTLS를 요구하는데 기기에 맞는 인증서가 없거나, 여럿 중 서버가 안 받는 걸 브라우저가 내밀었습니다. 회사 노트북엔 클라이언트 인증서가 여러 개 있곤 하고, Chrome은 태연히 엉뚱한 걸 보냅니다.

2. 클라이언트 인증서가 만료·폐기됐거나 개인키가 없음 - 클라이언트 인증서도 다른 것처럼 만료됩니다. 개인키 없이 임포트된 인증서(.pfx/.p12가 아니라 .cer)는 설치된 듯 보여도 핸드셰이크를 못 끝냅니다. 폐기된 인증서는 서버가 즉시 거부합니다.

3. 로컬 TLS 가로채기가 클라이언트 인증을 깨뜨림 - 백신 HTTPS 검사나 회사 프록시가 당신 TLS 연결을 끊고 다시 맺습니다. 클라이언트 인증서를 제대로 전달 안 하면 — 많은 놈이 안 합니다 — 모든 연결의 mTLS를 조용히 깨뜨립니다. 오류가 모든 사이트에서 한꺼번에 뜰 때의 통상적 설명입니다.

Diagnose with DechoNet

• SSL 진단으로 서버 쪽이 바깥에서 봤을 때 건강한지 확인하세요. DechoNet은 당신 기기와 무관하게 사이트 자신의 인증서와 체인을 검사하므로, 깨끗한 결과는 문제를 클라이언트 인증 단계 — 전적으로 당신 OS나 브라우저 인증서 저장소에 있는 — 로 격리합니다. SSL 진단은 정상인데 로컬에서는 여전히 ERR_BAD_SSL_CLIENT_AUTH_CERT가 난다면, 그 간극이 진단의 전부입니다: 서버 인증서는 멀쩡하니 실패는 당신이 내미는(또는 못 내미는) 인증서입니다. 클라이언트 인증 오류 뒤에 숨은 오표기된 서버 인증서 문제도 배제해 줍니다.

Resolution Checklist

• 사이트가 정말 mTLS를 요구하는지 확인하세요. 특정 인증서가 설치된 다른 기기에서 로드된다면 mutual TLS가 이유입니다 — 브라우저 수정이 아니라 그 인증서가 필요합니다.
• 이 사이트용 클라이언트 인증서가 하나라도 설치돼 있는지, 만료되지 않았는지 확인하세요. OS/브라우저 인증서 저장소를 열어 유효기간을 검증하세요.
• 인증서에 개인키가 포함됐는지 확인하세요. 키 없이 .cer/.pem에서 임포트한 인증서는 인증할 수 없습니다. 발급받은 .pfx/.p12에서 다시 임포트하세요.
• 발급 CA가 서버가 신뢰하는 것과 맞는지 검증하세요. 서버는 특정 기관의 클라이언트 인증서만 받습니다. 엉뚱한 CA의 유효한 인증서도 거부됩니다. 어느 CA를 요구하는지 사이트 운영자에게 물으세요.
• 오래되거나 중복된 클라이언트 인증서를 제거해, Chrome이 핸드셰이크 중 엉뚱한 걸 내미는 걸 멈추게 하세요.
• 오류가 모든 HTTPS 사이트에서 난다면 백신 “HTTPS/SSL 검사”와 TLS 가로채기 프록시를 끄고 재시도하세요. 그게 고치면 가로채기 놈이 클라이언트 인증을 깨고 있던 겁니다.

When to Escalate

• 방문자인데 클라이언트 인증서가 아예 없다면, 이건 브라우저에서 고칠 수 있는 게 아닙니다 — 사이트 소유자가 발급해 주거나 mTLS 요구를 풀어야 합니다. 연락하세요.
• 사이트를 운영하는데 정당한 사용자가 이걸 겪는다면, 클라이언트 인증서 신뢰 설정을 확인하세요: 어느 CA 번들이 검증하는지, 클라이언트 인증이 required인지 optional인지, 최근 변경이 허용 발급자를 좁혔는지. 이건 사용자 실수가 아니라 서버측 설정 문제입니다.