MOZILLA_PKIX_ERROR_INADEQUATE_KEY_SIZE 해결

문제

Firefox가 HTTPS 사이트 로드를 거부하고 MOZILLA_PKIX_ERROR_INADEQUATE_KEY_SIZE를 띄웁니다. 보통 “경고: 보안 위험 가능성 있음”과 함께 뜨고, 엄격 경로에서는 통과 옵션도 없습니다. 인증서가 만료된 것도 아니고, 이름도 맞고, 발급자가 아는 곳일 수도 있습니다 — 하지만 체인 어딘가의 공개키가 너무 작아서, Firefox는 그 키가 보호하는 연결을 협상하지 않습니다.

증상

• Firefox가 오류 페이지나 “인증서 보기”에서 MOZILLA_PKIX_ERROR_INADEQUATE_KEY_SIZE를 표시.
• 같은 사이트에서 Chrome·Safari는 더 일반적인 약한 키 오류를 낼 수 있음 — 이 원인을 콕 집어 이름 붙이는 건 Firefox라서, 이 정확한 문자열로 검색하게 됨.
• openssl s_client -connect host:443은 정상 연결되고 체인 구조도 유효해 보임 — 문제는 끊긴 고리가 아니라 숫자.
• 특정 사이트 하나(그 사이트의 인증서·체인)에서만 나거나, Firefox의 거의 모든 HTTPS 사이트(로컬에서 트래픽을 재서명하는 무언가)에서 남.

이 오류의 진짜 의미

Firefox는 운영체제의 신뢰 저장소와 별개로 mozilla::pkix라는 라이브러리에서 자체 인증서 검사를 합니다. 그 검사 중 하나가 공개키 최소 크기이고, 비교 대상 상수 MINIMUM_NON_ECC_BITS는 2048로 설정돼 있습니다. 체인의 모든 인증서가 측정됩니다: 접속 대상 leaf, 그 위의 각 중간 인증서, 심지어 OCSP 응답자가 폐기 응답에 서명할 때 쓰는 인증서까지. 그중 하나라도 2048비트보다 작은 RSA·DSA 키를 갖고 있으면 mozilla::pkix는 멈추고 MOZILLA_PKIX_ERROR_INADEQUATE_KEY_SIZE를 반환합니다.

이 오류는 옛 범용 SEC_ERROR_INVALID_KEY에서 일부러 떼어낸 것입니다 — 메시지가 키가 거부된 이유를 알려주도록. 잘못된 형식이 아니라, 그냥 너무 짧다고. 뒤에 진짜 수학이 있는 정책 하한이죠. 1024비트 RSA는 약 80비트 보안인데, NIST가 2013년 말에 은퇴시켰습니다. 2048비트는 약 112비트로 현재 기준선입니다. Firefox가 까다로운 게 아닙니다. 결연한 공격자가 딸 수 있는 자물쇠 뒤에 자물쇠 아이콘을 숨기길 거부하는 겁니다.

실무 번역: 경로상의 어떤 인증서가 몇 년 전에 부적격해진 키로 생성됐고, Firefox가 그걸 이름까지 붙여 말할 만큼 엄격한 브라우저인 겁니다.

가장 흔한 원인 3가지

1. 레거시·사내 CA가 leaf를 1024비트(이하) 키로 발급 - 공개 CA는 2014년경부터 2048비트 미만 발급이 금지돼서, 이건 Let’s Encrypt나 DigiCert에서 거의 안 나옵니다. 사내 PKI, 오래된 엔터프라이즈 CA, 또는 임베디드 장비 — 라우터·프린터·스토리지 어플라이언스·IoT 기기 — 가 512·1024비트 인증서를 박아 출하한 뒤 한 번도 교체하지 않은 경우입니다.
2. 체인의 오래된 중간 인증서가 작은 키를 가짐 - leaf는 완벽히 현대적인 2048비트인데, 그 위 중간 인증서 — 서버가 체인에 끼워 보내는 그것 — 가 오래된 1024비트 CA 인증서일 수 있습니다. mozilla::pkix는 체인 전체를 검사하므로 짧은 고리 하나가 전부를 실패시킵니다. leaf가 멀쩡해 보여서 놓치기 쉽습니다.
3. 로컬 TLS 검사 프록시·백신이 약한 키로 재서명 - 거의 모든 HTTPS 사이트에서 오류가 나면, 보이는 인증서는 대개 사이트 것이 아닙니다 — 회사 미들웨어나 “HTTPS 검사” 백신이 자체 루트를 설치하고 즉석에서 작은 키로 재서명한 것입니다. 진짜 서버는 멀쩡하고, 가로채는 계층이 약한 쪽입니다.

DechoNet으로 진단하기

• SSL 진단은 서버가 외부에 실제로 제시하는 인증서를 네트워크 밖에서 읽어 체인을 보고합니다. 외부 체인이 전 구간 2048비트 이상이면, 약한 키는 로컬에서 주입되는 것 — 당신 기기의 프록시나 백신 — 이지 사이트가 제공하는 게 아닙니다.
• HTTP 진단은 사이트가 외부 클라이언트에 정상 응답하는지 확인해 “서버가 고장” 대 “내 기기의 Firefox가 신뢰 거부”를 분리합니다.
• 포트 진단은 443 도달 가능성을 확인해 TLS 계층 아래 순수 연결 문제를 배제합니다.

해결 체크리스트

• 먼저 한 사이트 대 모든 사이트를 격리하세요. 하나뿐이면 그 인증서나 체인이 문제입니다. Firefox의 사실상 모든 HTTPS 사이트라면 로컬 TLS 가로채기(회사 프록시, “HTTPS 검사” 백신)가 약한 키로 재서명하는 걸 의심하세요.
• 단일 사이트라면 SSL 진단을 돌려 leaf 와 모든 중간 인증서의 키 크기를 보세요. 실패하는 키는 leaf가 아니라 오래된 1024비트 중간인 경우가 많습니다.
• 2048비트 이상 RSA 키로 인증서를 재발급하거나, 2048 하한이 적용되지 않는 ECDSA 키로 전환하세요. CSR을 새로 생성하고 — 옛 약한 키를 재사용하지 마세요.
• 약한 고리가 중간 인증서라면 서버가 보내는 체인을 CA의 현재 적정 크기 중간으로 갱신하세요. SSL 진단을 다시 돌려 체인 전체가 깨끗한지 확인하세요.
• 로컬 가로채기라면 작은 키로 재서명하는 미들웨어를 고치거나 끄세요. about:config에서 security.pki.minimum_non_ecc_key_size_in_bits를 낮추는 건 해결이 아니라 다운그레이드 — 당신 브라우저 하나에서 진짜 약한 키를 가릴 뿐입니다.
• 재발급 후 SSL 진단을 다시 돌려 체인의 어떤 인증서도 2048비트 미만이 아님을 확인하세요.

에스컬레이션 시점

• SSL 진단에서 오리진이 2048비트 미만 키를 제공하면 그 사이트 PKI 담당자에게 넘기세요 — 장비나 사내 CA가 제대로 재발급돼야 하고, 진짜 약한 인증서에는 클라이언트측 해결책이 없습니다.
• 회사의 모든 HTTPS 사이트에서 오류가 나면 IT에 넘기세요: 검사 프록시나 엔드포인트 보안이 약한 키로 트래픽을 재서명하고 있고, 그걸 교체할 수 있는 건 그들뿐입니다.
• 교체 불가능한 어플라이언스가 1024비트 인증서를 출하한다면 벤더에게 현대적 키를 생성하는 펌웨어를 요청하세요 — 사용자마다 브라우저 설정을 만지는 방편은 확장되지 않고 약한 키를 그대로 남깁니다.