서버 인증서 체인이 클라이언트의 신뢰 저장소를 무시할 수 있을까?

브라우저가 체인이 완전한 사이트에서 인증서 경고를 표시하면, 첫 반응은 서버를 고치는 것입니다. 그러나 대개 서버는 마땅히 내놓아야 할 것을 정확히 제시하고 있습니다. 어떤 앵커를 받아들일지는 클라이언트가 정하며, 중간 인증서를 어떻게 배열해도 연결의 반대편에서 그 결정을 바꿀 수 없습니다. 인증서 문제처럼 보이는 것의 대부분은 이 경계로 설명됩니다.

검증은 클라이언트에서, 클라이언트의 앵커로 실행됩니다

경로 검증은 제시된 인증서를 가져와 검증 시스템이 이미 보유한 신뢰 앵커까지 체인을 만듭니다. RFC 5280은 이 모델을 설명하며, 앵커 선택을 서버가 아니라 로컬 구현에 둡니다. 애플리케이션은 그 위에 자체 정책을 더할 수 있습니다. 고정된 키, 기업 신뢰 저장소, 또는 더 엄격한 신원 확인입니다. 서버가 보내는 인증서 목록은 그 프로세스에 제공되는 증거이며, 결코 지시가 아닙니다.

따라서 완전한 체인은 서버에 구성 요소가 있음을 증명합니다. 클라이언트가 그것을 받아들인다는 것은 증명하지 않습니다.

서버가 실제로 무엇을 보내는지 보려면 다음을 실행하고 openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts출력에서 인증서 수를 세십시오. 그곳의 불완전한 체인은 서버 측 수정 사항입니다. 완전한 체인은 질문을 클라이언트와 그 앵커로 옮기며, 그곳에서 서버는 발언권이 없습니다.

TLS 검사가 실제로 바꾸는 것

검사 어플라이언스는 클라이언트 측 TLS 세션을 종료하고 실제 서비스로 별도 세션을 엽니다. 그러면 클라이언트는 어플라이언스의 인증서를 검증하며, 이는 클라이언트가 신뢰하는 앵커까지 이어져야 합니다. 관리 기기가 기기 관리로 검사 루트를 받는 이유이며, 그것이 없는 개인 기기가 경고를 표시하는 이유입니다.

이 배치는 의도적이고 로컬입니다. 원래 서버의 체인에 있는 어떤 것도 관리되지 않는 브라우저가 대체 신원을 받아들이도록 강제할 수 없고, 관리 기기가 그렇게 하는 것을 막지도 않습니다.

VPN 종단은 HTTPS 복호화가 아닙니다

VPN 계층은 클라이언트와 게이트웨이 사이에서 패킷을 운반합니다. 이를 제거하거나 구성을 읽어도 내부의 HTTPS 페이로드가 노출되지 않습니다.

TLS 세션은 여전히 브라우저와 웹 서버 사이에서 같은 검증 규칙으로 실행됩니다. 무언가가 명시적으로 종료하지 않는 한 그렇습니다. 두 계층을 혼동하면 VPN 관리자에게 인증서를 제공하라는 요청이 생기지만, 문제의 인증서는 검사 프록시나 사이트 자체의 것입니다. 신뢰 저장소를 바꾸기 전에 어떤 구성 요소가 인증서를 제시하는지 물어보십시오.

통제하는 구성 요소에서 기대치를 설정하십시오

애플리케이션과 그 클라이언트를 운영한다면 기대하는 서비스 신원, 허용되는 발급자, 고정 또는 클라이언트 인증 요구 사항을 함께 정의하십시오. 정당한 인증서 변경이 중단이 되지 않도록 갱신과 복구를 계획하십시오. 공용 서버만 운영한다면 어떤 인증을 요구하고 어떤 클라이언트 환경을 지원하는지 문서화하십시오. 선호하는 체인을 보내는 것은 낯선 사람의 기기를 인증하지 않습니다.

관리 장비에서는 애플리케이션과 네트워크 소유자를 통해 비호환성을 해결하십시오. 검증을 끄거나, 설명 없는 루트를 추가하거나, 검사 정책을 버티려는 시도는 의도한 피어 관계를 세우지 못합니다.

결과는 예외가 이미 추가된 머신이 아니라 깨끗한 클라이언트 프로필에서 시험하십시오. 새 기기가 무엇을 겪을지 보여 주는 유일한 확인입니다.