갱신된 VPN 인증서: 일부 클라이언트는 여전히 거부한다

갱신 후 환경의 절반은 다시 연결되지만 세 기기는 거부하며, 각각 게이트웨이의 신원에 관한 경고를 띄운다. 갱신 자체는 일상적인 작업이다. 그 세 기기가 들고 있는 것은 이전 객체에 대한 핀이며, 핀은 CA 목록도, 이름 검사도, 트러스트 스토어 항목도 아니다. 어떤 클라이언트를 건드리기 전에 세 가지 메커니즘을 비교하라.

하나의 갱신, 두 가지 행동

다시 연결되는 클라이언트는 신뢰 판단이 아직 통과되지만, 거부하는 클라이언트에는 새 인증서가 충족하지 못하는 요구가 있다. 그 차이는 정보이지 잡음이 아니다. 실패한 클라이언트의 메시지를 정확히 읽어라. 이름 불일치, 알 수 없는 발급자, 바뀐 지문은 세 가지 다른 판정이며, 마지막 것만 핀을 가리킨다.

실패한 클라이언트가 어떤 프로필을 골랐는지도 확인하라. 자체 저장소에 사는 가져온 사본은 관리자가 다른 곳에서 원본 파일을 편집해도 바뀌지 않는다.

갱신은 날짜만이 아니라 객체를 바꾼다

지문은 인코딩된 인증서 내용을 식별한다. 갱신은 새 인증서를 만들므로 주체 이름과 공개 키가 같아도 지문은 바뀐다. CA를 신뢰하고 이름을 검증하는 클라이언트에는 예상된 일이며 무해하다. 정확히 하나의 인증서만 받도록 설정된 클라이언트에는 치명적이며, 트러스트 스토어가 새 발급자를 받은 적 없는 클라이언트에도 치명적이다.

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

두 번째 줄은 키 쌍이 살아남았는가라는 다른 질문에 답한다. 키를 재사용하는 갱신은 그 값을 유지하고 인증서만 바꾸며, 바로 그 지점에서 관리자는 아무것도 바뀌지 않았다고 가정하고 싶어진다. 빌드 호스트에 있는 것이 아니라 배포된 인증서를 점검하라. 저장소의 파일을 비교하면 무엇이 생성되었는지는 증명되지만, 리스너가 지금 무엇을 제시하는지는 증명되지 않는다.

클라이언트가 무엇을 고정하는지 읽어라

일부 클라이언트는 프로필에 지문을 보관하고 연결할 때마다 비교한다. 다른 클라이언트는 플랫폼 트러스트 스토어에 저장하고, 또 다른 클라이언트는 CA만 신뢰한다. 수리는 경우마다 다르므로 먼저 메커니즘을 식별하라.

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

첫 명령은 전통적인 프로필의 핀을 보여 주고, 둘째는 엔드포인트가 지금 실제로 제공하는 지문을 보여 준다. 둘이 다르면 추측 없이 장애를 찾은 것이다. 불평하는 모든 클라이언트에 새 값을 붙여 넣지 마라. 발급자 때문에 거부하는 클라이언트는 계속 거부할 것이고, 문제가 지문이 아니었는데도 지문이 문제였다고 스스로를 설득하게 될 것이다.

각 백엔드가 제공하는 인증서를 비교하라

간헐적인 결과는 보통 여러 엔드포인트를 뜻하며, 한 노드에만 적용된 갱신은 나머지가 이전 객체를 제시하게 남긴다. 각 백엔드를 공유 이름이 아니라 주소로 비교하라.

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

한 노드가 뒤처진 풀은 두 번째 시도에서 연결되고 첫 번째에서 실패하는 클라이언트를 설명한다. 사용자가 불평하는 동안 모니터링 검사가 통과하는 것도 설명한다. 먼저 지연을 고쳐라. 모든 노드가 새 인증서를 제공하기 전에 신뢰 구성을 롤링하면 아무것도 작동하지 않는 창이 생기고, 그 뒤에 롤링하면 클라이언트가 예측할 수 없이 실패한다.

관리되는 경로로 신뢰를 바꿔라

어디서든 받아들이기 전에 이미 신뢰된 관리 채널을 통해 교체를 확인하라. 그럴듯한 만료 날짜는 소유의 증거가 아니다. 관리되는 구성을 그것을 소유한 프로세스로 갱신하고, 허용 가능한 신원의 계획된 중첩을 두며, 배포가 요구하는 이름 검증을 유지하라. 이름 검사 없는 핀은 그것이 대체한 CA 신뢰보다 약한 설계다.

그다음 클라이언트별로 연결하고, 받아들인 신원을 확인하고, 이제 신뢰하는 인증서 버전을 기록하라. 한 번 물리친 경고는 다음 갱신에서 돌아오는 습성이 있다.