SSL/TLS 시스템의 주도권은 브라우저에게 있다

SSL 인증서, 너 정체가 뭐야!

Window 웹 서버를 구축하며 SSL 인증서를 발급하고 설정하는 업무를 맡게 되었습니다.

사실 가이드에 따라 인증서 파일을 서버에 업로드하고 경로를 맞추는 것은 그리 어려운 일이 아닙니다.

하지만 가끔 그 가이드 속 '간단한 한 줄'이 머릿속에서 명쾌하게 해석되지 않아 발걸음을 멈추게 될 때가 있습니다.

이번에 저를 고민에 빠뜨린 문장은 바로 이것이었습니다.

"로컬 테스트를 위해 Hosts를 설정해야 합니다."

• 단순히 서버에 파일을 올리면 끝나는 게 아닌가?
• Hosts를 수정한다는 게 뭐지?
• 도메인에 대해 인증을 받는다는 건 정확히 무엇을 의미할까?
• 인증은 대체 서버 내부에서 어떻게 처리되는 걸까?

질문이 꼬리에 꼬리를 물면서, 제가 그동안 인증서 시스템의 본질을 정확히 이해하지 못하고 있었다는 사실을 깨달았습니다.

기초적인 내용이지만 놓치기 쉬운, 인증서 시스템의 진짜 주인공과 그 동작 원리에 대해 제대로 정리해 보았습니다.

인증서의 본질 - 신뢰를 담은 디지털 보증서

인증서(SSL/TLS Certificate)가 없어도 기술적으로 데이터를 암호화해서 통신하는 것은 가능합니다. 즉, 단순히 암호화 그 자체를 위해 인증서가 꼭 필요한 것은 아닙니다.

SSL 인증서는 기술적인 암호화 도구라기보다, 웹사이트라는 공간의 안전함을 증명하는 '보증서'에 가깝습니다.

신분증에 사진과 이름이 박혀 있듯, 인증서에는 서버의 신원 정보와 함께 누구나 볼 수 있는 공개키(Public Key)가 포함되어 있습니다.

실제 데이터를 열고 처리하는 것은 서버가 금고 깊숙이 숨겨둔 '비밀키'의 몫이지만, 브라우저가 그 서버를 믿고 대화를 시작하려면 먼저 이 보증서를 확인해야 합니다.

즉, 인증서는 브라우저에게 다음과 같이 증명합니다.

"나는 공인된 myonee.com이 맞으니, 이 보증서에 적힌 공개키로 암호를 잠가서 나에게 던져줘."

이는 중요한 금괴(사용자 정보)를 전달하기 전에, 그 금고가 놓인 방(서버)이 정말 믿을 만한 곳인지 보증서를 통해 먼저 확인하는 과정과 같습니다.

보증서에 적힌 주소와 내가 찾아온 방의 이름이 다르면, 아무리 튼튼한 금고가 있어도 금괴를 맡길 수는 없으니까요.

서버는 증명하고, 클라이언트는 의심한다

HTTPS 통신의 주인공은 서버가 아니라 우리가 매일 쓰는 브라우저입니다.
브라우저는 서버를 절대 그냥 믿지 않습니다. 서버가 인증서를 내밀면 브라우저는 다음 3가지를 빠르게 검증하며 심사를 시작합니다.

1. 도메인 대조: "신분증에 적힌 이름이 내가 주소창에 친 주소(myonee.com)와 똑같은가?"

2. 발급처 확인: "이 신분증을 발급해 준 기관(CA)이 내가 신뢰하는 기관 목록에 있는가?"

3. 유효 기간 확인: "이 신분증, 혹시 기한이 지나지는 않았는가?"

결국 인증서는 클라이언트가 서버를 심사하기 위해 존재하는 것입니다. 이 깐깐한 브라우저의 심사를 모두 통과해야만 우리 눈에 익숙한 '자물쇠 아이콘'이 비로소 나타납니다.

특정 주소에 대해 인증서를 발급받는다는 것은,
"내가 접속한 이 주소가 믿을 만한 곳이다"라는 사실을 브라우저에게 증명하기 위한 일련의 과정인 셈입니다.

이제 인증서가 어떤 것인지는 이해했습니다. 그럼 이 인증서를 발급받고 어떻게 로컬에서 테스트할 수 있을까요?

Host와 SNI

실제 서비스 중인 서버에 테스트 인증서를 밀어 넣고 실험해 볼 수는 없는 노릇입니다. 그렇다면 브라우저를 어떻게 내 PC에 설치된 서버로 오게 만들 수 있을까요?

① 접속 가로채기: hosts 파일 설정
브라우저가 외부 DNS(전화번호부)에 물어보러 나가기 전, 내 PC 내부의 hosts 파일을 먼저 보게 만듭니다.

127.0.0.1 myonee.com이라고 적는 순간, 브라우저는 외부 서버가 아닌
내 로컬 서버(localhost)를 해당 도메인으로 인식하고 접속합니다.

② 신분증 골라주기: SNI (Server Name Indication)
내 로컬 서버에 도착한 브라우저는 요청합니다.
"나 myonee.com 찾아왔으니 보증서 보여줘!"

이때 서버가 여러 도메인을 운영 중이라면 SNI 기술을 통해 브라우저가 부른 이름을 확인하고, 그에 딱 맞는 인증서를 꺼내줍니다.

인증서는 클라이언트가 검증하는 것

정리하자면, 우리가 로컬 환경에서 굳이 hosts 파일을 건드려가며 이름을 맞추려 했던 이유는 명확해집니다.

아무리 서버에 완벽한 인증서를 설치했더라도, 브라우저가 보기에
"내가 부른 이름(URL)"과 "서버가 내민 신분증(인증서)의 이름"이 다르면 그 신뢰는 성립될 수 없기 때문입니다.

브라우저는 서버의 IP 주소가 무엇인지에는 관심이 없습니다. 오직 자신이 요청한 그 '도메인'이 보증서와 일치하는지만을 집요하게 따질 뿐입니다.

결국 SSL/TLS 설정의 핵심은 단순히 파일을 서버에 올리는 기술적인 작업에 그치지 않습니다. 그것은 클라이언트가 의심 없이 우리 서버와 대화를 시작할 수 있도록, 약속된 이름을 확인시켜 주는 '신뢰의 인터페이스'를 구축하는 과정입니다.

이제 "로컬 테스트를 위해 Host를 설정해야 합니다"라는 문장을 다시 마주한다면, 우리는 당황하지 않고 이렇게 이해할 수 있을 것입니다.

"브라우저가 내 로컬 서버를 '진짜 그 도메인'이라고 믿게끔 속여서, 내가 준비한 보증서를 심사받게 하라!"