HTTPS 통신과정 쉽게 이해하기 (CA, 인증기관)

https://aws-hyoh.tistory.com/59

HTTPS 통신과정 쉽게 이해하기 #5(CA, 인증기관)

 

CA(Certificate Authority, 인증기관)

이전 문서에서 브라우저가 접속하고자 하는 서버의 SSL 인증서를 받으면 이것이 진짜인지 가짜인지 검증하기 위해 인증기관(CA)에 요청한다고 말씀드린 것을 기억하시나요? 이 인증기관은 단 하나만 존재하는 것일까요?

<인증기관의 역할(출처 : www.n3ncloud.co.kr)>

하나의 인증기관만이 존재하여 모든 요청을 처리하게 된다고 생각해봅시다. 그럴 일은 없겠지만 인증기관이 여러분이 만든 인증서를 암호화할 때 사용한 인증기관의 개인키를 탈취당한다면 어떻게 될까요? 인증기관이 하나뿐이므로 모든 SSL 인증서가 위험에 노출됩니다. 그러나 누구나 신뢰할 수 있는 최상위 인증기관 아래 다수의 중간 인증기관을 두고 그 인증기관들이 SSL 인증서 생성을 요청한다면? 중간 인증기관 하나에 문제가 생기더라도 다른 중간 인증기관을 사용하는 SSL 인증서들은 문제가 없을 것입니다. 그래서일까요? CA는 사실 3계층 혹은 2계층 구조의 형태를 띄고 있습니다.  

 

1. Root CA(최상위 기관)

2. Intermediate CA(중간 기관)

 

계층 구조의 가장 위에는 모두가 신뢰하기로 합의한 최상위 인증기관인 Root CA가 존재합니다. 그리고 그 아래에는 중간 기관인 Intermediate CA가 존재하지요. 이런 계층 구조라면 서버가 요청하는 SSL 인증서 생성을 어떻게 처리하는 것일까요? 지난 문서에서 설명한 것을 다시 이야기해보겠습니다.

<인증기관의 계층 구조(출처 : 위키백과)>

여러분이 SSL 인증서를 생성하기 위해 서버의 각종 정보와 공개키를 Intermediate CA에 제출합니다. 그러면 Intermediate CA는 서버가 제출한 각종 정보를 Intermediate CA의 개인키로 암호화(서명)합니다. 그런데 모두가 신뢰하기로 합의한 Root CA가 아닌 Intermediate CA가 서명한 인증서를 어떻게 신뢰할 수 있겠습니까? 그래서 Intermediate CA도 중간기관에 불과하기 때문에 상위 기관의 검증을 받게 됩니다. Intermediate CA는 자신의 공개키를 상위 기관(상위 Intermeidate CA)에 제출하면 상위 기관이 인증서를 생성하고 암호화(서명)합니다. 그리고 그 위의 상위 기관 또한 자신의 공개키를 Root CA에 제출하고 Root CA가 인증서를 생성하고 암호화(서명)합니다. 마지막으로 Root CA는 스스로 인증서를 생성하고 자신이 암호화(서명)합니다. 그 인증서들의 나열을 직접 확인해보면 다음과 같습니다. 

 

<네트워크 엔지니어 환영의 AWS 기술블로그 인증서>

 

짜잔~ 제 블로그의 SSL 인증서(*.tistory.com)의 상위 인증서들(G1,G2)과 Root CA(VeriSign)이 나타나있습니다. 위에서 언급한 것처럼 제 블로그는 Intermediate CA에게서 검증을 받고, Intermediate CA들은 Root CA에게 검증받으며, Root CA는 스스로를 검증합니다. 이러한 인증서의 나열을 나타낸 것이 Certificate Chain(인증서 체인)입니다.

 

인증서 체인은 왜 필요한 것일까요? 만약 Client가 Server의 인증서를 가져오는 과정에서 해커가 개입하여 인증서를 가로채고 자신의 인증서를 보냈다고 가정해봅시다. 해커가 보낸 인증서, 공개키, Root CA 등은 모두 해커가 만든 것이기 때문에 인증서를 확인하는 과정에 전혀 문제가 없게 됩니다. 해커가 보낸 공개키로 인증서가 복호화될테고 또 인증서 서명(지문) 또한 변조되지 않았을테니 정상이니 말입니다.(전자서명, 지문에 대해서는 깊게 설명하지 않겠습니다.) 사용자는 해당 진짜 인증서라고 착각할 수 있게 만듭니다. 그래서 이 인증서가 해커가 아닌 올바른 Intermediate CA, Root CA를 가리키고 있다고 증명하는 Certificate Chain이 필요한 것입니다. 해커가 만든 Root CA, Intermediate CA가 아니라 신뢰할 수 있는 인증기관을 말입니다.

 

 

<인증서 서명과 검증 과정>

 

Browser(브라우저)

단도직입적으로 말하면 브라우저는 인증서를 발급한 주요 인증기관의 리스트와 공개키를 이미 보유하고 있습니다. 그러므로 서버의 인증서를 요청하여 검증할 때마다 직접 인증기관으로 가는 것이 아닌 해당 인증서가 자신이 보유한 인증기관의 리스트 중 하나일 경우 이미 갖고 있는 공개키를 이용하여 인증서를 복호화합니다. 그렇다면 자신이 가지고 있지 않은 인증기관의 공개키라면 어떻게 할까요? 이럴 경우 외부 인터넷으로 나아가 인증기관 관련 정보와 공개키를 확보합니다. 그래서 SSL 인증서를 사용할 때 최소한의 인터넷 접속이 필요한 이유가 이런 이유 때문입니다.

 

네트워크를 운영하시는 분이라면 가끔 인프라망의 트래픽 조절을 위해 일부 대역을 차단했는데, 사용자로부터 몇몇 사이트 접속시 신뢰할 수 없는 사이트라 뜬다는 문의 전화를 받아본 적이 있으실 겁니다. 모든 경우는 아니지만 브라우저가 갖고 있는 않은 CA 리스트, 공개키를 확보하기 위해 가는 목적지의 IP가 차단되어 발생하는 경우가 종종 있으니 참고하시면 좋을 것 같다는 생각이 드네요.