NET::ERR_CERT_WEAK_KEY: Chrome 해결

문제

Chrome이 연결을 거부하고 NET::ERR_CERT_WEAK_KEY를 띄웁니다. ‘무시하고 진행’ 옵션도 없죠. 인증서가 만료된 것도, 이름이 안 맞는 것도 아닙니다 — 문제는 그 안의 암호 키입니다. 체인 어딘가의 인증서가 Chrome이 신뢰하기엔 너무 작은 RSA 키를 씁니다.

증상

• Chrome이 NET::ERR_CERT_WEAK_KEY를 우회 링크 없는 전체 화면 경고로 띄웁니다.
• 인증서는 그 외엔 멀쩡합니다 — 만료 안 됨, 호스트명 일치, 체인 존재.
• 사이트는 대개 내부·레거시 엔드포인트입니다: 라우터·방화벽 관리 페이지, 서버 대역외 관리 콘솔(iLO/iDRAC), 오래된 NAS, IoT 장비, 또는 사설 CA 뒤의 서비스.
• 구버전 브라우저나 Firefox(선을 다르게 긋습니다)에선 로드될 수 있어 일관성 없어 보입니다.

이 오류의 진짜 의미

모든 TLS 인증서는 공개 키를 담고, 그 키의 강도가 공격자와 서버 사칭 사이를 막는 벽입니다. RSA 키의 강도는 크기에서 나옵니다. 512비트 키는 수년 전에 이미 소인수분해됐고, 1024비트 키는 자원 있는 공격자의 사정권 안이라 장기 사용엔 부적합하다고 십수 년째 여겨져 왔습니다. Chrome은 하드 하한을 박아 뒀습니다: 1024비트 미만 RSA 키는 ERR_CERT_WEAK_KEY로 즉시 거부됩니다(이를 시행하는 Chromium 변경은 “Enforce a minimum RSA key size of 1024”로 추적됩니다). 무시하고 넘어갈 수 있는 경고가 아니라 거부입니다.

이 오류가 그저 성가신 게 아니라 진단에 진짜 쓸모 있게 만드는 사실이 둘 있습니다.

첫째, 공개 CA는 원인이 될 수 없습니다. CA/Browser Forum Baseline Requirements가 공개 CA의 1024비트 미만 RSA 키 발급을 금지했고, 2013-12-31 이후 유효한 것은 전부 금지선 밖입니다. 그러니 ERR_CERT_WEAK_KEY를 건드릴 만큼 약한 인증서는 Let’s Encrypt·DigiCert 같은 공개 CA에서 온 게 아닙니다 — 사설·내부 CA, 자체서명 어플라이언스, 스스로 키를 생성한 임베디드 장비, 또는 규칙이 조여지기 전에 발급된 오래된 인증서입니다. 이것만으로 어디를 봐야 할지 좁혀집니다.

둘째, Chrome은 leaf만이 아니라 체인 전체를 검사합니다. 완벽히 현대적인 2048비트 leaf 인증서도 낡은 1024비트 중간 인증서를 거쳐 체인되면 여전히 오류를 냅니다. 루트 인증서는 예외입니다 — 자기 서명 신뢰 앵커라 같은 방식으로 검증되지 않습니다 — 하지만 루트 아래의 모든 인증서는 기준을 넘어야 합니다. 약한 중간 인증서는 흔하고 놓치기 쉬운 원인입니다: 서버 인증서는 그 자체로 멀쩡해 보이고, 약점은 한 단계 위에 있죠.

가장 흔한 원인 3가지

1. 작은 자체서명 키를 가진 레거시 어플라이언스·장비 - 라우터, 방화벽, 관리 콘솔, 오래된 NAS, IoT 장비는 공장에서 박은 512·1024비트 RSA 키로 생성한 자체서명 인증서를 달고 나오는 경우가 많습니다. 수년간 잘 됐는데, Chrome 업데이트가 하한을 조여 이제 관리 페이지에 못 들어갑니다. 펌웨어가 허용한다면 장비 인증서를 현대적 키로 재생성하는 게 해결입니다.
2. 멀쩡한 체인 속 약한 중간 인증서 - leaf 인증서는 건강한 2048비트 키인데, 발급한 내부 CA의 중간 인증서가 여전히 수년 전 1024비트 키를 씁니다. Chrome은 경로 전체를 검증해 약한 중간에서 거부합니다. 서버 관리자는 멀쩡한 leaf를 보고 당황하지만, 문제는 CA 계층 상단입니다.
3. 2048비트 시대 이전의 오래된 인증서 - 오래 사는 내부 인증서, 또는 임베디드 시스템 무리에 재사용된 인증서가 1024비트가 정상이던 시절에 발급되고 한 번도 교체되지 않았습니다. “2014년부터 잘 되던” 인증서를 브라우저 업데이트가 마침내 따라잡은 것이죠.

DechoNet으로 진단하기

• SSL 진단은 서버 인증서를 읽어 leaf와 그것이 제시하는 체인의 키 종류·크기를 보고합니다. 약한 키가 서버 인증서 자신인지 그 위 중간 인증서인지 바로 알려주죠 — 어느 인증서를 재발급해야 하는지 아는 데 필요한 단 하나의 사실입니다.
• 네트워크 바깥에서 SSL 진단을 돌리면 서버와 로컬도 격리됩니다: 도구는 건강한 2048비트 체인을 보고하는데 내 기기의 Chrome만 오류를 내면, 약한 키가 로컬에서 주입되는 것입니다 — 트래픽을 작은 키로 재서명하는 TLS 검사 프록시나 백신이지 진짜 서버가 아닙니다.

해결 체크리스트

• SSL 진단을 돌려 leaf만이 아니라 체인의 모든 인증서 키 크기를 읽으세요. 2048비트 미만인 인증서 — leaf인지 중간인지 — 를 특정하세요.
• leaf라면 새 2048비트 RSA 키(또는 ECDSA P-256 키)로 인증서를 재발급하세요. 기존 약한 키를 제자리에서 업그레이드할 수 없습니다 — 새 키 쌍을 생성해 그것에 대해 재발급하세요.
• 사설·내부 CA의 중간 인증서라면, CA의 중간을 충분한 키를 쓰는 것으로 교체하고 그 아래 인증서를 재발급해야 합니다. 서버가 아니라 CA 쪽 작업입니다.
• 약한 인증서가 박힌 공장 장비라면, 인증서를 재생성하는 펌웨어가 있는지 확인하거나, 현대적 인증서로 TLS를 종단하는 리버스 프록시를 장비 앞에 두세요.
• SSL 진단은 깨끗한 체인을 보이는데 오류가 한 기기에서만 나타나면, TLS 검사 백신·회사 프록시를 끄세요 — 로컬에서 약한 키로 재서명하고 있습니다.
• 재발급 후 SSL 진단을 다시 돌려, 제시되는 체인의 모든 인증서가 2048비트 RSA 또는 현대적 ECDSA 키인지 확인하세요.

에스컬레이션 시점

• 약한 인증서가 키를 재생성할 수 없는 네트워크 어플라이언스·벤더 장비 것이면, 현대적 인증서를 발급하는 펌웨어를 벤더에 에스컬레이션하세요 — 아니면 리버스 프록시를 앞에 두고 거기서 TLS를 종단하세요.
• 약한 키가 내부 PKI의 중간 인증서면, CA 운영자에게 넘기세요. 중간과 그 아래 전부를 재발급하는 건 빠른 서버 변경이 아니라 계획된 PKI 작업입니다.
• 브라우저 키 크기 하한을 낮추려 about:config나 커맨드라인 플래그에 손대지 마세요. 그건 그 기기의 모두에게서 안전장치를 끄는 것이고, Chrome이 하한을 2048로 올리는 중이라 인증서는 곧 다시 실패할 뿐입니다 — 재발급하세요.