교차 서명된 CA: 키는 일치하지만 AKI 바인딩은 그렇지 않다

두 CA 인증서가 같은 공개 키와 같은 subject를 가져도 서로 교환 가능하지 않을 수 있다. 하나는 자체 서명이고 다른 하나는 옛 루트가 교차 서명했으며, 발급자 이름과 일련번호, 서명이 다르다. 리프는 자신의 Authority Key Identifier를 통해 둘 중 하나에만 구체적으로 결속될 수 있다. 그 결속은 클라이언트가 잘못된 체인을 골라 handshake가 뚜렷한 이유 없이 실패할 때까지 보이지 않는다.

다음 다섯 가지 점검을 순서대로 하라. 각각은 서로 다른 실패를 배제한다.

점검 1: 템플릿을 건드리기 전에 두 체인을 모두 그려라

경로를 적어 두라. 옛 집단은 옛 루트 A를 신뢰하고, A가 CA B를 발급했고, B가 서버 리프를 발급했다. 새 집단은 자체 서명된 CA B를 직접 신뢰한다. 두 B 인증서는 같은 키와 subject를 지니며, 바로 그래서 subject 줄을 읽는 사람은 하나의 CA를 보는 곳에서 클라이언트는 둘을 본다.

교차 서명된 사본 역시 실제 CA 인증서여야 하며, 서명을 허용하는 basic constraints와 key usage를 갖춰야 한다.

점검 2: 키만이 아니라 AKI 필드를 비교하라

리프의 발급자 이름은 B의 subject와 일치해야 하며 그 부분은 대개 성립한다. 두 사본이 갈라지는 지점은 Authority Key Identifier인데, 키 식별자와 발급자 인증서, 일련번호를 담을 수 있기 때문이다. 키 식별자는 키가 동일하므로 두 사본 모두와 일치한다. 발급자와 일련번호 필드는 정확히 하나와만 일치하며, 그래서 자체 서명 사본에 맞춰 만든 체인이 교차 서명 사본에서는 실패할 수 있다.

추측하지 말고 리프를 확인하라: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

그다음 두 후보를 openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier"로 비교하고, 같은 명령을 자체 서명 사본에 대고 실행하라.

리프가 발급자와 일련번호를 담고 있다면 그 값이 설명하는 인증서만이 체인을 완성하며, 클라이언트가 어느 사본을 읽었든 상관없다.

점검 3: 발급 정책을 바꿔라, 서명된 바이트는 절대 바꾸지 마라

확장은 서명 안에 있다. 기존 리프에서 확장을 추가하거나 제거하거나 편집하는 것은 수리가 아니라 다른 인증서이며, 재발급이 필요하다. 변경은 발급 정책에 속한다. authorityKeyIdentifier = keyid,issuer:always는 새 리프가 인증서별 결속을 지니게 하고, keyid만 쓰면 의도적인 교차 서명 전환에 맞는 느슨한 형식을 유지한다. 다음 배치가 서명되기 전에 PKI가 어느 쪽을 원하는지 결정하라.

공유 템플릿을 편집하면 눈앞의 서버만이 아니라 앞으로의 모든 인증서가 바뀐다.

점검 4: 신뢰 집단마다 따로 검증하라

옛 경로와 새 경로를 별개의 실행으로 시험하라. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem는 교차 서명 경로를 연습하고, 새 루트를 쓰고 untrusted 파일을 지정하지 않은 같은 명령은 자체 서명 경로를 연습한다. 두 루트를 하나의 번들에 섞으면 어느 체인이 선택되었는지 가려진다. 그 뒤 실제 클라이언트로 반복하라. VPN 백엔드는 openssl이 하지 않는 방식으로 체인을 선호하거나 인증서를 고정할 수 있기 때문이다.

중간 인증서는 클라이언트가 실제로 읽는 서비스 구성으로 전달하고, 위키 페이지로 전달하지 마라.

점검 5: 옛 경로를 폐기 시한에 올려라

교차 서명은 옛 신뢰 경로를 설계상 살려 둔다. 그것이 목적이자 위험이다. 그것은 침해된 옛 루트를 치유하지 않으며, 어떤 클라이언트에서도 그 루트를 제거하지 않는다. 옛 경로가 신뢰를 주지 않게 되는 날을 적어 두고, 그날이 실제로 오는지 확인하라.

리프가 옮겨가기 전에 모든 클라이언트가 새 루트를 받아들일 수 있다면, 단순한 이중 신뢰 롤아웃이 교차 서명보다 간단하고, 폐기할 것도 하나 줄어든다.