SEC_ERROR_UNKNOWN_ISSUER (Firefox) 해결

Problem

Firefox가 Warning: Potential Security Risk Ahead와 함께 SEC_ERROR_UNKNOWN_ISSUER 오류 코드를 표시합니다. 서버가 제시한 인증서가 깨진 게 아니라, Firefox가 그 인증서를 자기 신뢰 저장소의 인증기관까지 거슬러 올라가지 못한 것입니다. 유효한 인증서는 리프 → 중간 → 신뢰된 루트로 체인을 이뤄야 합니다. Firefox는 리프는 받았지만 그 체인을 완성하지 못했고, 그래서 연결을 신뢰하지 않습니다. 관건은 체인이 어디서 끊겼는가입니다: 서버(중간 인증서 누락), 내 컴퓨터(트래픽을 재서명하는 무언가), 또는 Firefox 신뢰 저장소(없는 루트).

Symptoms

• 전체 화면 경고에 SEC_ERROR_UNKNOWN_ISSUER가 표시됩니다. Chrome·Edge는 같은 근본 조건을 NET::ERR_CERT_AUTHORITY_INVALID로 표현합니다.
• 백신·프록시 가로채기의 경우 Firefox는 더 구체적인 MOZILLA_PKIX_ERROR_MITM_DETECTED를 대신 보여줄 수 있습니다.
• 한 사이트라면: Chrome이나 휴대폰에서는 잘 열리는데 Firefox에서만 실패하는 경우가 많습니다 — 중간 인증서 누락의 특징입니다.
• 모든 사이트라면: 오류가 사이트가 아니라 나를 따라다닙니다 — 로컬 TLS 가로채기의 특징입니다.

Top 3 Causes

1. 서버에 중간 인증서가 빠짐 - 단일 사이트에서 가장 흔한 원인. 서버가 리프 인증서만 보내고 루트로 이어주는 중간 인증서를 생략합니다. Firefox는 빠진 중간 인증서를 네트워크로 가져오지 않으므로(AIA fetching 없음), 미리 받아뒀거나 캐시하지 않은 이상 체인을 못 만듭니다. Chrome은 중간 인증서를 가져와 같은 설정 오류를 가려주는데, 그래서 “Chrome에선 됨”은 서버가 올바르게 설정됐다는 증거가 아닙니다.
2. 백신이나 프록시가 TLS를 가로챔 - 여러 사이트에서 오류가 뜬다면, HTTPS/SSL 검사를 하는 백신(또는 회사 MITM 프록시)이 트래픽을 복호화해 자기 CA로 재서명하는 것입니다. Firefox는 자체 루트 저장소를 쓰므로 그 CA를 신뢰하지 않아 SEC_ERROR_UNKNOWN_ISSUER — 패턴을 인식하면 MOZILLA_PKIX_ERROR_MITM_DETECTED — 를 보고합니다.
3. Firefox 저장소에 없는 자체 서명·사설 루트 - 내부 도구, 개발 환경, 어플라이언스는 자주 자체 서명 인증서나 사설 CA를 씁니다. Firefox는 OS와 별개로 자체 NSS 신뢰 저장소를 유지하므로, 루트를 Windows·macOS에 임포트하는 것만으로는 부족합니다 — 루트가 Firefox 저장소에 있거나 기업 루트 읽기가 켜져야 신뢰합니다.

Diagnose with DechoNet

• SSL Check는 서버가 보내는 체인을 그대로 보여줍니다 — 리프, 그리고 중간 인증서 포함 여부. 여기서 체인이 불완전하면(중간 없는 리프) 원인 #1이 확인된 것이고, 해결은 Firefox가 아니라 서버 쪽입니다.
• HTTP Check는 TLS를 제쳐두고 엔드포인트가 응답하는지 확인해, 인증서 체인 문제와 실제 연결 실패를 구분하는 데 유용합니다.

Resolution Checklist

• 먼저 범위를 판단하세요: 오류가 한 사이트인가, 여러 사이트인가? 한 사이트 → 서버의 체인 문제. 여러 사이트 → 내 컴퓨터의 가로채기. 이 한 질문이 올바른 해결로 안내합니다.
• 한 사이트라면 서버가 보내는 체인을 점검합니다: openssl s_client -connect YOUR_DOMAIN:443 -servername YOUR_DOMAIN -showcerts. 리프 하나(CERTIFICATE 블록 1개)만 보이고 중간이 없으면 서버 설정 오류입니다. 전체 체인(리프 + 중간 번들)으로 인증서를 다시 설치하세요 — 대부분의 CA가 바로 이 용도의 “fullchain” 파일을 제공합니다.
• SSL Check를 다시 돌려 이제 중간 인증서가 체인에 나타나는지 확인합니다. “Chrome에서 열린다”에 기대지 마세요 — Chrome의 AIA fetching이 Firefox가 정당하게 거부하는 누락 중간을 가려줍니다.
• 여러 사이트라면 백신의 HTTPS/SSL 검사(흔히 “웹 실드”, “암호화 연결 검사”, “SSL 검사”)를 끕니다. 오류가 사라지면 그게 원인이었습니다. 꼭 켜둬야 한다면 Firefox가 기업 루트를 신뢰하게 하세요: about:config에서 security.enterprise_roots.enabled를 true로 설정하고 재시작합니다.
• 내부·자체 서명 인증서라면 루트를 Firefox에 직접 임포트합니다: 설정 → 개인 정보 및 보안 → 인증서 → 인증서 보기 → 인증 기관 → 가져오기. OS 저장소에만 임포트해서는 Firefox에 닿지 않습니다.
• 서버 쪽이 진짜로 미신뢰·만료된 루트라면, 실제 해결은 공개적으로 신뢰되는 CA에서 재발급하는 것입니다 — 경고를 그냥 통과시키면 사용자가 진짜 보안 통제를 무시하도록 길들이게 됩니다.

When to Escalate

• SSL Check가 완전한 체인을 보여주는데도 Firefox가 여전히 실패한다면, 시스템 시계와 루트 자체의 유효기간을 확인하세요 — 만료됐거나 신뢰 철회된 루트 CA(브라우저는 주기적으로 CA를 저장소에서 제거합니다)는 체인이 올바르게 구성돼도 이 오류를 냅니다. 해결은 현재 신뢰되는 CA에서 받은 새 인증서입니다.
• 가로채기가 내가 통제하지 못하는 회사 프록시라면, 기업 루트를 IT가 Firefox에 배포해야 합니다(security.enterprise_roots.enabled 또는 엔터프라이즈 정책). 이는 머신별로 고칠 일이 아니라 엔드포인트 관리 작업입니다.
• 체인의 추가 CA가 정당한 백신인지 실제 공격자인지 판단이 안 서면, 입증 전까지 의심스러운 것으로 다루세요 — MOZILLA_PKIX_ERROR_MITM_DETECTED가 존재하는 이유가 바로 그 구분이 중요하기 때문입니다.