SSL 인증서 발급 방법: Let's Encrypt 무료부터 유료까지

SSL(정확히는 TLS) 인증서는 이제 선택이 아니라 기본입니다. HTTPS가 없으면 크롬이 "주의 요함" 경고를 띄우고, 구글 검색 순위에서도 불리하며, HTTP/2·HTTP/3 같은 최신 프로토콜도 쓸 수 없습니다. 다행히 대부분의 사이트는 무료로, 10분 안에인증서를 발급받을 수 있습니다. Let's Encrypt와 certbot 조합이면 명령어 한 줄로 발급부터 웹서버 설정, 자동 갱신까지 끝납니다.

이 글은 DV/OV/EV 인증서의 차이, Let's Encrypt 발급 실전 명령어, 발급이 실패하는 흔한 원인 (CAA 레코드, 검증 방식 선택)까지 처음부터 끝까지 다룹니다. 발급 후에는 SSL 인증서 점검로 체인·만료일이 제대로 잡혔는지 꼭 확인하세요.

DV vs OV vs EV — 대부분은 DV면 충분하다

인증서는 CA(인증기관)가 "무엇을 검증했는가"에 따라 세 등급으로 나뉩니다. 기술적인 암호화 강도는 세 등급 모두 완전히 동일합니다. 차이는 발급 절차와 인증서 안에 기재되는 조직 정보뿐입니다.

• DV(Domain Validation)— 도메인 소유권만 확인. 자동 발급, 몇 분이면 완료. Let's Encrypt가 발급하는 것이 바로 DV입니다. 블로그·쇼핑몰·API 서버·사내 서비스 등 거의 모든 용도에 충분합니다.
• OV(Organization Validation) — 사업자등록 등 법인 실재성까지 확인. 인증서 상세정보에 회사명이 기재됩니다. 수동 심사라 1~3일 걸리고 유료입니다.
• EV(Extended Validation) — 가장 엄격한 법인 심사. 과거에는 브라우저 주소창에 회사명이 초록색으로 표시됐지만, 현재 크롬·파이어폭스는 이 표시를 없앴습니다. 시각적 이점이 사라져 채택이 크게 줄었습니다.

유료(OV/EV)가 의미 있는 경우는 따로 있습니다: 금융·보험처럼 규제/감사 요건에 "조직 검증 인증서"가 명시된 경우, 계약상 CA의 배상 보증(warranty)이 필요한 경우, 자동 갱신을 돌릴 수 없는 폐쇄망 장비에 1년짜리 인증서를 수동 설치해야 하는 경우 정도입니다. 그 외라면 무료 DV로 시작하는 것이 정답입니다.

발급 절차의 원리 — 키 페어, CSR, 도메인 검증

certbot이 자동으로 처리해 주지만, 내부에서 무슨 일이 일어나는지 알아두면 문제가 생겼을 때 바로 원인을 짚을 수 있습니다. 발급은 항상 세 단계입니다.

1. 키 페어 생성 — 서버에 개인키(private key)와 공개키 쌍을 만듭니다. 개인키는 절대 서버 밖으로 나가면 안 됩니다.
2. CSR(인증서 서명 요청) 제출 — 공개키 + 도메인 이름(CN/SAN) + 조직 정보를 담은 요청서를 CA에 보냅니다. 유료 인증서를 신청할 때 만든 CSR에 도메인 오타나 누락이 없는지는 CSR 디코더에 붙여넣어 제출 전에 미리 확인하세요. SAN에 www 붙은 도메인을 빠뜨리는 실수가 정말 흔합니다.
3. 도메인 검증(Domain Validation)— CA가 "이 도메인이 정말 당신 것인지"를 확인합니다. 방식은 아래 표의 두 가지가 표준입니다.

한 가지 함정이 더 있습니다. 도메인에 CAA 레코드가 설정되어 있으면 거기에 명시된 CA만 인증서를 발급할 수 있습니다. 예를 들어 CAA 0 issue "digicert.com"만 있는 도메인은 Let's Encrypt 발급이 CAA record prevents issuance 오류로 거부됩니다. 발급이 이유 없이 실패한다면 CAA 레코드 확인로 CAA 레코드를 먼저 확인하고, 필요하면 issue "letsencrypt.org"를 추가하세요. CAA 레코드가 아예 없으면 모든 CA가 발급 가능하므로 문제되지 않습니다.

실전: nginx 서버를 0에서 HTTPS까지 (Let's Encrypt + certbot)

Ubuntu + nginx에서 example.com을 HTTPS로 만드는 전체 과정입니다. 전제 조건은 두 가지: 도메인의 A 레코드가 이 서버 IP를 가리키고 있고, 방화벽에서 80·443 포트가 열려 있어야 합니다.

1. certbot 설치
   sudo apt update && sudo apt install certbot python3-certbot-nginx
2. 발급 + nginx 자동 설정
   sudo certbot --nginx -d example.com -d www.example.com
   이메일 입력과 약관 동의 후, certbot이 HTTP-01 검증을 통과시키고 nginx 설정 파일에 ssl_certificate·ssl_certificate_key경로를 자동 삽입합니다. HTTP → HTTPS 리다이렉트도 물어보면 "2: Redirect"를 선택하세요.
3. 발급 확인 — 인증서는 /etc/letsencrypt/live/example.com/에 저장됩니다(fullchain.pem = 인증서+중간체인, privkey.pem = 개인키). 브라우저로 접속해 자물쇠가 뜨는지 보고, SSL 인증서 점검로 체인이 "리프 → 중간 → 루트"로 완성됐는지, 만료일이 약 90일 뒤인지 확인합니다.
4. 자동 갱신 검증 — Let's Encrypt 인증서는 유효기간이 90일이고 certbot은 설치 시 systemd 타이머(또는 cron)를 등록해 만료 30일 전에 자동 갱신합니다. 실제로 갱신이 돌아갈지 반드시 리허설하세요:
   sudo certbot renew --dry-run
   "Congratulations, all simulated renewals succeeded"가 나오면 끝입니다. 이후 손댈 일이 없습니다.

와일드카드가 필요하면 DNS-01로 발급합니다: sudo certbot certonly --manual --preferred-challenges dns -d "*.example.com" -d example.com. 다만 수동 방식은 갱신 때마다 TXT 레코드를 다시 올려야 하므로, 실서비스에서는 DNS 업체용 certbot 플러그인(route53, cloudflare 등)으로 자동화하는 것이 필수입니다.

발급 후 점검 체크리스트

• SSL 인증서 점검로 중간 인증서 체인 완성 여부 확인 — 리프만 설치하면 모바일·API 클라이언트에서만 실패하는 골치 아픈 오류가 납니다. nginx에는 항상 fullchain.pem을 지정하세요.
• www와 루트 도메인 둘 다 SAN에 포함됐는지 확인 — 한쪽만 발급하면 다른 쪽 접속 시 ERR_CERT_COMMON_NAME_INVALID가 뜹니다.
• HTTP → HTTPS 301 리다이렉트가 걸려 있는지, 페이지 안에 http:// 리소스(혼합 콘텐츠)가 없는지 확인.
• certbot renew --dry-run 성공 + systemctl list-timers에서 certbot.timer가 살아 있는지 확인. 만료 사고의 90%는 갱신 자동화 누락입니다.