SSL 인증서 CA를 잘 선택해야 하는 이유

애플 웹훅 설정 중 발생한 이슈와 원인 분석

애플 ID 회원 탈퇴 등의 이벤트가 발생하면, 우리 서비스로 HTTP 요청을 보내는 기능을 제공한다(웹훅).
apple2ourserver

이를 활용하면, 애플 ID 탈퇴 시 우리 서비스 계정도 자동으로 휴면 처리하는 기능을 구현할 수 있다.

문제 상황

애플 대시보드에서 웹훅 엔드포인트만 설정하면 간단히 끝날 줄 알았다.
하지만 웹훅 요청이 전혀 수신되지 않았다.

특이한 점은 ngrok이나 웹훅 테스트 사이트에는 정상적으로 요청이 수신된다는 것이다.
apple2otherserver

WAF와 화이트리스트(17.0.0.0/8) 설정은 정상임을 확인했다.

무슨 차이가 있을까?

우리 API 서버와 웹훅 테스트 서비스는 어떤 차이가 있길래 통신이 되지 않았을까?
SSL 문제일 가능성을 의심해 SSL 체크 사이트에서 확인했다.

눈에 띄는 점은 Trusted 항목에서 Java가 빨간색으로 표시되었다는 것이다.
sslchecker_trusted

결국 문제의 원인은 여기서 비롯되었다.

SSL 통신 과정 이해

Trusted란 클라이언트가 해당 서버 인증서를 신뢰할 수 있는지를 나타내는 상태이다.
이를 이해하기 위해 SSL 통신 과정을 단계별로 정리했다.

1. 준비 단계

ssl_step1

  1. CA는 비대칭 키(공개키/비밀키)를 생성한다.
  2. 클라이언트는 신뢰할 수 있는 CA 목록을 관리한다.
    • OS, Mozilla, Java 등에서 관리하는 Trust Store가 다를 수 있다.

2. 인증서 발급 및 설정 단계

ssl_step2

  1. 서버는 비대칭 키를 생성하고, 서버 공개키를 CA에 전달한다.
  2. CA는 서버 공개키를 해시한 뒤, 자신의 비밀키로 서명하여 인증서를 발급한다.
  3. 서버는 CA가 발급한 인증서를 설정한다.

여기서 CA 서명(CA Signature)이란 "CA가 서버 공개키를 검증 후 서명한 값"을 의미한다.

3. 클라이언트-서버 통신 단계

ssl_step3

  1. 클라이언트가 서버에 SSL 연결을 요청한다.
  2. 서버는 인증서를 클라이언트에게 전달한다.
  3. 클라이언트는 인증서의 CA 서명을 검증한다.
    • 이때 클라이언트는 자신의 Trust Store에 저장된 CA 공개키를 사용한다.
  4. 검증이 완료되면, 양측은 통신에 사용할 대칭키를 교환한다.
  5. 대칭키로 데이터를 암호화하여 요청/응답을 주고받는다.

비대칭키는 공개키로 암호화한 데이터를 개인키로, 개인키로 암호화한 데이터를 공개키로 복호화할 수 있다.

통신 오류 원인

내가 사용한 인증서 CA는 Java Trust Store에 포함되지 않았다.
애플 웹훅 클라이언트는 Java로 개발되었으며, Java에서 신뢰하지 않는 CA로 SSL 연결 시 오류가 발생했다.

즉, Java 클라이언트 입장에서는 우리 서버 인증서를 신뢰할 수 없는 상태였던 것이다.

요약

  1. CA 선택에 따라 일부 클라이언트가 인증서를 신뢰하지 않을 수 있다.
  2. 이번 사례에서는 한국전자인증의 TuringSign 공개키가 Java에 내장되지 않아 통신 오류가 발생했다.
  3. Java 환경을 포함한 글로벌 서비스와 통신할 가능성이 있다면, Digicert나 Let's Encrypt 같은 널리 사용되는 CA를 선택하는 것이 안전하다.
    • 참고로 Let's Encrypt는 무료로 사용 가능하다.