ca md too weak: 인증서를 재발급할까, 아니면 등급을 낮출까

OpenVPN 클라이언트가 지난달에는 동작했는데 이제 시작 시 ca md too weak 오류로 실패한다. 디스크의 프로필은 동작하던 것과 바이트 단위로 같다. 이 메시지는 인증 기관 인증서의 서명을 가리키며, 데이터 암호나 auth 다이제스트, 계정 암호와는 무관하다. 수정이 새 신원 자료인지, 새 체인인지, 의도적인 정책 변경인지는 세 가지 조건이 결정한다. 순서대로 처리하면 호스트의 모든 TLS 연결을 약화시켜 터널을 되살리는 흔한 결말을 피할 수 있다.

오류가 실제로 지목하는 것

OpenSSL은 체인을 만드는 도중 이 검증 오류를 낸다. CA 역할을 하는 인증서가 라이브러리의 보안 등급이 더는 받아들이지 않는 서명 다이제스트를 지녔을 때다. MD5는 기본 등급에서 거부되고, SHA-1은 등급을 올리는 순간 거부된다. 여기서는 말단 인증서의 다이제스트보다 그것에 서명하는 발급자의 다이제스트가 더 중요하다. 같은 정책이 발급 당시에는 지극히 평범했던 루트도 거부할 수 있다.

그래서 auth 또는 data-ciphers 를 편집해도 이 실패에는 아무 효과가 없다. 그 설정은 핸드셰이크 이후 패킷을 어떻게 보호할지를 정하며, 거부된 대상은 터널이 존재하기 전에 검사되는 신분 문서다. 인증서는 유효 기간 안에 편안히 들어 있어도 라이브러리가 받아들이지 않을 서명을 지닐 수 있다.

검사를 머릿속에서 분리해 두면 오류는 더 이상 불가사의해 보이지 않는다. 유효 기간, 키 용도 , 서명 다이제스트는 독립적인 시험이며, 그중 정확히 하나가 방금 실패했다.

조건 하나: 거부된 대상이 루트인가

프로필의 각 인증서를 출력해 subject와 issuer 필드를 읽는다. 자체 서명 루트는 둘에 같은 값을 보이며, 그 서명 알고리즘이 체인 전체의 토대다. 약한 다이제스트가 거기에 있다면 그 아래 모든 말단이 문제를 물려받는다. 나중 비교가 기억이 아니라 기계적이 되도록 알고리즘을 subject 옆에 적어 둔다.

묶음 CA 파일은 여러 블록을 담는 경우가 많으니 첫 번째가 범인이라고 가정하지 말고 실제로 적재되는 블록을 식별한다. openssl x509 -in ca.pem -noout -subject -issuer -text 명령은 한 번에 인증서 하나를 설명하므로, 묶음에 더 들어 있으면 먼저 나눠야 한다. 출력된 서명 알고리즘을 루트가 만들어진 시대에서 기대할 다이제스트와 비교한다.

약한 루트 아래에서 SHA-256으로 서명된 말단도 여전히 실패한다. 체인 검사가 꼭대기까지 올라가기 때문이다. 바로 그 순서가 다음 조건을 중요하게 만든다.

조건 둘: 발급자를 통제하는가

루트가 우리 조직의 것이라면 항구적인 해결은 현대적 다이제스트를 쓰는 새 루트와 재발급한 말단이며, 한 번의 프로필 갱신으로 배포한다. 여기에는 유지보수 시간대와 같은 날 갱신을 받을 수 없는 기기를 위한 계획이 든다.

체인을 제삼자가 발급했다면 해결은 그 운영자에 대한 요청이며, 로컬에서 유효한 유일한 조치는 옛 자료에 기대기를 그만두는 것이다. PEM 텍스트를 편집하거나 파일을 다시 저장해도 서명이 덮는 범위는 달라지지 않는다.

중간 사례 하나는 이름을 붙일 만하다. 현재 기본값보다 오래되었으나 다른 시스템이 신뢰하는 자료에 여전히 서명하는 내부 루트다. 이를 교체하려면 옛 인증서를 지문으로 고정해 둔 장비를 포함해 모든 소비자를 조사해야 한다. 변경을 예약하기 전에 그 소비자를 세어 보라. 하나를 놓친 루트 교체는 시작 오류를 장애와 맞바꾼다.

조건 셋: 등급을 낮추면 또 무엇을 받아들이는가

보안 등급을 낮추거나 OpenVPN의 레거시 인증서 프로필을 고르면 클라이언트가 옛 다이제스트를 다시 받아들인다. 그것은 같은 라이브러리의 다른 검사들도 그 프로세스가 여는 모든 연결에 대해 함께 느슨하게 만든다.

실험실에서, 또는 교체 자료를 준비하는 동안의 짧은 다리로서는 정당화될 수 있다. 단 예외가 한 프로필로 한정되고 종료 날짜를 가져야 한다. 공유 호스트의 영구 설정으로 두면 그곳의 모든 TLS 클라이언트가 무엇을 신뢰할지를 조용히 넓힌다.

예외는 소유자와 제거 단계를 함께 적어 둔다. 문서화되지 않은 등급 변경은 반년 뒤에는 실수와 구별되지 않으며, 다음 엔지니어는 그것이 한때 결정이었다는 사실을 알지 못한다.

결정을 규칙으로 적으면

발급자를 통제하고 그 소비자를 셀 수 있으면 체인을 교체한다. 그럴 수 없으면 발급자에게 에스컬레이션한다. 등급은 교체가 이미 예약된, 날짜가 붙은 제한적 예외로만 낮춘다. 그 밖의 모든 처리는 같은 인증서를 그대로 두고 위험을 덜 보이는 곳으로 옮길 뿐이다.

그다음 깨끗한 클라이언트에서 프로필을 다시 시험하고, 핸드셰이크가 끝나는지 확인하며, 여전히 실패하면 거부 문구를 그대로 보관한다. 정확한 오류 메시지는 다음 계층을 가진 사람에게 건넬 수 있는 가장 값싼 것이다.