TCP라더니 HTTPS?! 예상치 못한 디버깅 여정(feat, openssl TLS인증서 추출방법)

25년 1월에 경험했던 재밌는 디버깅 과정을 공유드립니다.

 

1.   배경

설날전 꼭 디버깅을 했어야 했던 상황이었습니다. 애플리케이션을 호출해야 했었는데 가이드에서는 tcp프로토콜을 사용하라고 되어 있었습니다. 하지만 가이드대로 동작하지 않았습니다.

 

담당자는 휴가 였습니다. 그리고 애플리케이션 소스코드, 메트릭, 로그는 권한이 없어 못보는 상황이었습니다.

 

시간이 많이 없었기 때문에 http 또는 https프로토콜을 사용하여 디버깅을 시작했습니다.

 

http, https모두 안되었지만 https에서는 TLS 핸드쉐이킹 과정에서 서버 인증서 검증에러가 났습니다. 그래서 인증서 검사 무시 옵션을 추가했더니 https통신이 되었습니다. curl에서는 -k옵션이 인증서 무시입니다.

curl -k {엔드포인트}

 

애플리케이션 호출이 되었지만 이게 정말 맞는지 의문이었습니다. 가이드는 tcp프로토콜을 사용하라고 되어 있었고 https를 사용하지만 인증서 검증을 실패했기 때문이죠. 그래서 정말 https 프로토콜을 사용하는게 맞나라는 의심이 들었습니다. 의도한 기능이 아니라 다른 기능을 호출한게 아닐까?라는 생각이 들었습니다.

 

약 20분이상 고민을 하고 있었는데 옆에 있던 동료분이 명쾌한 해답을 주셨습니다. 담당자 또는 소스코드 없이는 분석이 불가능하기 때문에 인증서 추출해서 인증서 검증까지만 하자고 말씀하셨습니다. 당장 확인할 수 없기 때문에 많은 시간을 쓰지 말고 할 수 있는데까지만 하는게 좋겠다고 덧붙여 말씀하셨습니다.

 

그래서 지금 당장 확인할 수 있는 검증하지 못한 인증서 추출 후 확인만 하고 담당자에게 물어보기로 했습니다. 며칠 뒤 담당자에게 문의해본 결과, 애플리케이션을 호출하려면 tcp가 아니라 https를 사용해야한다는 것을 알았습니다.

 

2.  인증서 추출 방법

인증서 추출은 openssl s_client 명령어로 할 수 있습니다. -connect뒤에 엔드포인트 주소를 입력하면 끝입니다.

openssl s_client -connect {엔드포인트} -showcerts

 

아래는 로컬에 nginx를 실행하고 hostname을 myserver.com으로 설정한 예제입니다.

openssl s_client -connect 127.0.0.1:8880 -servername myserver.com -showcerts