Go 빌드, Composer 설치, Python 클라이언트가 모두 집에서는 동작하고 회사 VPN 안에서는 모두 실패합니다. 이 패턴은 애플리케이션이 아니라 경로에 대해 말해 줍니다. 터널 위의 무언가가 프로세스가 보는 인증서 체인을 바꾸었거나, 체인이 도착하기도 전에 핸드셰이크를 재설정했습니다. 두 장애는 터미널에서 비슷해 보이지만 전혀 다른 대응을 요구합니다.

세 가지 메시지, 세 가지 원리

x509 certificate signed by unknown authority 오류는 체인이 만들어졌지만 그 루트가 해당 프로세스가 쓰는 신뢰 저장소에 없다는 뜻입니다. self-signed certificate in certificate chain 오류는 보통 검사 프록시가 자기 인증서로 응답했다는 뜻이고, 그것은 런타임이 인식하지 못하는 체인입니다. 핸드셰이크 중의 SSL EOF는 쓸 만한 인증서가 전송되기 전에 연결이 닫혔다는 뜻이며, 이는 ClientHello를 거부하는 중간 장비이고 신뢰 문제가 전혀 아닙니다.

안전하지 않음 플래그를 더하면 세 메시지가 모두 사라지지만 가로채기는 그대로 남고, 실제 공격자를 잡을 검증까지 없애 버립니다.

그 프로세스가 실제로 읽는 번들을 찾으세요

Windows 저장소에 설치한 회사 루트는 시스템 저장소를 참조하는 브라우저와 .NET 응용 프로그램을 고칩니다. 자체 CA 번들을 지닌 컨테이너 안에서 도는 빌드에는 아무 효과가 없고, certifi를 쓰는 Python 프로세스나 자체 포함 목록을 쓰는 Node 프로세스에도 효과가 없습니다. Go는 바이너리가 도는 환경의 시스템 풀을 읽으므로 컨테이너를 보고, 노트북을 보지 않습니다. 그래서 한 대의 기계가 동작하는 브라우저와 실패하는 빌드 도구를 동시에 만들어 냅니다.

가정하지 말고 도구에 물어보세요. python3 -c "import ssl; print(ssl.get_default_verify_paths())"는 Python이 참조할 파일을 출력하고, node -e "console.log(process.env.NODE_EXTRA_CA_CERTS)"는 재정의가 이미 설정되었는지 보여 줍니다. 컨테이너라면 빌드가 실제로 쓰는 환경인 이미지 안에서 같은 점검을 실행하세요.

빌드가 도는 곳에 루트 하나를 설치하세요

검사 루트를 IT에서 PEM 파일로 받고, 신뢰하기 전에 별도 경로로 지문을 확인하세요. Debian 계열 이미지에서는 /usr/local/share/ca-certificates/로 복사하고 update-ca-certificates를 실행하고, RHEL 계열 이미지는 파일을 /etc/pki/ca-trust/source/anchors/에 넣은 뒤 update-ca-trust를 씁니다. 컨테이너 빌드에서는 실패하는 명령 앞에 이 단계를 넣어 계층이 의존성 설치 위에 캐시되게 하세요.

로컬 devcontainer라면 개인 이미지에 구워 넣어 남이 재현할 수 없게 만드는 대신 PEM을 마운트하고 시작할 때 같은 갱신 명령을 실행하세요. 자체 번들을 함께 배포하는 도구에는 각자의 문서화된 재정의가 필요한데, pip에는 인증서 설정이, npm에는 cafile 설정이 있고, 나머지 대부분은 표준 환경 변수를 받아들입니다.

어떤 인증서든 받아들이는 것과는 다릅니다. 검사를 수행하는 쪽에서 받은 특정 루트 하나를 한 환경에 더하는 것이고, 다른 모든 체인에는 검증이 켜진 채로 남습니다. 검사 루트도 다른 CA처럼 갱신되므로 어떤 파일을 언제 추가했고 언제 만료되는지 적어 두세요.

인증서보다 먼저 핸드셰이크가 죽을 때

아무것도 제시되지 않으면 신뢰 저장소를 바꿔도 소용없습니다. 같은 요청을 터널이 켜진 상태와 꺼진 상태로 비교하고, 다음으로 openssl s_client -connect host:443 -servername host -showcerts로 체인을 직접 확인하세요. VPN 밖에서는 완료되고 안에서는 재설정되는 연결은 중간 장비의 정책 결정이며, 해법은 다른 인증서가 아니라 그 호스트에 대한 예외입니다. 패키지 레지스트리나 API 엔드포인트를 변형 없이 통과시켜 달라고 요청하세요.

도구가 VPN을 우회하도록 터널을 나누면 그 트래픽의 검사를 피할 수 있지만, 정책을 위반할 수 있고 도구가 신뢰할 만해지는 것도 아닙니다.

도구별로 결과를 적어 두세요

바이너리, 그것이 읽는 신뢰 파일, 관련된 환경 변수, 승인된 예외를 나열한 짧은 메모는 다음 사람의 진단 전체를 아껴 줍니다. 바뀐 것이 노트북인 경우는 드물기 때문에 메모는 노트북별이 아니라 도구별로 유지하세요.

그리고 티켓에는 특정 회사 루트를 설치했다는 것과 검증을 껐다는 것, 두 문장을 따로 두세요. 지원 조치인 것은 둘 중 하나뿐입니다.

관련 글