티스토리 뷰

Dev/HTTP

Certbot, CA, SSL 인증서

kjyyjk 2026. 3. 28. 16:41

학습 배경

사내 블로그 서비스의 개발 환경을 구축하던 중 certbot과 dns 챌린지 방식을 활용해 https 설정을 했고,

그 과정에서 생긴 궁금증들을 해결해보았다.

 

Certbot이란?

Certbot은 Let's Encrypt라는 CA에서 SSL 인증서 발급 및 관리를 위해 제공하는 오픈소스 도구다.
CA(Certificate Authority)는 말 그대로 https 인증을 하는 기관이고, Let's Encrypt는 CA 종류 중 하나이다.

 

SSL 인증서의 목적은 무엇일까?

SSL 인증서는 이 서버가 해당 도메인의 진짜 주인이다라는 것을 인증한다.

 

도메인의 주인이라는 것을  인증해야 할까?

공격자가 중간에서 브라우저의 요청을 가로채 진짜 서버인척 흉내를 낼 수 있기 때문이다.
이를 MITM(Man in the Middle), 중간자 공격이라고 한다.

이런 공격을 대비하여 SSL 인증서로 내가 진짜임을 브라우저에게 인증하는 것이다.
공격자는 위조된 인증서, 혹은 자기 인증서를 가지고 있을테니 브라우저는 이 유효하지 않은 인증서를 보고 공격자임을 인식할 수 있다.

정리해보면 SSL 인증서는 이 서버가 도메인의 진짜 주인이니, 안심해도 된다라는 의미이며 이걸 인증해주는 곳이 바로 CA다.

 

CA는 어떻게 우리가 진짜라는걸 알고 인증서를 발급하는 걸까?

certbot을 활용해 ssl 인증서를 발급 받으려면 챌린지를 거쳐야 하고, 이 챌린지에 성공해야만 SSL 인증서를 발급해준다.

챌린지는 우리가 실제로 이 도메인을 컨트롤 할 수 있는지 확인하는 과정으로 크게 두 가지 방식이 있다.
- http 챌린지 : 서버에 토큰 파일을 제공하고 도메인 주소로 요청했을 때 해당 토큰 파일이 있는지를 검증한다. 80 포트를 사용한다.
- dns 챌린지 : 서버에 랜덤 값을 주고 이를 DNS TXT에 추가할 수 있는지를 검증한다.

 

위 인증서는 포게더 개발 환경 api 서버의 도메인에 발급된 인증서다.
인증서에 관한 기본 정보가 나열되어있고, 가장 아래 두 줄에서 Certificate Path와 Private Key Path를 확인할 수 있다.
해당 경로에 있는 fullchain.pemprivkey.pem이 바로 인증서의 본체다.

fullchain.pem에는 인증서와 공개키가 포함되어 있고, privkey는 서버의 개인키다.
공개키로 암호화한 건 개인키로만 복호화할 수 있다.
(지난 포스트에서 다룬 내용이다.)

TLS 핸드쉐이크 과정 중 ServerHello 단계에서 브라우저에게 fullchain.pem을 전달해

자신이 진짜 서버임을 증명함과 동시에 공개키를 전달한다.

근데 이 fullchain.pem 마저도 탈취하면 자신이 진짜 서버인척, 인증받은 척 행세할 수 있지 않나?라는 의문이 들었다.

 

fullchain.pem이 탈취되면?

결론적으로는 소용 없다.
TLS 1.2 버전까지는 브라우저가 비밀 값을 공개키로 암호화하여 전달한다.
암호화한 값은 서버가 가지고 있는 개인키로만 복호화가 가능하니, 공격자는 할 수 있는게 아무것도 없다.

TLS 1.3 버전에서는 서버가 개인키로 서명(TLS 핸드쉐이크의 모든 내용을 해싱하고 암호화)하여 브라우저에게 전달한다.
브라우저는 공개키로 서명을 풀고, 그 해싱값이 원본 해싱값과 일치하면 서버를 신뢰한다.
이때 전제 조건은 공개키를 알고 있어도 공개키로 풀 수 있는 서명을 만들어내지 못해야한다는 것이다.
이게 바로 비대칭 알고리즘이 제공하는 기능이며 이러한 복잡함으로 인해 https 본 통신에서는 비대칭키가 아닌 대칭키를 사용한다.
(지난 포스트에서 다룬 내용이다.)

 

요약해보자면

Certbot은 Let's Encrypt라는 ca에서 제공하는 오픈소스 도구이고,
챌린지라는 과정을 통해 우리 서버가 도메인의 진짜 주인이라는 것을 확인하여 SSL 인증서를 발급한다.
서버는 이 SSL 인증서를 통해 도메인의 진짜 주인임을 브라우저에게 인증한다.
만약 privkey.pem(개인키)가 탈취당한다면 누구나 서버 행세를 하고 암호화된 정보를 확인할 수 있으니 절대절대 조심해야 한다.

'Dev > HTTP' 카테고리의 다른 글

https, 대칭키, 비대칭키  (0) 2026.03.18
[HTTP] HTTP 헤더 (3)  (0) 2023.01.03
[HTTP] HTTP 헤더 (2)  (0) 2022.12.29
[HTTP] HTTP 헤더 (1)  (2) 2022.12.29
[HTTP] HTTP 상태코드  (0) 2022.12.27
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2026/04   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30
글 보관함