MCP 연결에서 인증서 검증 오류가 나면 API 키를 다시 발급하기 전에 접속 이름, 인증서 신뢰 경로, 실행 환경을 나눠 확인한다. HTTPS 인증서 검증과 MCP 도구의 사용 권한은 다른 단계다. 인증서 검증을 꺼서 연결된 상태를 정상 복구로 판단해서는 안 된다.
대상은 원격 MCP 서버에 HTTPS로 연결하는 운영자다. 로컬 stdio 연결은 이 진단의 대상이 아니다. TLS 이름 확인은 RFC 9525, 관측 명령은 OpenSSL 3.5 문서를 기준으로 한다. curl은 설치 버전과 TLS 백엔드에 따라 신뢰 저장소가 달라진다. 공식 문서 확인일은 2026년 10월 16일 한국시간이다. 아래 절차와 사례는 문서 기반 진단 제안이며, 특정 MCP 클라이언트의 장애 재현·복구 실험 결과가 아니다.
인증 실패라는 한 단어를 먼저 나눈다
| 실제 관측 | 먼저 확인할 경계 |
|---|---|
| 서버 인증서 검증 오류 | 접속 이름·신뢰 경로·유효 기간 |
| HTTP 401 또는 403 응답 | 응답을 만든 서비스와 인증·권한 조건 |
| 정상 HTTP 응답 안의 MCP 오류 | 프로토콜 응답과 도구 실행 결과 |
| 연결 시간초과만 관측 | DNS·네트워크·프록시 등. 인증서 문제로 단정 금지 |
오류 문구 전체를 공개 채널에 붙여넣기보다, 비밀정보를 제거한 오류 종류와 발생 단계부터 남긴다. 서버 응답인지 클라이언트 검증기 메시지인지도 구분한다. 중간 프록시가 TLS를 종료하는 구조에서는 어느 연결 구간의 오류인지 추가 확인이 필요하다.
1. 브라우저가 아니라 실패한 실행 환경을 기준으로 잡는다
브라우저에서는 열리는데 에이전트에서 실패한다면 같은 주소라는 이유만으로 같은 조건이라고 볼 수 없다. 에이전트가 실행되는 컨테이너·원격 호스트의 런타임과 신뢰 저장소, 프록시 경로를 기록한다. 브라우저의 저장소와 별도 런타임의 저장소가 같은지 확인하기 전에는 서버 인증서가 정상이라고 결론 내리지 않는다.
curl 공식 문서는 기본 인증서 검증과 플랫폼·TLS 백엔드에 따른 신뢰 저장소 차이를 설명한다. HTTPS 프록시와 원본 서버의 TLS 연결도 별도로 검증된다. 따라서 curl 결과는 curl이 사용한 조건의 증거이지, 다른 SDK의 인증서 검증 결과를 대신하지 않는다. curl 인증서 검증 문서
관측 시각 / 시간대:
실패한 앱·SDK·런타임 버전:
실제 실행 위치와 OS:
접속 호스트 / 포트:
프록시 사용 여부와 승인된 경로:
인증서 검증 오류 종류:
사용한 신뢰 저장소의 관리 주체:
동일 조건에서 비교한 결과:이 양식은 운영자가 권한 안에서 작성할 관측 기록이다. 토큰, 쿠키, 클라이언트 개인키는 넣지 않는다. 내부 호스트 이름이나 조직 정보가 포함된 인증서 출력도 외부 공유 전에 검토한다.
2. 이름 불일치와 신뢰 실패를 구분한다
RFC 9525는 서버의 이름을 인증서의 적절한 subjectAltName 식별자와 대조하도록 규정한다. 도메인으로 접속할 때와 IP 주소로 접속할 때의 대조 대상은 다르다. 인증서 화면에 익숙한 조직 이름이 보인다는 사실만으로 접속한 호스트의 신원이 확인되지는 않는다. RFC 9525: TLS 서비스 신원 확인
가상 사례 A. 설정에는 mcp.example.com이 필요한데 접속 테스트에서 서버 IP를 직접 사용했다. 이때 이름 불일치는 API 키 문제가 아니다. 운영자가 제공한 공식 엔드포인트를 확인하고 인증서의 대상 이름과 대조한다. 이름 검사를 끄거나 임의의 다른 호스트로 인증값을 보내는 방식은 해결책이 아니다.
가상 사례 B. 같은 공식 주소가 브라우저에서는 열리지만 컨테이너에서 신뢰 경로 오류로 실패한다. 서버가 보내는 중간 인증서 목록과 컨테이너의 신뢰 저장소를 각각 조사한다. 오류 하나만으로 중간 인증서 누락인지, 필요한 CA가 없는지, 다른 경로에서 인증서를 받은 것인지 확정할 수 없다. 승인된 관리 주체가 확인한 인증서만 검토 대상으로 삼는다.
3. 인증서 출력과 검증 성공은 다르다
아래는 OpenSSL 3.5 문서에 근거한 POSIX 셸용 관측 예시다. 예시 도메인은 실제 MCP 서버가 아니다. 소유하거나 진단 권한이 있는 서버의 승인된 호스트로 바꿔 사용한다. 기존 네트워크 정책상 직접 연결이 허용되지 않는다면 이 명령으로 프록시를 우회하지 않는다. 도구가 없다면 새로 설치하기보다 담당자가 제공하는 관측 결과를 요청한다.
openssl version
openssl s_client \
-connect mcp.example.com:443 \
-servername mcp.example.com \
-verify_hostname mcp.example.com \
-verify_return_error \
-showcerts </dev/null-servername은 SNI로 서버 이름을 전달하는 옵션이고, -verify_hostname은 인증서의 이름을 대조하는 옵션이다. 역할이 같지 않다. -verify_return_error는 검증 오류가 있어도 계속 진행하는 시험 도구의 동작을 바꾼다. -showcerts는 서버가 전송한 인증서 목록을 보여줄 뿐, 검증된 신뢰 체인을 출력한다는 뜻이 아니다. OpenSSL 3.5 s_client 문서
이 예시처럼 표준입력을 바로 닫으면 TLS 1.3 등의 비대화형 연결에서 조기 종료가 나타날 수 있다. 종료 오류만으로 인증서 검증 실패를 단정하지 말고 검증 메시지를 구분한다. 이를 피하려고 -ign_eof를 무작정 추가하면 서버의 응답을 계속 기다릴 수 있으므로, 실행 도구와 종료 조건을 함께 검토한다.
종료 코드와 검증 메시지, 검사한 이름을 함께 읽는다. 출력에 인증서가 나왔거나 소켓이 연결됐다는 사실만 따로 떼어 성공으로 기록하지 않는다. 이 명령은 MCP 요청을 실행하지 않으므로, 여기서 인증서 검증이 통과해도 도구 목록 조회나 도구 사용 권한까지 확인된 것은 아니다. 또한 명령의 신뢰 저장소와 실제 앱의 신뢰 저장소가 다르면 두 결과를 직접 등치할 수 없다.
4. 수정 권한과 완료 조건을 분리한다
접속 이름이 잘못됐다면 승인된 공식 주소를 확인한다. 서버의 체인 구성이 문제라면 서버 관리자가 수정하고, 실행 환경의 신뢰 구성이 문제라면 해당 환경 관리자가 검토한다. 인증서 유효 기간 오류가 보이면 유효 기간과 해당 실행 환경의 현재 시각을 함께 확인한다. 오류를 없애려고 시간을 임의로 바꾸거나 검증 자체를 비활성화하지 않는다.
CA 추가는 단순한 문장 수정이 아니라 신뢰 대상을 바꾸는 작업이다. 출처가 불명확한 인증서를 내려받아 전역 저장소에 넣지 않는다. 조직의 TLS 검사 장비가 관련돼 있다면 인증서 배포 정책과 적용 범위를 담당자에게 확인한다. 이 글은 신뢰 저장소 변경이나 보안 경고 우회를 승인하는 절차가 아니다.
완료 확인 순서: 실패했던 실제 실행 환경에서 인증서 검증을 유지한 채 같은 호스트에 연결되는지 확인한다. 그다음 허용된 읽기 요청으로 MCP 응답을 확인한다. 마지막으로 변경한 항목과 검증 범위를 기록한다. 이전 쓰기 요청의 실행 여부가 불명확하다면 연결이 회복됐다는 이유로 다시 보내지 말고 대상 상태부터 읽는다.
다음 진단으로 넘어갈 기준
인증서 검증이 통과한 뒤 HTTP 상태가 돌아오기 시작하면 조사 단계가 달라진 것이다. 415의 콘텐츠 형식 진단이나 리디렉션과 요청 메서드 진단을 해당 응답에 맞춰 적용한다. 인증서 문제가 해결됐다는 판단과 MCP 작업 전체가 성공했다는 판단을 따로 남겨야, 다음 오류를 같은 문제로 되풀이하지 않는다.