MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT 해결

문제

Firefox가 “Warning: Potential Security Risk Ahead”로 막아서고, 고급 버튼 뒤에는 MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT 오류 코드와 “The certificate is not trusted because it is self-signed”라는 문구가 있습니다. 그 사이트는 Chrome에서는 멀쩡히 열립니다. 다른 기기의 Firefox에서도 멀쩡할 수 있습니다. 이건 Firefox가 받은 인증서가 스스로에게 서명했다고 — 신뢰하는 어떤 기관으로도 이어지는 체인이 없다고 — 알려주는 것입니다.

증상

• 오류 페이지에 SEC_ERROR_UNKNOWN_ISSUER나 SEC_ERROR_EXPIRED_CERTIFICATE가 아니라 MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT가 표시됩니다.
• 같은 컴퓨터의 Chrome·Edge에서는 같은 URL이 경고 없이 열립니다.
• 공개 사이트라면 Firefox 어디서나 실패하고, 내부 사이트라면 특정 한 기기에서만 실패합니다.
• openssl s_client -connect host:443 -servername host가 verify error:num=18:self signed certificate와 정확히 한 단계 깊이의 체인을 보고합니다.
• 스테이징 서버, 가정용 공유기, NAS, 프린터, 기본 인증서를 탑재한 어플라이언스에서 흔합니다.

이 오류가 실제로 뜻하는 것

모든 인증서는 **발급자(Issuer, 누가 보증했는가)**와 **주체(Subject, 누구를 위한 것인가)**를 담습니다. 정상 체인에서는 이 둘이 다릅니다: 리프 인증서의 발급자는 중간 CA이고, 그 발급자는 루트이며, 그 루트 인증서는 Firefox의 신뢰 저장소에 있습니다. Firefox는 그 체인을 신뢰하는 루트까지 거슬러 올라가고, 자물쇠가 나타납니다.

자체 서명 인증서는 한 단계짜리 체인입니다. 발급자와 주체가 동일합니다 — 스스로를 보증합니다. 위로 거슬러 올라갈 대상이 없고 신뢰하는 루트도 아니므로, Firefox의 인증서 검증기(mozilla::pkix)는 멈추고 자신이 발견한 구체적 조건을 보고합니다: 인증서가 자기 자신의 발급자다. 이 구체성이 유용한 부분입니다. “중간 인증서를 못 찾았다”(그건 SEC_ERROR_UNKNOWN_ISSUER)가 아니라, 찾을 중간 인증서가 없다는 뜻입니다. 인증서가 곧 체인 전체입니다.

이걸 Firefox 전용의 놀라움으로 만드는 한 가지 결: Firefox는 자체 루트 저장소를 유지하고, 기본 상태에서는 OS 인증서 저장소를 참조하지 않습니다. Windows에 인증서를 넣으면 Chrome은 신뢰하지만, Firefox는 당신이 직접 Firefox에 가져오거나 security.enterprise_roots.enabled를 켜기 전까지 알아채지 못합니다. 그러니 “Chrome에선 되고 Firefox에선 안 된다”는 Firefox 버그가 아니라 — 같은 인증서를 두고 서로 다른 두 신뢰 저장소가 이견을 내는 것입니다.

주요 원인 3가지

1. 서버가 실제로 자체 서명 인증서를 제공한다. openssl로 만든 인증서를 쓰는 개발/스테이징 서버, 또는 공장 기본값을 내미는 어플라이언스(공유기, NAS, iDRAC, 프린터). 압도적으로 흔한 경우입니다. 판별: openssl s_client가 verify error:num=18과 한 단계 깊이의 체인을 보여주고, Firefox에서 어디서나 실패한다.
2. 엉뚱한 인증서를 배포했다. CA가 발급한 리프와 그 중간 인증서를 설치하려 했는데, 실제로 올라간 건 사설 CA의 자체 서명 루트이거나, 끝내 교체되지 않은 임시 인증서입니다. 판별: 제공되는 주체/발급자가 호스트명이 아니라 내부 CA 이름이다.
3. 클라이언트 쪽에서 TLS를 가로챈다. HTTPS 검사를 하는 회사 프록시나 백신이 자기 자체 서명 인증서로 바꿔치기할 수 있습니다. 판별: 특정 한 기기나 한 네트워크에서만 재현되고, 다른 기기에서는 사이트가 깨끗이 열린다. (Firefox는 알려진 가로채기를 대신 MOZILLA_PKIX_ERROR_MITM_DETECTED로 표시하기도 하지만, 항상은 아닙니다.)

DechoNet으로 진단하기

• SSL 진단은 호스트가 실제로 제공하는 인증서를 가져와 체인을 보여줍니다 — 리프가 자체 서명인지(발급자=주체, 체인 길이 1), 아니면 Firefox가 그저 모르는 기관에 서명받았는지. 그 하나의 구분이 진짜 인증서가 필요한지 아니면 중간 인증서만 빠졌는지를 알려줍니다.

해결 체크리스트

• 코드가 UNKNOWN_ISSUER가 아니라 SELF_SIGNED_CERT인지 확인하세요 — 앞은 진짜 인증서가, 뒤는 빠진 중간 인증서가 필요합니다. 엉뚱한 걸 고치지 마세요.
• 호스트에 SSL 진단을 돌려 체인을 읽으세요: 길이 1에 발급자/주체가 같으면 자체 서명이 확정됩니다.
• 공개 사이트: 자체 서명 인증서를 CA 발급 인증서로 교체하세요. Let’s Encrypt의 무료 ACME 인증서면 몇 분이면 되고, 모든 브라우저에서 오류가 한 번에 사라집니다. 자체 서명은 공개 인터넷에 있을 물건이 아닙니다.
• 내가 통제하는 내부/개발 호스트: 사설 CA에서 인증서를 발급하고 그 CA의 루트를 기기들에 배포하거나, 해당 인증서를 Firefox의 **인증서 관리자 → 인증기관(Authorities)**에 가져오세요. 전사 관리 Windows라면 security.enterprise_roots.enabled = true로 Firefox가 OS 저장소를 읽게 할 수 있습니다.
• 특정 한 기기에서만 재현되면 서버를 손대기 전에 백신/프록시의 TLS 검사를 살피세요 — 서버는 멀쩡할 수 있습니다.
• 명령줄에서 확인: openssl s_client -connect host:443 -servername host — verify error:num=18:self signed certificate가 나오면 원인이 확정됩니다.

에스컬레이션 시점

• SSL 진단이 정상적인 CA 발급 체인을 보여주는데 Firefox에서만 여전히 자체 서명이라고 한다면, 문제는 서버가 아닙니다 — 클라이언트 쪽 가로채기 계층이 인증서를 다시 쓰고 있는 것이고, 해결은 웹 서버가 아니라 그 엔드포인트나 프록시 설정에 있습니다.