SSL_ERROR_HANDSHAKE_FAILURE_ALERT: Firefox 해결

문제

Firefox가 페이지를 SSL_ERROR_HANDSHAKE_FAILURE_ALERT와 보안 연결 실패 — SSL peer가 수용 가능한 보안 파라미터 집합을 협상하지 못했습니다 메시지로 로드하지 못합니다. 첫 반응은 인증서를 탓하는 것. 하지만 헛다리입니다. 여기서 거부된 인증서는 없습니다 — 연결이 인증서를 평가할 단계까지 가지도 못했습니다. 서버가 일부러 핸드셰이크를 끝내고 Firefox에 이유를 알렸으며, Firefox는 그 판정을 전달하고 있을 뿐입니다.

증상

• Firefox가 보안 연결 실패를 오류 코드 SSL_ERROR_HANDSHAKE_FAILURE_ALERT와 수용 가능한 보안 파라미터 집합을 협상하지 못했습니다라는 문구로 표시합니다.
• “예외 추가”·“위험을 감수하고 계속” 버튼이 없습니다 — 미신뢰 인증서 경고가 아니므로 Firefox가 우회를 제공하지 않습니다.
• 대개 특정 사이트·포털·API 하나에만 발생하고 웹 전반엔 아닙니다.
• 같은 URL이 Chrome·Edge에선 열리기도 해서(기본값이 다르거나 클라이언트 인증서가 이미 설치돼 있어) Firefox 버그처럼 보입니다.
• 회사·정부 사이트에선 스마트카드를 뺐거나, 클라이언트 인증서가 만료됐거나, 프로필을 초기화한 직후 시작됐습니다.

이 오류의 진짜 의미

TLS 핸드셰이크는 클라이언트의 ClientHello로 시작합니다: 자기가 할 수 있는 모든 것의 목록 — 프로토콜 버전·cipher suite·서명 알고리즘·지원 그룹(커브). 서버의 일은 그 메뉴에서 수용 가능한 조합 하나를 고르는 것입니다. 단 하나의 수용 가능한 조합도 못 찾거나, 클라이언트가 제공하지 않은 무언가가 필요하면, 서버는 치명적 handshake_failure 알림을 보냅니다 — TLS 알림 코드 40, RFC 5246 §7.2.2 정의: “handshake_failure — 이 알림의 수신은 발신자가 주어진 옵션으로 수용 가능한 보안 파라미터 집합을 협상할 수 없었음을 나타낸다.” Firefox는 그 받은 알림을 SSL_ERROR_HANDSHAKE_FAILURE_ALERT로 표출합니다.

Firefox 메시지의 ‘peer’를 문자 그대로 읽으세요. 협상하지 못한 peer — 서버 — 가 주체입니다. Firefox가 거절한 게 아니라, Firefox가 거절당한 겁니다. 이게 진단 전체를 뒤집습니다. 당신은 Firefox의 cipher 목록을 디버깅하는 게 아닙니다(그건 로컬에서 결정되는 SSL_ERROR_NO_CYPHER_OVERLAP처럼 보이죠). 당신은 서버가 요구한 무언가를 당신 Firefox 연결이 공급하지 못한 것을 디버깅하는 겁니다.

그 요구는 두 형태밖에 없습니다. 서버가 Firefox의 제안보다 더 원했거나 — 보내지 않은 클라이언트 인증서 — 아니면 Firefox의 제안에서 수용 가능한 게 없었거나: 공유 프로토콜 버전 없음, 공유 cipher 없음, 서버가 제시하려던 인증서에 쓸 서명 알고리즘 없음. 아래는 그 둘을 가리는 방법들입니다.

가장 흔한 원인 3가지

1. 서버가 클라이언트 인증서를 원하는데 Firefox가 안 보냄(상호 TLS) - 압도적으로 흔한 한 사이트 케이스. 서버가 클라이언트 인증을 요구하도록 설정돼 있는데, Firefox가 저장소에 맞는 클라이언트 인증서 없이 접속하면 서버는 RFC 5246 §7.4.6이 허용하는 대로 handshake_failure로 중단합니다. 회사 인트라넷·정부 서비스·뱅킹/파트너 API·관리자 패널이 그렇게 하죠. 지문: 한 엔드포인트만이고, 평범한 사이트는 멀쩡하며, 스마트카드·인증서·Firefox 프로필이 바뀌었을 때 깨졌다는 점. Firefox도 원본 오류가 진짜 원인을 가린다는 이유로 이를 Bugzilla 1362079로 추적합니다.
2. 서버가 수용할 겹침 없음 — 버전·cipher·서명 알고리즘 - 서버가 ClientHello를 평가하고 쓸 만한 걸 못 찾은 경우. 현대 Firefox가 더는 제안하지 않는 TLS 1.0/1.1에 박힌 레거시 장비·로드밸런서, 현재 Firefox가 내미는 모든 것을 배제한 cipher 목록으로 하드닝된 서버, 또는 서버가 보유한 인증서에 대한 서명 알고리즘·커브 불일치(ECDSA 전용 서버가 만족시킬 수 없는 클라이언트 제안을 만난 경우). 핸드셰이크는 인증서 제시 전, 파라미터 선택 단계에서 죽습니다.
3. SNI나 중간 장비가 ClientHello를 거부 - 서버가 가상 호스트·인증서가 없는 SNI를 받고 기본값을 서빙하는 대신 중단하도록 설정됐거나, 인라인 장비 — TLS 검사 프록시·WAF·로드밸런서 — 가 제안된 확장이나 지문을 근거로 연결을 거부하는 경우. 이땐 오리진 자체 TLS는 멀쩡할 수 있고, 그 앞의 무언가가 알림을 보내는 겁니다.

DechoNet으로 진단하기

• SSL 진단은 네트워크 바깥에서 호스트로 전체 TLS 핸드셰이크를 돌리고 실제로 협상되는 프로토콜 버전·cipher suite를 보고합니다. 진단이 완료되고 유효한 핸드셰이크를 보이면, 서버는 표준 클라이언트와 분명히 협상할 수 있는 것 — 그러니 당신 실패는 당신 Firefox 연결이 제안하는(또는 안 하는) 것에 관한 문제입니다: 없는 클라이언트 인증서, 잠긴 프로필, 로컬 검사 프록시. 진단이 역시 핸드셰이크에 실패하면 서버 TLS 정책이 문제입니다 — 현대적 겹침 없음, 또는 모두에게 클라이언트 인증서 요구 — 수정은 서버측입니다.
• HTTP 진단은 사이트를 아예 네트워크 바깥에서 가져옵니다. 외부 결과는 깨끗한데 당신 Firefox만 실패하면 오리진이 아니라 당신의 로컬 경로·특정 클라이언트 설정을 가리킵니다.

해결 체크리스트

• 외부 SSL 진단으로 서버냐 클라이언트냐부터 가르세요. 진단에선 서버가 깨끗이 협상하는데 당신 Firefox에서만 실패 → 문제는 당신 클라이언트(아래로). 외부 진단도 실패 → 서버 TLS 설정.
• 회사·정부·API 엔드포인트 하나라면 클라이언트 인증서 요구를 의심하세요. 맞는 클라이언트 인증서가 Firefox에 임포트됐는지(설정 → 개인정보 및 보안 → 인증서 → 인증서 보기 → 내 인증서) 확인하고, 스마트카드라면 PKCS#11 모듈이 로드됐고 카드가 꽂혀 있는지 확인하세요.
• 외부 SSL 진단이 서버가 옛 프로토콜·좁은 cipher만 제안한다고 보이면 수정은 서버측입니다: 오리진이나 로드밸런서에 TLS 1.2/1.3과 현대적 cipher suite를 켜세요. Firefox about:config에서 security.tls.version.min을 낮추지 마세요 — 그건 깨진 서버에 맞추는 다운그레이드이지 fix가 아니며, 다른 모든 연결을 약화시킵니다.
• 서로 무관한 여러 HTTPS 사이트에서 실패하면 로컬 TLS 검사 백신·회사 프록시가 잘못 재협상하는 것을 의심하세요. 잠시 끄고 테스트해 그걸로 풀리면, 꺼 두지 말고 검사 소프트웨어를 재설정·업데이트하세요.
• 변경할 때마다 재시도하고 SSL 진단을 다시 돌려 서버측이 끝에서 끝까지 깨끗한지 확인하세요.

에스컬레이션 시점

• 외부 SSL 진단이 건강한 서버를 보이는데 엔드포인트가 당신에게 없는 클라이언트 인증서를 요구하면, 그 서비스를 관리하는 쪽에 올리세요 — 그들이 클라이언트 인증서·스마트카드를 발급·등록하고, 엔드포인트가 어느 것을 기대하는지도 그들만 확인할 수 있습니다.
• 외부 진단이 서버가 폐기된 TLS나 비호환 cipher만 쓴다고 확인해 주면, 그 오리진·로드밸런서를 소유한 쪽에 TLS 설정 문제로 넘기세요(진단 결과를 증거로). 업데이트된 적 없는 레거시 장비에서 흔합니다.
• 실패가 한 기기·한 사무실 네트워크에서 여러 사이트에 나타나면, 엔드포인트 보안 소프트웨어나 네트워크 검사 중간 장비를 관리하는 쪽에 넘기세요 — 깨끗이 협상 못 하는 검사 프록시가 거의 확실한 범인이고, SSL 진단이 진짜 서버들은 멀쩡함을 증명합니다.