SSL_ERROR_BAD_CERT_ALERT는 웹사이트 인증서 문제인가요?

아닙니다 — 그리고 이걸 바로잡는 게 제일 중요합니다. 다들 여기서 엉뚱한 길로 빠지거든요. Firefox의 문구는 'SSL peer cannot verify your certificate'인데, 핵심 단어는 *your(당신의)*입니다. 이 오류는 서버 인증서에 관한 게 아닙니다. *당신이* 제시한 인증서에 관한 겁니다. 상호 TLS(mutual TLS) 연결에서 서버는 브라우저에게 클라이언트 인증서를 요구하는데, Firefox가 서버가 받아주지 않을 인증서를 보내면 — 또는 핸드셰이크가 요구하는 걸 못 대면 — 서버는 치명적 bad_certificate 알림(TLS 알림 코드 42, RFC 5246 §7.2.2, TLS 1.3은 RFC 8446 §6.2로 계승)으로 응답하고, Firefox가 그 받은 알림을 SSL_ERROR_BAD_CERT_ALERT로 표시합니다. *서버* 인증서를 재발급·수정하는 건 아무 소용 없습니다. 애초에 문제 된 게 서버 인증서가 아니었으니까요. 거부된 건 클라이언트 인증서입니다.

이것과 SSL_ERROR_HANDSHAKE_FAILURE_ALERT는 뭐가 다른가요?

서버가 클라이언트 인증에 대해 보낼 수 있는 서로 다른 두 알림이고, 어느 쪽이 오느냐가 원인을 좁혀줍니다. SSL_ERROR_HANDSHAKE_FAILURE_ALERT는 알림 코드 40(handshake_failure)입니다: 서버가 수용 가능한 파라미터를 아예 협상하지 못한 것 — 흔히 클라이언트 인증서를 요구했는데 Firefox가 *하나도* 안 보내서 인증 단계 전에 핸드셰이크가 포괄적으로 죽은 경우죠. SSL_ERROR_BAD_CERT_ALERT는 알림 코드 42(bad_certificate)입니다: Firefox가 클라이언트 인증서를 *실제로 보냈고* 서버가 그걸 평가해서 수용 불가로 판단한 것 — 만료됐거나, 서버가 신뢰하지 않는 CA가 서명했거나, 폐기됐거나, 그 엔드포인트가 원하는 게 아닌 것. 더 좁은 사촌으로 SSL_ERROR_UNKNOWN_CA_ALERT(알림 48)가 있는데, 이건 구체적으로 '당신 클라이언트 인증서에 서명한 CA를 못 믿겠다'입니다. 셋 다 서버의 판정이 알림으로 Firefox에 전달된 것이고, 42는 인증서가 제시됐고 거부됐다고 말하는 쪽입니다.

회사·정부·뱅킹 사이트 한 곳에서만 실패합니다. 왜죠?

그 한 사이트가 mutual TLS를 요구하고 나머지는 안 하기 때문입니다. 웹의 압도적 다수는 브라우저에게 클라이언트 인증서를 요구하지 않아서 평범한 사이트는 다 잘 열립니다. 회사 인트라넷, 정부 포털, 뱅킹 백엔드, 파트너 API, 관리자 패널은 클라이언트 인증서나 스마트카드를 요구하는 일이 잦고, 바로 거기서 SSL_ERROR_BAD_CERT_ALERT가 나타납니다. 잘 되던 사이트에서 최근 시작됐다면 클라이언트 쪽에서 뭔가 바뀐 겁니다: 클라이언트 인증서가 만료됐거나, 스마트카드를 뺐거나, Firefox 프로필이 초기화됐거나, 제시하는 인증서가 서버가 아직 신뢰하도록 설정되지 않은 CA로 갱신됐거나. 외부 TLS 진단이 서버 자신의 인증서와 핸드셰이크가 멀쩡함을 확인해줘서, 문제를 당신이 보내는 클라이언트 인증서로 격리합니다.

조회수: 9

SSL_ERROR_BAD_CERT_ALERT: Firefox 해결

SSL_ERROR_BAD_CERT_ALERT는 서버 인증서가 아니라 당신의 클라이언트 인증서를 서버가 거부한 것. 인증서·발급 CA·만료를 점검하세요. 무료 SSL 진단으로 바로 확인.

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

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

문제

Firefox가 페이지를 SSL_ERROR_BAD_CERT_ALERT와 보안 연결 실패 — SSL peer cannot verify your certificate 메시지로 로드하지 못합니다. 거의 모두가 이걸 사이트 인증서 문제로 읽고 서버의 만료·체인을 확인하기 시작합니다. 헛다리입니다. 메시지를 그대로 읽으세요: 당신의(your) 인증서. 서버가 Firefox에게 클라이언트 인증서를 요구했고, Firefox가 하나를 제시했고, 서버가 그걸 거부했습니다. 이건 mutual TLS 실패이고, 의심받는 인증서는 당신 쪽 것입니다.

증상

Firefox가 보안 연결 실패와 코드 SSL_ERROR_BAD_CERT_ALERT, 그리고 SSL peer cannot verify your certificate 문구를 띄웁니다.
“예외 추가”·“위험 감수” 우회 버튼이 없습니다 — 이건 미신뢰 서버 인증서 경고가 아닙니다.
특정 사이트·포털·API 한 곳에서만 — 보통 회사·정부·뱅킹·내부 관리자 패널 — 발생하고 나머지 웹은 멀쩡합니다.
같은 엔드포인트가 Chrome·Edge에선 클라이언트 인증서가 이미 선택돼 있으면 열려서 Firefox 전용 버그처럼 보입니다.
클라이언트 인증서가 만료·갱신되거나, 스마트카드를 빼거나, Firefox 프로필을 초기화한 직후 시작됐습니다.

이 에러의 실제 의미

TLS 핸드셰이크는 클라이언트 인증을 포함할 수 있습니다. 서버가 CertificateRequest를 보내면 브라우저는 자기가 누구인지 증명할 클라이언트 인증서로 답합니다 — 이게 mutual TLS입니다. 그다음 서버가 그 클라이언트 인증서를 검증합니다: 유효 기간 안인가, 서버가 신뢰하도록 설정된 CA가 서명했나, 폐기되지 않았나, 구조적으로 온전한가? 답이 ‘아니오’면 서버는 치명적 bad_certificate 알림을 보냅니다 — TLS 알림 코드 42, RFC 5246 §7.2.2 정의: “인증서가 손상됐거나, 올바르게 검증되지 않는 서명을 담고 있는 등” — 그리고 TLS 1.3도 RFC 8446 §6.2에서 같은 알림을 유지합니다. Firefox는 받은 알림을 SSL_ERROR_BAD_CERT_ALERT로 표시합니다.

방향이 진단의 전부입니다. 이 알림은 서버가, 당신이 제시한 인증서에 대해 보낸 것입니다. Firefox가 서버를 불신하는 것도, 서버 자신의 인증서가 나쁜 것도 아닙니다. 서버가 “네가 건넨 신분증은 내가 받아줄 게 아니다”라고 말하는 겁니다. 그러니 조사 전체가 클라이언트 인증서로 옮겨갑니다: Firefox가 어느 걸 보내는지, 그게 유효한지, 그리고 서버가 그 발급 CA를 신뢰하도록 설정된 적이 있는지. Firefox는 이 오류가 얼마나 헷갈리는지 오래 추적해왔습니다 — raw 문구는 당신의 인증서를 지목하면서 왜 거부됐는지는 전혀 안 알려주죠(Bugzilla 1255049).

주요 원인 3가지

클라이언트 인증서가 만료·폐기됐거나 구조적으로 무효. 엔드포인트가 mutual TLS를 요구하는데 Firefox가 서버가 안 받을 인증서를 제시합니다 — notAfter 지남, 폐기됨, 또는 malformed. bad_certificate(알림 42)가 바로 “인증서가 손상됐거나 서명이 검증 안 되는” 경우입니다. 클라이언트 인증서가 만료되거나 스마트카드를 뺀 순간 나타나는 전형적 한-사이트 실패죠.
서버가 신뢰하지 않는 CA가 클라이언트 인증서에 서명. 당신 인증서는 유효한데 서버가 그 발급 CA를 신뢰하도록 설정된 적이 없거나 — 서버 trust store가 반영 못 한 새 중간 인증서로 갱신됐거나. 여기가 SSL_ERROR_UNKNOWN_CA_ALERT(알림 48)와의 경계입니다. 어떤 서버는 더 좁은 “unknown CA” 알림을, 다른 서버는 포괄적 bad_certificate를 보냅니다. 어느 쪽이든 수정은 클라이언트가 아니라 서버의 클라이언트-CA 신뢰 설정에 있습니다.
엉뚱한 인증서를 제시하거나, Firefox가 맞출 게 없음. Firefox가 클라이언트 인증서 여러 개를 갖고 있는데 엔드포인트가 안 받는 걸 내밀거나, 필요한 스마트카드 PKCS#11 모듈이 로드 안 돼서 맞는 인증서가 아예 제시되지 않습니다. 서버는 검증 못 할 신분을 보고 거부합니다. 프로필 초기화나 인증서 재설치 직후 이 오류가 뜨는 이유입니다.

DechoNet으로 진단

SSL 진단은 네트워크 밖에서 호스트에 완전한 TLS 핸드셰이크를 돌려 서버 자신의 인증서·체인·협상된 프로토콜을 보고합니다. 멀쩡하게 돌아오면 서버 쪽이 정상임을 증명한 겁니다 — 인증서가 유효하고 핸드셰이크를 완료할 수 있으니 — 따라서 당신 실패는 전적으로 당신 Firefox가 보내는 클라이언트 인증서에 관한 것입니다. 서버 만료·체인에 시간 낭비하지 않게 갈라주는 분기점입니다.
HTTP 진단은 브라우저 밖에서 사이트를 가져옵니다. 우리 진단은 클라이언트 인증서를 제시하지 않으므로 mutual TLS 엔드포인트는 대개 우리 것도 거부하지만 — SSL 진단은 서버 자신의 인증서와 TLS 스택이 온전한지를 확인해주고, 그게 문제를 클라이언트 인증으로 격리하는 데 정확히 필요한 정보입니다.

해결 체크리스트

서버 쪽 정상부터 확인. 외부 SSL 진단을 돌리세요. 서버 인증서가 유효하고 핸드셰이크가 깨끗하면 문제는 당신이 제시하는 클라이언트 인증서입니다 — 서버 만료는 그만 보세요.
클라이언트 인증서 유효성 확인. Firefox에서 설정 → 개인 정보 및 보안 → 인증서 → 인증서 보기 → 내 인증서. 이 엔드포인트용 인증서가 있는지, 유효 기간 안인지, 임포트 안 한 갱신본으로 대체되진 않았는지 확인하세요.
스마트카드 / PKCS#11 모듈 로드 확인. 엔드포인트가 스마트카드를 쓰면 보안 장치가 꽂혀 있고 모듈이 로드됐는지(설정 → 개인 정보 및 보안 → 보안 장치) 확인해 Firefox가 맞는 인증서를 실제로 제시할 수 있게 하세요.
서버가 당신 발급 CA를 신뢰하는지 물어라. 인증서는 유효한데 서버가 신뢰하도록 설정 안 된 CA·중간 인증서로 발급·갱신됐다면 서버가 거부합니다. 이건 엔드포인트 관리자와 조율하는 서버측 trust store 수정입니다.
서버 인증서를 재발급하지 마라. 그건 애초에 문제가 아니었습니다. 알림은 클라이언트 인증서에 관한 것이라 새 서버 인증서는 아무것도 안 바꿉니다.
클라이언트 대 서버 격리. 외부 SSL 진단이 깨끗한데 Firefox만 실패 → 당신 클라이언트 인증서. 외부 SSL 진단도 비정상 → 그건 이 문제가 아니라 전혀 다른 문제(서버 자신의 인증서)입니다.

에스컬레이션 시점

당신 클라이언트 인증서가 유효하고 최신인데 엔드포인트가 여전히 거부한다면, 그 서비스를 운영하는 쪽에 에스컬레이션하세요: 엔드포인트가 어떤 클라이언트 CA를 신뢰하는지, 당신 인증서의 발급자가 그 목록에 있는지는 그쪽만 확인할 수 있습니다. 새 중간 인증서로의 갱신이 흔한 방아쇠입니다.
명백히 클라이언트 인증서를 요구하는 엔드포인트에 대해 당신에게 인증서가 없다면, 그건 서비스 관리자의 등록(enrollment) 업무입니다 — 그들이 클라이언트 인증서·스마트카드를 발급·등록하고, 엔드포인트가 어떤 신분을 받아줄지 결정합니다.