SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE 원인

Problem

Firefox가 SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE와 “발급자 인증서가 만료되어 이 인증서를 신뢰할 수 없습니다”라는 줄로 사이트를 막습니다. 정확한 단어를 보세요 — 발급자(issuer). Firefox는 웹사이트의 인증서가 만료됐다고 말하는 게 아닙니다. 그걸 보증한 무언가 — 체인 위쪽 한두 칸의 CA 인증서 — 가 기한이 지났다고 말하는 겁니다.

이게 사람을 헷갈리게 하는 건, 바로 사이트 인증서를 확인하고 몇 달 남은 넉넉한 만료일을 보고는 Firefox가 틀렸다고 결론짓기 때문입니다. Firefox는 안 틀렸습니다. 인증서는 그걸 앵커하는 체인만큼만 유효하고, 그 체인의 어느 링크라도 만료됐으면 경로 전체가 실패합니다. 만료된 인증서는 당신이 보고 있는 것보다 위에 앉아 있습니다.

Symptoms

• 정확한 코드는 SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE, leaf 레벨의 SEC_ERROR_EXPIRED_CERTIFICATE와 구별됩니다.
• 웹사이트 본인의(leaf) 인증서는 확인해보면 여전히 유효합니다 — 만료는 체인 다른 곳에 있습니다.
• 오래된 기기와 OS만 걸리고 최신 기기는 사이트가 잘 뜨는 경우가 매우 잦습니다.
• 커맨드라인 도구끼리 의견이 갈립니다: 최신 openssl s_client는 깨끗이 검증하는데 옛 버전이나 옛 라이브러리는 만료된 발급자를 보고합니다.
• “아무것도 안 바꿨는데” 갑자기 뜰 수 있습니다 — 누가 서버를 건드려서가 아니라, 체인의 CA 인증서가 달력상 자기 만료일을 넘었기 때문입니다.

SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE의 실제 의미

TLS 신뢰는 체인입니다: 당신의 leaf 인증서는 중간 CA가 서명하고, 그 중간은 클라이언트가 이미 신뢰하는 루트가 서명(또는 교차 서명)합니다. 그 체인의 모든 인증서 — leaf, 각 중간, 루트 — 는 자기만의 notBefore/notAfter 유효 구간을 지닙니다. Firefox는 NSS 라이브러리를 통해 체인을 훑으며 전부 검사합니다. leaf는 유효한데 위쪽 발급자가 만료됐으면 SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE가 뜹니다. 당신 인증서가 나빠서가 아니라, 당신 인증서를 받쳐주는 것이 더 이상 유효하지 않아서 신뢰가 실패한 겁니다.

이걸 진짜 어렵게 만드는 미묘함은, 하나의 leaf 인증서가 종종 둘 이상의 체인으로 구성될 수 있다는 점입니다. CA는 교차 서명을 합니다: 하나의 중간을 옛 루트와 새 루트가 모두 서명해서, 둘 중 어느 루트를 가진 클라이언트든 신뢰 앵커에 닿게 합니다. 그 루트 중 하나가 만료돼도 인증서는 멀쩡합니다 — 클라이언트가 다른, 유효한 루트로 가는 체인을 고르기만 하면요. 고르느냐는 클라이언트 신뢰 저장소에 뭐가 있는지와 체인 구성 로직이 얼마나 좋은지에 달렸습니다. 같은 서버가 같은 날 한 브라우저에서는 되고 다른 브라우저에서는 실패하는 이유입니다.

교과서적 사례가 2020년 5월 30일 만료된 AddTrust External CA Root입니다. Sectigo(옛 Comodo)의 어마어마한 수의 인증서가 이걸 거쳐 체인됐습니다. 최신 클라이언트는 더 새로운 USERTrust RSA Certification Authority 루트(2038년까지 유효)를 갖고 깨끗한 경로를 만들었고, 오래된 클라이언트 — 특히 체인 선택 버그가 있는 1.1.1 이전 OpenSSL — 는 만료된 AddTrust 경로를 계속 골라 깨졌습니다. 같은 인증서, 같은 서버 — 실패는 전적으로 각 클라이언트가 어느 루트를 향해 손을 뻗었는지의 문제였습니다.

Top Causes

1. 서버가 낡은 중간을 보냄 - 서버가 스테이플링하는 체인이 최신 체인 대신 옛 중간 — 흔히 이제 만료된 루트로 이어주던 교차 서명본 — 을 포함합니다. 가장 흔하고 가장 고치기 쉬운 원인입니다: 서빙하는 체인을 CA가 제공하는 최신 체인으로 교체하세요.

2. 옛 루트가 만료됐는데 클라이언트에 대안이 없음 - 체인이 만료일을 지난 루트에서 끝나고, 실패하는 클라이언트의 신뢰 저장소에 더 새로운 교체 루트가 없습니다. 새 기기엔 있고 옛 기기엔 없어서, 실패가 낡은 OS에 몰리는 이유입니다.

3. 체인 구성 버그가 있는 옛 클라이언트 - 유효한 대안 경로가 있어도, 옛 TLS 라이브러리(1.1.1 이전 OpenSSL, 낡은 Android/macOS 스택)가 만료된 가지를 골라 실패할 수 있습니다. 이 경우 인증서도, 심지어 서빙 체인도 멀쩡할 수 있습니다 — 클라이언트가 올바로 고르기엔 너무 낡았을 뿐.

4. 갱신 안 된 진짜 만료 중간 - 더 드물지만 실재합니다: 내부·소규모 CA가 중간을 재발급 없이 만료시킨 경우. 그 아래 모든 인증서가 중간을 갱신·재배포하기 전까지 실패합니다.

DechoNet으로 진단

• SSL 점검은 서버가 실제로 제시하는 인증서 체인을 밖에서 검사해, 각 인증서의 유효 기간과 발급자를 보고합니다 — 그래서 어느 링크가 만료됐는지 추측 대신 볼 수 있습니다. 점검이 leaf는 유효한데 만료된 중간이나 낡은 루트에서 끝나는 체인을 짚어주면 찾은 겁니다: 서버가 잘못된 체인을 서빙 중이고, 해법은 유효 앵커를 가리키는 최신 중간을 설치하는 것입니다. DechoNet이 깨끗한, 전부 유효한 체인을 보이는데 오래된 기기만 실패하면, 문제는 서버가 아니라 — 그 클라이언트가 아직 지닌 만료된 루트로 체인을 완성하는 것이고, 답은 그들의 신뢰 저장소 업데이트입니다.

Resolution Checklist

• 무언가 만료됐다가 아니라 어느 인증서가 만료됐는지 보세요. 체인을 검사해 leaf·모든 중간·루트의 유효 기간을 읽으세요. leaf는 보통 멀쩡하고, 만료는 그 위에 있습니다.
• 외부 SSL 점검을 돌려 서버가 보내는 그대로의 체인을 보세요. 거기서 만료된 중간이나 낡은 루트로 끝나는 체인이면 서버 잘못입니다.
• 범위를 확인하세요. 오래된 기기만 실패하고 최신은 멀쩡하면 체인 선택 문제 — 서버가 레거시 체인을 보내거나, 옛 클라이언트에 교체 루트가 없는 겁니다.
• 서빙 체인이 낡았으면, CA가 주는 최신 중간 번들 — 유효 루트로 체인되는 것 — 을 설치하고 새로고침하세요. 도움 될까 싶어 leaf를 갱신하지 마세요. leaf는 문제가 아닙니다.
• 그냥 만료된 루트에 닿는 클라이언트라면, 그 기기의 OS와 루트 저장소를 업데이트하세요. 업데이트를 못 받는 너무 오래된 클라이언트라면, 깔끔히 고쳐줄 서버측 인증서는 없습니다.
• 내부 CA의 중간이 진짜 만료됐으면, 그 아래 모든 서버에 중간을 재발급·재배포하세요.

When to Escalate

• 외부 SSL 점검이 서빙 체인이 낡았음을 확인하면 이건 서버 수정이고, origin 운영자에게 만료된 인증서를 정확히 짚어줘야 합니다. “서빙 중인 중간이 만료됨; USERTrust(또는 당신 CA의 최신) 루트로 가는 체인을 설치하라”가 “인증서가 깨졌다”보다 훨씬 나은, 조치 가능한 요청입니다.
• 실패가 패치 불가한 오래된 기기에 국한되면, 인증서가 아니라 결정을 올리세요. 오래된 클라이언트 지원과 최신 체인 서빙 사이엔 진짜 트레이드오프가 있고, 둘을 완벽히 만족시키는 서버 설정은 없습니다. 누구를 아직 지원하느냐는 제품 판단이고, 그 결정 주체의 몫입니다 — 나머지 모두의 신뢰 경로를 조용히 약화시키는 낡은 체인으로 덮을 일이 아닙니다.