인증서를 교체한 뒤 OpenConnect가 게이트웨이를 거부하는 이유는 무엇인가?

게이트웨이는 인증서를 교체하고, 어제까지 연결되던 클라이언트가 첫 TLS 교환에서 멈추기 시작한다. 메시지는 네트워크 결함이 아니라 검증 사유를 말하며, 머신 자체는 바뀌지 않았고 이것이 유용한 단서다. 깨진 것은 지금 제시된 인증서와 클라이언트가 받아들일 의사가 있는 루트 사이의 관계다. 이를 고치는 것은 신뢰 결정이므로, 옵션을 입력하기 전에 그 결정을 내려라.

신뢰 설정을 바꾸기 전에 실패를 읽어라

서명자가 없다는 식의 오류는 체인이 클라이언트가 받아들이지 않는 무언가에서 끝난다는 뜻이다. 내부 기관이 갱신한 인증서, 공개 기관의 교체본, 또는 중간에서 자체 인증서를 제시하는 장치일 수 있다. 문구만으로는 그 경우를 구분할 수 없다, 그러므로 결정하기 전에 발급자를 보라.

연결을 한 번 전면에서 실행해 실패하게 두라, 대화형 출력에 서버 이름, 발급자 체인, 클라이언트가 계산한 지문이 담기기 때문이다. 그 발급자를 조직이 실제로 운영하는 기관과 비교하라. 지문은 바뀌었는데 발급자는 그렇지 않다면, 이미 신뢰하는 경로로 갱신이 확인될 때까지 의심스럽게 다뤄라. 이 시점의 추측이 결국 누군가 가로채는 자의 키를 고정하게 만드는 길이다.

같은 메모에 클라이언트 버전을 적어라. 신뢰 문제처럼 보이는 실패의 상당 부분은 더 오래된 클라이언트가 더 새로운 게이트웨이 교환을 만나서 생긴다.

발급자를 신뢰하는 것과 하나의 키를 고정하는 것 중에서 고르라

두 선택 모두 연결을 성공시킨다. 나중에 서로 반대 방식으로 깨지므로, 선택은 감당할 수 있는 실패에 달려 있다.

인증서가 독립적으로 검증할 수 있는 기관에서 온다면, 갱신이 클라이언트 인수를 건드리지 않고 계속 작동하므로 CA 파일을 택하라. 시스템 루트를 끄는 스위치와 함께 쓰라, 그렇지 않으면 공개 기관이 당신 대신 검사를 충족할 수 있다. 대신 게이트웨이에 얻을 수 있는 CA가 없거나 가능한 가장 좁은 예외가 목표라면 고정하라. 어느 길도 추상적으로 더 안전하지 않다, CA는 갱신 전반으로 확장되고 고정은 검토하기 쉽기 때문이다.

어느 쪽을 고르든 신뢰하는 값은 변경 전에 신뢰하던 경로로 도착해야 한다. 관리자, 게이트웨이의 콘솔 세션, 미리 떠 둔 사본 모두 자격이 있다. 프롬프트가 보여 주는 지문을 그대로 복사하는 것은 편리하며 가로채는 자가 바라는 바로 그것이다.

실제로 실행하는 명령에 값을 넣어라

고정은 서버 인증서 옵션으로 전달되고 접두사가 인코딩을 정한다: sha1 또는 sha256 아래의 십육진 공개 키 다이제스트, 그리고 pin-sha256 아래의 base64 키 고정이다. 이를 주면 해당 실행에서 시스템 신뢰도 꺼지므로, 고정한 키가 결정 전부가 된다.

sudo openconnect --protocol=gp vpn.example.com --user alice \
  --servercert pin-sha256:AbCdEf...   # single key pin
sudo openconnect vpn.example.com --cafile /etc/ssl/internal-ca.pem --no-system-trust

클라이언트는 잘린 다이제스트를 맞추며, 접두사 뒤 네 글자만으로도 받아들이는데, 이는 편의가 아니라 함정이다. 줄인 값은 로컬에서 통과하고도 의도한 게이트웨이를 식별하지 못한다. 메시지에서 다시 입력하지 말고 클라이언트가 첫 시도에서 출력한 전체 문자열을 복사하라. 그런 다음 완성된 옵션을 연결을 시작하는 래퍼 스크립트, 유닛 파일, 프로필로 옮겨, 신뢰 결정을 검토할 수 있게 하고 이후 편집을 의도적으로 하라.

데스크톱 실행기와 NetworkManager 플러그인은 연결 인수의 자체 사본을 저장한다. 디스크에서 편집한 스크립트는 앞서 가져온 프로필에 닿지 않으므로 저장된 값이 계속 이긴다.

스스로 잠기지 않고 교체를 처리하라

옵션은 여러 번 줄 수 있으므로 계획된 변경은 나가는 키와 들어오는 키를 함께 받아들일 수 있다. 게이트웨이가 바뀌기 전에 새 고정을 추가하고, 세션이 옮겨 가는 동안 둘 다 나열하며, 옛 키가 사라지면 은퇴한 쪽을 뺀다. 그 창에는 소유자가 필요하다, 잊힌 이중 고정은 아무도 지켜보지 않는 키를 신뢰된 상태로 남기기 때문이다. 새 키 쌍을 만드는 재구축은 순수 고정을 깨고, 복구는 반대 방향의 같은 절차다.

변경 날짜를 고정 옆에 적어라. 검토 날짜가 없는 고정은 혼란스러운 오류 메시지를 동반한 미래의 장애다.

신뢰를 편집하기 전에 클라이언트 버전을 배제하라

오래된 클라이언트는 게이트웨이가 그 뒤 변경한 인증 응답을 파싱하다 실패할 수 있고, 표면 메시지는 여전히 파서가 아니라 연결을 말한다. 설치된 버전을 게이트웨이가 문서화한 것과 비교하고, 어떤 신뢰 설정을 바꾸기 전에 일회용 프로필에서 현재 패키지를 시험하라.

openconnect --version

복구 후에는 하나가 아니라 두 가지를 확인하라: 포털이 터널을 통해 로드되고, 평범한 내부 주소가 응답해야 한다. 완료된 핸드셰이크는 신뢰 결정이 받아들여졌다는 것만 증명한다.