HTTPS 인증서 실전 — Let's Encrypt 발급부터 자동 갱신까지 (certbot,ACME,관리형)

인프라 HTTPS SSL Let's Encrypt
6 분 소요

HTTPS 인증서는 한때 매년 돈을 내고 수동으로 발급받아 서버에 복사해 넣는 번거로운 작업이었습니다. 지금은 무료 인증서와 자동화 도구가 표준이 되어, 한 번 제대로 설정해 두면 사람이 손댈 일이 거의 없습니다. 이 글에서는 인증서를 실제로 발급받고, 서버나 클라우드에 설치하고, 자동으로 갱신되게 묶는 과정을 단계별로 다룹니다. 인증서가 무엇을 보증하는지, 인증기관과 신뢰 사슬이 무엇인지가 생소하다면 인증서란 무엇이고, 왜 필요한가를 먼저 읽고 오시길 권합니다.

발급의 기본 흐름: ACME와 도메인 소유 검증 #

자동 발급의 핵심은 ACME라는 프로토콜입니다. Let’s Encrypt 같은 인증기관이 ACME로 “정말 이 도메인의 주인이 맞는지"를 자동으로 확인하고 인증서를 내줍니다. 확인 방식은 두 가지가 자주 쓰입니다.

  • HTTP-01: 인증기관이 http://도메인/.well-known/acme-challenge/... 경로에 특정 값을 요구하고, 서버가 그 값을 응답하면 소유가 증명됩니다. 80번 포트가 외부에서 열려 있어야 합니다.
  • DNS-01: 인증기관이 요구한 값을 도메인의 TXT 레코드(_acme-challenge)에 올려 두면 소유가 증명됩니다. 80번 포트가 필요 없고, 와일드카드 인증서를 발급할 때 반드시 이 방식을 씁니다.

리눅스 서버에서 Let’s Encrypt 발급하기 #

가장 흔한 구성인 리눅스 + Nginx 기준입니다. certbot이 발급부터 Nginx 설정 수정까지 한 번에 처리합니다.

certbot 발급 
# 설치 (예: Ubuntu/Debian)
sudo apt install certbot python3-certbot-nginx

# 발급 + Nginx 설정 자동 반영 (HTTP-01)
sudo certbot --nginx -d schoolofweb.net -d www.schoolofweb.net

발급이 끝나면 인증서 파일이 다음 위치에 생깁니다. 각 파일의 역할을 알아 두면 오류를 진단하기 쉽습니다.

/etc/letsencrypt/live/ 
/etc/letsencrypt/live/schoolofweb.net/
├── privkey.pem      # 비밀 키. 절대 외부에 노출 금지
├── cert.pem         # 사이트 인증서 한 장
├── chain.pem        # 중간 인증서
└── fullchain.pem    # cert + chain. Nginx에는 보통 이것을 지정

Nginx에서 직접 지정한다면 fullchain.pem과 privkey.pem을 씁니다. 사이트 인증서만 넣고 중간 인증서(chain)를 빠뜨리면, 일부 환경에서 신뢰 사슬이 끊겨 오류가 납니다. 그래서 cert.pem이 아니라 fullchain.pem을 쓰는 것이 안전합니다.

nginx.conf 
server {
    listen 443 ssl;
    server_name schoolofweb.net www.schoolofweb.net;

    ssl_certificate     /etc/letsencrypt/live/schoolofweb.net/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/schoolofweb.net/privkey.pem;
    # ...
}

자동 갱신: 90일이 기본인 이유 #

Let’s Encrypt 인증서의 유효 기간은 90일입니다. 짧아 보이지만, 짧기 때문에 자동 갱신을 전제로 설계되어 있습니다. certbot을 패키지로 설치하면 보통 갱신 타이머가 함께 등록됩니다.

자동 갱신 점검 
# 자동 갱신 타이머가 등록돼 있는지 확인
systemctl list-timers | grep certbot

# 실제 갱신을 흉내 내서 문제없이 도는지 점검 (실제 갱신은 안 함)
sudo certbot renew --dry-run

renew는 만료가 임박한 인증서만 실제로 갱신합니다. 갱신 후 Nginx가 새 인증서를 다시 읽도록, 갱신 훅에 systemctl reload nginx를 걸어 두는 것까지 확인하면 완성입니다. 자동 갱신이 표준이 된 지금도 사고의 대부분은 “타이머가 멈춰 있었다"거나 “갱신은 됐는데 서버가 reload를 안 했다"에서 나옵니다.

와일드카드 인증서 #

*.schoolofweb.net처럼 하위 도메인 전체를 한 장으로 덮는 인증서를 와일드카드 인증서라고 합니다. 와일드카드는 HTTP-01로는 발급되지 않고, 반드시 DNS-01로 발급해야 합니다.

와일드카드 발급 (DNS-01) 
sudo certbot certonly --manual --preferred-challenges dns \
  -d "schoolofweb.net" -d "*.schoolofweb.net"

수동(--manual)으로 하면 TXT 레코드를 직접 넣어야 하므로 자동 갱신과 맞지 않습니다. 실무에서는 사용하는 DNS 서비스의 플러그인(예: certbot-dns-cloudflare, certbot-dns-route53)을 써서 TXT 레코드 등록까지 자동화하는 것이 정석입니다.

클라우드 관리형: 직접 관리하지 않는 선택 #

서버에 certbot을 두지 않고, 플랫폼이 인증서를 대신 관리하게 할 수도 있습니다. 요즘은 이 방식이 더 흔합니다.

  • AWS Certificate Manager(ACM): 인증서를 무료로 발급,자동 갱신하고, ALB나 CloudFront에 붙여 사용합니다. 검증은 보통 Route 53의 DNS 레코드로 자동 처리됩니다. 인증서 파일을 서버에 직접 만질 일이 없습니다.
  • Cloudflare: 프록시(주황색 구름)를 켜면 Cloudflare가 방문자와의 구간 인증서를 자동으로 발급,갱신합니다. 원본 서버 구간을 위한 Origin 인증서도 따로 제공합니다.

관리형은 키 파일을 직접 다루지 않아 편하지만, 인증서가 종단되는 지점(로드 밸런서,CDN)과 원본 서버 사이 구간을 어떻게 보호할지는 따로 챙겨야 합니다.

인증서 종류 빠르게 정리 #

  • DV(도메인 검증): 도메인 소유만 확인합니다. Let’s Encrypt가 여기에 해당하고, 대부분의 사이트에 충분합니다.
  • OV/EV(조직,확장 검증): 발급 기관이 조직 실체까지 확인합니다. 발급이 느리고 비용이 들며, 일부 금융,기업 환경에서 요구됩니다.
  • SAN(다중 도메인): 한 인증서에 여러 도메인을 함께 담습니다. -d 옵션을 여러 번 준 위 예시가 SAN 인증서입니다.
  • 와일드카드: 하위 도메인 전체를 한 장으로 덮습니다.

흔한 오류 진단 #

문제가 나면 브라우저 경고만 보지 말고 도구로 사슬을 직접 확인합니다.

인증서 사슬 진단 
# 서버가 내려주는 인증서 사슬과 만료일 확인
echo | openssl s_client -connect schoolofweb.net:443 -servername schoolofweb.net 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer

# 헤더와 인증서 상태를 한눈에
curl -vI https://schoolofweb.net

자주 만나는 원인은 다음과 같습니다.

  • 중간 인증서 누락: cert.pem만 설치한 경우입니다. fullchain.pem으로 바꿉니다. 브라우저에서는 멀쩡한데 일부 클라이언트에서만 실패하는 형태로 나타나기도 합니다.
  • 이름 불일치: 인증서에 담긴 도메인과 실제 접속 도메인이 다른 경우입니다. www 포함 여부, SAN에 빠진 도메인을 확인합니다.
  • 만료: 자동 갱신 타이머가 멈췄거나 갱신 후 reload가 빠진 경우입니다. certbot renew --dry-run으로 점검합니다.
  • HTTP-01 실패: 80번 포트가 막혀 있거나, 방화벽,보안 그룹에서 인증기관의 접근을 차단한 경우입니다. 포트가 안 열리는 환경이면 DNS-01로 바꿉니다.
  • 혼합 콘텐츠(mixed content): 페이지는 HTTPS인데 이미지,스크립트를 http://로 불러오는 경우입니다. 인증서 문제가 아니라 페이지 안의 링크를 https://로 고쳐야 합니다.

마무리 #

HTTPS 인증서 실전은 결국 세 가지로 압축됩니다. 도메인 소유를 ACME로 검증해 발급하고, 서버나 플랫폼에 신뢰 사슬이 끊기지 않게 설치하며, 만료 전에 자동으로 갱신되도록 묶어 두는 것입니다. 자동화가 표준이 된 지금은 “한 번 제대로 설정하고, 갱신이 실제로 도는지 가끔 확인"하는 것이 핵심입니다.

인증서가 동작하려면 그 앞에 도메인이 올바로 연결돼 있어야 합니다. 도메인 연결이 아직이라면 DNS 레코드 설정 실전을, 암호화와 자물쇠의 원리가 궁금하다면 주소창의 자물쇠는 무엇을 지키는가를 함께 보시길 권합니다.

X