IL-0173 Devsisters · 2024-02-13kubernetessecurity

Let's Encrypt 가 기본 체인을 바꾼 뒤 cert-manager 의 preferredChain 처리 버그로 만료된 DST Root CA X3 체인 인증서가 발급돼, 구버전 BoringSSL 을 쓰는 클라이언트가 개발 서버에 접속하지 못했다.

Let's Encrypt 의 RSA 인증서에는 신뢰 체인이 두 가지 있다. 하나는 DST Root CA X3 이 ISRG Root X1 을 교차 서명한 체인이고, 다른 하나는 ISRG Root X1 에서 바로 시작하는 체인이다. 교차 서명 체인은 ISRG Root X1 을 신뢰하지 않는 안드로이드 7.1 미만 기기를 위해 남겨 둔 것이고, 2024년 9월 30일까지 유효하다. 신뢰 앵커는 체인을 검증할 때 출발점으로 삼는 루트의 공개 키와 그 신원이다. 대부분의 구현체는 신뢰 앵커의 만료일을 검사하지 않아 이 체인을 받아도 ISRG Root X1 까지만 검증해 문제없이 동작하지만, 만료일을 검사하는 구버전 BoringSSL 은 실패한다. 그래서 데브시스터즈는 cert-manager 에 preferredChain: ISRG Root X1 을 지정해 두었다.

Let's Encrypt 는 2월 8일 기본 체인을 DST Root CA X3 체인에서 ISRG Root X1 체인으로 바꾸고, DST Root CA X3 체인을 대체 체인으로 돌렸다. ACME 는 Let's Encrypt 같은 자동 인증서 발급 서비스가 쓰는 API 이고 RFC 8555 에 정의돼 있다. ACME 서버는 기본 체인과 함께 Link 헤더로 대체 체인을 알려 준다. 어느 체인을 쓸지는 클라이언트가 고른다. Certbot 디버그 로그로 확인해 보니 Let's Encrypt 는 의도대로 두 체인을 내주고 있었다.

문제는 cert-manager 의 체인 선택 로직이었다. cert-manager 는 preferredChain 을 찾을 때 기본 체인을 아예 후보에서 빼고, 대체 체인 안의 모든 인증서에서 발급자 CN 을 꺼내 설정값과 비교했다. 2월 8일 이전에는 기본 체인이 DST Root CA X3 체인이어서 이 동작이 문제를 일으키지 않았다. 이제는 원하는 ISRG Root X1 체인이 기본 체인이라 후보에서 빠졌고, DST Root CA X3 체인 안에도 발급자가 ISRG Root X1 인 인증서가 있어 이 체인이 선택됐다. 반면 Certbot 은 체인마다 루트에 가장 가까운 인증서의 발급자 CN 만 비교한다.

담당 엔지니어는 Let's Encrypt 커뮤니티 포럼과 cert-manager 저장소 어디에도 보고된 사례가 없자 바로 cert-manager 에 PR 을 올렸고, PR 은 머지됐다. 다음 날 같은 이슈가 cert-manager 저장소에 올라왔고, 약 5일 뒤 Let's Encrypt 커뮤니티에도 사례가 공유됐다. 데브시스터즈는 개발 환경에서 문제를 발견해 서비스 영향은 없었다.

심각도

–

영향 범위

Development server reached by clients using a library built on an old BoringSSL; no service impact

영향 사용자

–

지역

–

감지까지

–

복구까지

–