ERR_CERT_WEAK_SIGNATURE_ALGORITHM: SHA-1 인증서

Problem

Chrome이 NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM과 “연결이 비공개로 설정되어 있지 않습니다” 화면으로 페이지를 거부합니다. 인증서는 만료되지 않았고, 이름도 맞고, 체인도 해결됩니다 — 그래서 흔한 용의자들은 다 무죄죠. 이 오류는 인증서가 누구에게 언제 발급됐는지가 아니라 어떻게 서명됐는지의 문제입니다. 체인 어딘가의 인증서가 SHA-1로 서명됐고, Chrome은 수년 전 SHA-1 서명을 신뢰하지 않기로 했습니다.

이유는 현학이 아닙니다. SHA-1은 깨진 해시 함수입니다. 공개 CA는 2016년 1월 1일까지 SHA-1 인증서 발급을 중단했고, Chrome은 Chrome 56(2017년 1월 말 릴리스)에서 공개 루트로 이어지는 SHA-1 인증서를 완전히 불신했습니다. 몇 주 뒤인 2017년 2월, Google과 CWI Amsterdam이 SHAttered — 첫 실용적 SHA-1 충돌 — 를 발표해 “이론상 약함”을 “실증적으로 위조 가능”으로 바꿨습니다. 서명은 그 아래 해시만큼만 믿을 수 있고, SHA-1의 해시는 더 이상 전혀 믿을 수 없습니다. 그래서 Chrome은 경고하지 않고 거부합니다.

Symptoms

• Chrome(및 Chromium 브라우저)이 NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM을 표시합니다. 신원이 아니라 알고리즘이 문제라 대개 “무시하고 진행” 링크가 없습니다.
• 인증서는 그 외엔 유효합니다 — 만료 안 됨, 호스트명 정확, 체인 완전 — 그래서 헷갈립니다.
• 내부 도구, 낡은 네트워크 장비, IPMI/BMC 관리 콘솔, 라우터, 자체 호스팅 장비에서 가장 자주 나타납니다 — 2016년 이전 인증서나 아무도 현대화 안 한 사설 CA에서 나온 것들이죠.
• leaf 인증서 자체는 SHA-256인데 오류가 지속될 수 있습니다 — 약한 서명이 지금 보는 인증서가 아니라 중간 인증서에 있다는 신호입니다.

Top 3 Causes

1. 최신 체인 속 SHA-1 중간 인증서 - leaf는 SHA-256인데, 서버가 함께 보내는 중간 인증서가 CA가 오래전 교체한 낡은 SHA-1입니다. Chrome은 루트를 뺀 체인의 모든 서명을 검사하다 SHA-1 중간을 만나 전체를 거부합니다. 2026년 가장 흔한 실전 원인 — leaf가 완벽해 보여 다들 체인이 아니라 그것만 노려보기 때문입니다.
2. 여전히 SHA-1을 찍어내는 사설·내부 CA - SHA-256이 기본이 되기 전 설정하고 안 바꾼 사내 PKI, 홈랩 CA, 장비 벤더 내장 CA. 공개 CA는 더 이상 SHA-1을 발급 못 하므로, SHA-1 leaf는 사실상 항상 사설 발급자를 뜻합니다. 해결은 인증서를 사는 게 아니라 — CA와 그 아래 전부를 SHA-256으로 재생성하는 겁니다.
3. 낡은 자기 서명 인증서나 레거시 장비 - 라우터, 스토리지 어레이, 프린터, 하이퍼바이저 관리 인터페이스 등 수명 긴 하드웨어는 수년 전 생성돼 한 번도 교체 안 된 자기 서명 SHA-1 인증서를 그대로 씁니다. 장비는 멀쩡히 동작하고, 그 밑에서 브라우저의 규칙만 조여진 겁니다. 장비에서 인증서를 현대 알고리즘으로 재생성해야 합니다.

Diagnose with DechoNet

• SSL 진단은 서버가 제시하는 전체 인증서 체인을 검사하고 그 안 각 인증서의 서명 알고리즘을 보고합니다. 필요한 건 이 하나입니다: 어느 인증서가 SHA-1인지 — leaf인지 중간인지 — 알려주고, 그 한 사실이 인증서를 재발급할지 중간 번들을 재설치할지를 결정합니다.
• DNS 진단은 당신이 실제로 어느 호스트에 닿는지 확인합니다. 내부망에서는 호스트명이 낡은 인증서를 아직 서빙하는 옛 장비로 해석되는데 당신은 새 엔드포인트에 있다고 착각하기도 합니다 — 엉뚱한 장비를 손대기 전에 이걸 배제하세요.

Resolution Checklist

• 어느 인증서가 SHA-1인지 식별. SSL 진단을 돌려 체인의 각 인증서 서명 알고리즘을 읽으세요. leaf → 인증서 재발급. 중간 → 체인 번들이 낡음.
• 중간이 문제면 CA에서 최신 중간 번들을 받아 서버에 재설치. leaf는 멀쩡하고, 서버가 낡은 고리를 체인에 끼워 넣고 있을 뿐입니다. 재발급 불필요.
• 공개 CA leaf가 어쩐 일로 SHA-1이면 무료 재발급 요청 — 이제 모든 공개 CA가 기본으로 SHA-256을 발급하고, 재발급은 무료로 흔합니다.
• 사설·내부 CA면 SHA-1이 CA의 서명 방식에 박혀 있습니다. 발급 CA를 재생성(또는 SHA-256 서명으로 재구성)하고 그 아래 인증서를 재발급하세요. 클라이언트 신뢰 저장소에 있다면 새 CA를 재배포하세요.
• 레거시 장비·어플라이언스면 장비 관리 UI에서 자기 서명 인증서를 SHA-256으로 재생성하거나, 장비가 허용하면 현대 CA 인증서로 교체하세요.
• SSL 진단으로 재검증. 루트를 뺀 체인의 모든 인증서가 SHA-256(또는 그 이상)으로 나와야 합니다. SHA-1 루트는 예상된 것이고 괜찮습니다 — 그 서명은 결코 검증되지 않으니까요.

When to Escalate

• SSL 진단이 SHA-1 중간을 보여주는데 최신 번들 재설치로도 안 풀리면, 오리진 앞의 프록시나 로드밸런서가 TLS를 종단하며 자체 낡은 체인을 끼워 넣고 있을 수 있습니다. 브라우저에 실제로 인증서를 제시하는 홉에서 체인을 고치세요 — 처음 손댄 그 장비가 아닐 때가 많습니다.
• 벤더 어플라이언스가 인증서를 SHA-256으로 재생성할 방법을 안 주면, 그건 설정으로 이길 게 아니라 벤더에 넣을 지원 티켓입니다. 2026년에 SHA-1만 서명할 수 있는 장비는 브라우저 접근 관점에서 수명이 끝난 것이고, 정직한 답은 깨진 서명을 통과 클릭하는 게 아니라 앞에 현대 리버스 프록시를 두는 것입니다.
• “어제까진 되던” 인증서에 갑자기 이게 나타났다면, 인증서는 아무것도 안 바뀌었습니다 — 브라우저가 바뀐 겁니다. 알고리즘 집행을 조인 Chrome 업데이트나, 드디어 최신이 된 기기가, 줄곧 조용히 검사에 실패하던 SHA-1 체인을 표면화한 겁니다. 인증서는 처음부터 문제였고, 브라우저가 이제 그걸 봐주기를 멈췄을 뿐입니다.