ID를 바꾸지 않고 VPN 인증서 갱신하기

정체성을 바꾸는 인증서 갱신은 갱신이 아니라 유지보수 티켓을 쓴 이전입니다. 클라이언트는 이름, 체인, 때로는 특정 키를 검증하며, 이 셋은 만료일이 바뀌지 않은 채로 바뀔 수 있습니다. 교체를 요청하기 전에 클라이언트가 실제로 확인하는 것을, 호스트 이름 또는 피어 ID, 인증서 용도, 키 정책, 발급 체인으로 적어 두십시오. 갱신이 일상적인지 조정된 것인지는 교체가 이 중 무엇을 바꾸는지에 달려 있습니다.

세 가지 조건이 갱신의 형태를 결정한다

세 조건은 무언가가 리프를 고정하는지, 체인이 바뀌는지, 누가 또 이름을 검증하는지입니다. CA의 편의가 아니라 새벽 세 시에 실패하는 쪽이 클라이언트이므로 클라이언트 측에서 답하십시오.

가지고 있는 인증서를 검사하는 것으로 시작하십시오. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName 는 주체, 발급자, 유효 기간, 그리고 인증서가 실제로 유효한 이름을 출력합니다. 마지막 필드가 가장 중요하고 가장 흔히 전제되는데, 클라이언트가 의존하는 SAN을 빠뜨린 갱신 요청은 기술적으로는 유효하지만 기능적으로는 잘못된 인증서를 만듭니다. 이전 인증서의 SAN 목록을 기억에서 다시 입력하지 말고 요청에 복사하십시오.

조건 하나: 무언가가 리프를 고정하는가

클라이언트가 유지되는 CA를 신뢰하고 이름을 검증한다면, 새 키로 하는 리프 갱신은 그들에게 보이지 않습니다. 어떤 클라이언트든 리프 인증서, 그 지문, 또는 그 공개 키를 고정한다면, 이전 고정으로는 새 인증서를 검증할 수 없기 때문에 교체는 강제 전환이 따르는 조정된 변경입니다.

무엇이든 주문하기 전에 어떤 경우인지 알아내십시오. 아무도 문서화하지 않은 고정도 깨질 때는 고정입니다.

조건 둘: 고정과 체인을 비교하라

지문이 있으면 고정을 확인할 수 있습니다: 이전 인증서와 새 인증서에서 openssl x509 -noout -fingerprint -sha256 -in server.crt, 공개 키를 비교하려면 openssl x509 -noout -pubkey 입니다. 클라이언트 구성, 모바일 프로필 또는 어플라이언스 신뢰 저장소에 그 값 중 하나가 있으면 고정이 있는 것입니다. 모바일 VPN 프로필은 프로필이 한 번 배포되고 다시는 검사되지 않기 때문에 흔한 은신처입니다.

교체가 같은 중간 인증서에서 오고 클라이언트가 그 중간 인증서를 이미 가지고 있거나 가져올 수 있다면, 신뢰 쪽에서는 아무것도 바뀌지 않습니다. 새 중간 인증서, 다른 발급자, 또는 잘못된 순서로 전달된 체인은 갱신을 신뢰 변경으로 바꾸고, 그때의 장애는 만료된 인증서가 아니라 알 수 없는 발급자처럼 보입니다.

서버가 실제로 보내는 체인을 openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts 로 확인하고, openssl verify -CAfile ca.pem -untrusted chain.pem server.crt 로 로컬에서 검증하십시오. 변경 전에 그렇게 하면 나중에 비교할 기준선이 생깁니다.

조건 셋: 누가 또 이름을 검증하는가

VPN 집선기, 로드 밸런서, 모니터링 프로브, RADIUS 또는 SAML 통합, 모바일 프로필은 각각 예상 이름이나 신뢰 앵커의 자체 사본을 보관할 수 있습니다. 갱신은 인증서는 바뀌고 사본은 바뀌지 않기 때문에 그 사본들이 갈라지는 순간입니다.

변경 전에 모든 소비자를 나열하고 각각 업데이트가 필요한지 결정하십시오. 잊은 것이 바로 당신을 부르는 것입니다.

타이밍 함정도 있습니다. 만료뿐 아니라 유효 시작도, 나중 활성화를 위해 준비된 인증서가 너무 일찍 설치되면 거부되고 그 오류가 준비 문제가 아니라 시계 문제처럼 보이기 때문에 검사하십시오. 배포 전에 새 파일에서 openssl x509 -noout -dates 를 실행하는 것은 두 초짜리 확인입니다. 지원되는 복구 경로와 알려진 정상 구성을 유지하여, 잘못된 갱신을 이전 인증서와 키를 복원해 되돌릴 수 있게 하십시오.

배포하고, 새 인증으로 검증한 다음 폐기하십시오

구축된 터널은 구축될 때 일어난 검증을 반영하므로, 모든 새 연결이 실패하는 동안에도 건강해 보일 수 있습니다. 클라이언트가 사용하는 실제 서비스 이름으로 새 인증을 통해 테스트하십시오.

사용자가 신경 쓰는 애플리케이션 수준 확인을 완료하고, 체인 전달을 서버가 아니라 클라이언트 관점에서 확인하십시오. 전환을 조용히 유지하려고 이름이나 인증서 확인을 억제하면 일시적인 호환성 문제가 영구적인 문제가 됩니다.

폐기된 자재는 배포가 검증된 후에만 은퇴시키고, 침해된 키는 완전히 다른 사례로 취급하되, 갱신만으로는 아무것도 폐기되지 않으므로 영향을 받은 정체성에는 배포의 폐기 및 세션 처리 절차가 필요합니다.RFC 5280 은 이 모든 것 아래에 있는 인증서 및 경로 검증 규칙을 정의합니다. 일상적인 리프 갱신을 CA 교체와 분리하십시오, 그래야 클라이언트에게 이유 없이 새 발급자를 신뢰하라고 요구하지 않게 됩니다.