Ubuntu 24.04 Apache Certbot 설치 및 SSL 적용 방법

구축 목표

Ubuntu 24.04 환경에서 HTTPS를 지원하는 Apache 사이트를 구축합니다. Certbot을 통해 발급받은 무료 Let's Encrypt 인증서를 사용하며, systemd timer를 통해 자동으로 갱신되므로 별도의 관리가 필요 없습니다. 작업에 필요한 명령어는 단 한 줄입니다. 하지만 오류는 대부분 이 명령어를 실행하기 전 단계에서 발생합니다. ServerName 설정이 누락된 vhost, 공급업체 방화벽에서 80 포트가 차단된 경우, 또는 DNS가 여전히 이전 서버를 가리키는 경우 등이 해당됩니다. 따라서 이 가이드는 사전 준비 사항에 집중하며, 각 오류 발생 시 출력되는 정확한 에러 메시지를 명시합니다.

두 가지 주의 사항이 있습니다. 웹 서버로 nginx를 사용하는 경우, 전체적인 흐름은 동일하지만 플러그인과 설정 파일이 다릅니다. 이 경우 nginx 버전 가이드를 참조하십시오. 보안을 적용하려는 대상이 내부 전용인 경우(예: 사설 IP를 사용하는 관리자 패널, 외부 접근이 없는 스테이징 서버)에는 인증 기관이 필요하지 않습니다. 이럴 때는 self-signed certificate를 사용하는 것이 구조가 더 단순하며 오프라인에서도 작동합니다.

Prerequisites, and the three ways this fails before Certbot even runs

• Apache가 이미 plain HTTP로 사이트를 서비스 중이어야 합니다. Certbot의 Apache plugin은 기존 사이트를 수정하며, 새로운 사이트를 생성하지 않습니다. 빈 VPS에서 시작하는 경우, 먼저 LAMP stack on Ubuntu 24.04를 구축한 후 다시 돌아오십시오. 이 가이드는 해당 스택의 TLS 관련 장입니다.
• VPS 주소에 A record가 설정된 공용 도메인이 필요합니다. Let's Encrypt의 HTTP-01 challenge는 인증 서버가 인터넷을 통해 서버에 접속하는 방식입니다. 포트 포워딩이 없는 NAT 환경의 homelab, .local 이름, 또는 IP 주소만으로는 불가능합니다. dig +short example.com은 반드시 VPS 주소를 반환해야 합니다. 지난 1시간 이내에 DNS를 변경했다면, 인증을 실행하기 전에 이전 레코드의 TTL이 만료될 때까지 기다리십시오.
• AAAA record가 존재한다면 반드시 정확해야 합니다. AAAA record가 게시되면 Let's Encrypt는 IPv6를 우선적으로 사용합니다. 따라서 노트북에서 curl(아마도 IPv4 사용)가 정상 작동하더라도, 유효하지 않은 AAAA record가 있으면 인증에 실패합니다. 정확한 AAAA record를 게시하거나, 아예 게시하지 마십시오.

80번 및 443번 포트가 ufw와 서비스 제공업체의 네트워크 방화벽 모두에서 열려 있어야 합니다. 대부분의 호스팅 패널에는 OS에서 확인할 수 없는 별도의 방화벽이 존재합니다. HTTP-01은 80번 포트를 통해 인증을 수행하므로, 443번 포트만 사용하는 환경에서는 실행할 수 없습니다.

sudo ufw allow "Apache Full"
sudo ufw status

준비가 완료되면 전체 작업은 15분 정도 소요되며, 그중 10분은 읽는 데 사용됩니다.

Snap인가 apt인가? 24.04에서는 apt를 사용해도 좋습니다

Certbot이 snap 배포 방식으로 변경된 데에는 타당한 이유가 있습니다. 배포판 패키지는 업데이트가 느리기 때문입니다. Ubuntu 20.04는 Certbot 0.40 버전을 탑재한 후 업데이트되지 않았으며, 프로젝트 관리자들은 5년 전의 버그를 수정하는 데 어려움을 겪었습니다. 24.04에서는 이 문제가 해결되었습니다. 아카이브에 최신 버전인 Certbot 2.9.0이 포함되어 있으며, unattended-upgrades가 패치를 유지합니다. 이 OS에서는 apt 사용을 권장합니다. snapd 데몬이 필요 없으며, Apache plugin이 동일한 트랜잭션 내에 설치됩니다. 또한 갱신 타이머가 Debian 방식대로 systemd와 통합됩니다.

sudo apt update
sudo apt install -y certbot python3-certbot-apache
certbot --version

올바른 결과: certbot 2.9.0. python3-certbot-apache 패키지는 Apache 설정을 읽고 수정하는 플러그인입니다. 이 패키지가 없으면 certbot --apache 실행 시 The requested apache plugin does not appear to be installed 오류가 발생합니다.

다음 두 가지 경우에는 여전히 snap 사용이 적절합니다. 출시 당일에 가장 최신 버전의 Certbot을 사용해야 하거나, snap으로만 제공되는 DNS plugin이 필요한 경우입니다(certbot-dns-* 제공업체 플러그인 중 일부가 이에 해당합니다). 이 방식을 선택한다면 다음을 따르십시오.

sudo apt remove -y certbot python3-certbot-apache
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

어떤 방식을 선택하든 두 방식을 동시에 실행하지 마십시오. 두 개의 설치본이 있으면 /etc/letsencrypt을 두고 두 개의 갱신 스케줄러가 충돌합니다. 또한 PATH에서 shell이 찾는 certbot이 인증서를 관리하는 프로세스가 아닐 수 있습니다. 위의 apt remove 라인은 선택 사항이 아닙니다.

vhost Certbot 수정 사항이 이미 존재해야 합니다 — ServerName 설정이 핵심입니다

certbot --apache는 전달된 각 -d 도메인과 일치하는 ServerName 또는 ServerAlias를 가진 port-80 가상 호스트를 찾아 도메인 제어권을 증명한 뒤, 해당 vhost의 SSL 복사본을 작성하는 방식으로 작동합니다. 일치하는 ServerName가 없으면 매칭에 실패합니다. Ubuntu의 기본 000-default.conf에는 ServerName이 주석 처리되어 있습니다. 이 주석 처리된 한 줄이 이 가이드의 통합 명령어가 실패하는 가장 흔한 원인입니다.

따라서 Certbot을 실행하기 전에 사이트에 적절한 이름 기반 vhost를 설정하십시오. /etc/apache2/sites-available/example.com.conf을 생성하십시오:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com
    ErrorLog ${APACHE_LOG_DIR}/example.com-error.log
    CustomLog ${APACHE_LOG_DIR}/example.com-access.log combined
</VirtualHost>

해당 설정을 활성화하고 Apache가 이를 올바르게 파싱하고 이름을 해당 vhost로 라우팅하는지 확인하십시오:

sudo a2ensite example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2
sudo apache2ctl -S

configtest 결과에 Syntax OK이 출력되어야 합니다. 만약 AH00558: apache2: Could not reliably determine the server's fully qualified domain name이 함께 출력된다면, 이는 vhost가 아닌 global ServerName에 대한 경고입니다. 이 상황은 무해하며 echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2에 의해 무시됩니다.

중요한 확인 사항은 -S 출력입니다. port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.conf:1)과 그 아래의 alias www.example.com 형식이 나타나야 합니다. Apache는 sites-available에서 편집한 파일이 아니라, 실제로 읽어 들인 sites-enabled 심볼릭 링크를 보고합니다. example.com이 port 80에 대해 나열되지 않으면 Certbot도 이를 찾을 수 없습니다.

Issue the certificate: certbot --apache

sudo certbot --apache -d example.com -d www.example.com

처음 실행 시 세 가지를 요청합니다. 첫째는 이메일 주소입니다(ACME 계정 및 긴급 CA 통지에 사용됩니다. Let's Encrypt는 더 이상 만료 경고를 보내지 않으므로 갱신 모니터링은 사용자가 직접 수행해야 합니다). 둘째는 Let's Encrypt 약관 동의입니다. 셋째는 이메일 정보를 EFF와 공유할지 여부입니다. 더 이상 리다이렉트 관련 질문은 나타나지 않습니다. Certbot 2.0부터 Apache installer는 기본적으로 HTTP를 HTTPS로 리다이렉트하며, 이는 일반적인 요구 사항입니다. 만약 콘텐츠 제공을 위해 일반 HTTP를 반드시 유지해야 한다면 --no-redirect를 입력하십시오.

성공 시 다음과 같이 표시됩니다. 내용을 대충 훑어보지 말고 자세히 읽어야 합니다.

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/example.com/privkey.pem
This certificate expires on 2026-10-14.

Deploying certificate
Successfully deployed certificate for example.com to /etc/apache2/sites-available/example.com-le-ssl.conf
Successfully deployed certificate for www.example.com to /etc/apache2/sites-available/example.com-le-ssl.conf
Congratulations! You have successfully enabled HTTPS on https://example.com and https://www.example.com

이 메시지가 출력되면 Certbot은 다음 네 가지 작업을 수행한 것입니다. Apache의 ssl 모듈이 활성화되어 있지 않다면 활성화합니다. *:443에 있는 vhost의 복사본인 example.com-le-ssl.conf 파일을 생성하며, 여기에는 SSLEngine on 및 인증서 경로가 포함됩니다. 해당 모듈을 활성화합니다. 마지막으로 기존 port-80 vhost에 모든 요청을 HTTPS로 301 리다이렉트하는 RewriteRule 블록을 추가합니다. 기존 vhost 파일은 교체되는 것이 아니라 수정됩니다. 생성된 SSL 설정 파일은 기존 파일 옆에 위치하며, 추가된 모든 내용을 확인할 수 있습니다.

인증서의 실제 위치 및 복사하면 안 되는 이유

모든 파일은 /etc/letsencrypt/live/example.com/ 디렉토리에 저장됩니다. 여기에는 fullchain.pem(인증서 및 중간 체인 — 서버가 참조해야 할 파일), privkey.pem(root만 읽을 수 있는 private key)가 포함됩니다. 또한 개별 파일이 필요한 소프트웨어를 위해 cert.pem 및 chain.pem이 제공됩니다. 이 파일들은 /etc/letsencrypt/archive/를 가리키는 symlinks입니다. 이러한 간접 참조 방식이 갱신 메커니즘입니다. 갱신 시 archive/에 새 파일이 작성되고 symlinks가 새 파일을 가리키도록 변경됩니다. 다른 소프트웨어가 live/ 경로를 참조하도록 설정하면 별도 작업 없이 갱신된 인증서를 사용할 수 있습니다. 파일을 다른 곳으로 복사하면 90일 후에 인증서 만료로 인한 서비스 중단이 발생합니다.

알아두어야 할 다른 파일은 /etc/letsencrypt/renewal/example.com.conf입니다. 이 파일에는 인증서 발급 정보인 authenticator = apache, installer = apache, 도메인 정보가 기록됩니다. 이를 통해 갱신 프로세스가 자동으로 반복될 수 있으며, 갱신 후 Apache 재시작까지 수행할 수 있습니다.

갱신이 이미 예약되어 있습니다 — 빌드하지 말고 확인만 하십시오

Let's Encrypt 인증서의 유효 기간은 설계상 90일입니다. apt 패키지를 통해 이미 관련 기능이 설치되었습니다. Certbot이 하루에 두 번 무작위 시간에 실행되는 systemd timer가 포함되어 있으며, 만료까지 30일 이내인 모든 인증서를 갱신합니다. 별도의 cron job을 추가하지 마십시오. 중복된 스케줄러는 로그 노이즈와 rate-limit 노출만 초래합니다.

systemctl list-timers certbot.timer
sudo certbot renew --dry-run

첫 번째 명령은 timer가 활성화되어 있음을 보여주며, NEXT 항목에 향후 24시간 이내의 시간이 표시됩니다. 스케줄은 하루 2회이며 무작위 지연이 적용되므로 정확한 시간은 예측할 수 없습니다 (snap 설치 시 timer는 snap.certbot.renew.timer입니다). dry run은 Let's Encrypt의 staging environment를 대상으로 전체 갱신 시뮬레이션을 수행합니다. 실제 challenge가 수행되지만, 인증서가 발급되거나 rate-limit이 적용되지는 않습니다. 성공적인 결과는 다음과 같이 끝납니다:

Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/example.com/fullchain.pem (success)

dry run이 실패하면 약 60일 후의 실제 갱신도 동일하게 실패합니다. 현재 인증서의 유효 기간이 충분히 남아 있을 때 즉시 문제를 해결하십시오. 일반적인 원인은 인증서 발급 후 80 port를 다시 차단하도록 설정된 firewall rule입니다.

curl로 확인하기, 자물쇠 아이콘의 상태

curl -sI http://example.com | head -n 3
curl -I https://example.com
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuer -dates

첫 번째 결과는 Location: https://example.com/ 헤더를 포함한 HTTP/1.1 301 Moved Permanently를 반환해야 합니다. 이는 Certbot이 설치한 리다이렉션입니다. 두 번째 결과는 curl에서 TLS 오류가 발생하지 않은 HTTP/1.1 200 OK를 반환해야 합니다. 세 번째 결과는 발행자를 출력합니다. R12 또는 E7과 같은 짧은 CN을 포함한 O = Let's Encrypt 라인이 출력되며, 만료일은 notAfter 기준으로 약 90일 남아야 합니다. 브라우저에서는 자물쇠 아이콘이 나타나며, 이를 클릭하면 동일한 발행자를 확인할 수 있습니다. curl은 정상 작동하지만 브라우저에서 경고가 발생한다면, 이는 인증서 문제가 아니라 캐시된 페이지를 보고 있거나 잘못된 hostname을 사용하고 있을 가능성이 매우 높습니다.

Multiple sites: 하나의 SAN certificate 또는 사이트당 하나의 cert

두 방법 모두 가능하며, 갱신 방식은 동일합니다. 동일한 서버 내에서 서로 관련 없는 사이트들을 관리할 때는 사이트당 한 번씩 명령어를 실행하십시오. 각 사이트는 live/ 하위에 고유한 디렉토리와 갱신 설정을 가집니다. 따라서 한 도메인에 문제가 발생해도 다른 도메인의 갱신이 차단되지 않습니다. 이 방식이 기본 설정입니다.

여러 이름을 사용하는 하나의 사이트의 경우, 하나의 SAN certificate에 모든 이름을 포함하십시오. 단일 certificate에는 최대 100개의 이름을 포함할 수 있습니다. 위에서 example.com 및 www.example.com를 통해 이 방식을 이미 수행했습니다. 나중에 기존 certificate에 이름을 추가하려면, certificate 이름과 전체 새 목록을 지정하여 재발급하십시오:

sudo certbot --apache --cert-name example.com -d example.com -d www.example.com -d blog.example.com

Certbot은 변경된 도메인 세트를 감지하고 확장을 확인하는 절차를 거칩니다. 이후 기존 live/ 경로에 certificate를 교체합니다. 따라서 다른 설정은 수정할 필요가 없습니다. 목록은 추가(append)가 아닌 교체(replacement) 방식임에 유의하십시오. 해당 명령어에서 www을 생략하면 새 certificate에서 해당 도메인이 자동으로 제외됩니다.

Wildcards에는 DNS-01이 필요하며, 일반적으로 Wildcard는 필요하지 않습니다

HTTP-01 방식으로는 *.example.com를 발급할 수 없습니다. 웹 서버에 파일을 배치하는 방식은 단일 hostname에 대한 제어권만 증명하며, 전체 namespace를 증명하지는 못하기 때문입니다. Wildcard를 발급하려면 DNS-01 challenge가 필요합니다. Certbot은 _acme-challenge.example.com에 TXT 레코드를 설정합니다. 이는 실제로는 DNS 제공업체의 API 자격 증명이 포함된 certbot-dns-* plugin을 사용하거나, --manual를 사용하여 갱신할 때마다 TXT 레코드를 수동으로 수정해야 함을 의미합니다(매우 번거로우므로 이 방식은 권장하지 않습니다). TXT 레코드 작동 원리부터 자동 갱신을 위한 plugin까지의 상세 과정은 wildcard certificates with Certbot over DNS-01에서 확인할 수 있습니다. 조언하자면, 관리해야 할 서브도메인이 4개인 경우, Wildcard를 사용하는 것보다 4개 모두를 포함하는 SAN certificate를 사용하는 것이 더 간단하며 서버에 DNS API 키를 보관할 필요도 없습니다.

Failure modes, with the strings you will see

Apache 설정 오류로 인해 Certbot이 시작되지 않습니다.

The apache plugin is not working; there may be problems with your existing configuration.
The error was: MisconfigurationError('Error while running apache2ctl configtest.\n\nAction \'configtest\' failed.\nThe Apache error log may have more information.\n\nAH00526: Syntax error on line 12 of /etc/apache2/sites-enabled/example.com.conf')

플러그인은 작업을 수행하기 전 configtest를 실행하며, Apache 자체에 오류가 있으면 중단됩니다. Certbot이 예외의 repr을 출력하므로 \n는 문자 그대로의 내용입니다. sudo apache2ctl configtest를 직접 실행하십시오. 해당 명령은 파일명과 줄 번호를 표시합니다. 원인은 수동 편집 중 발생한 오타, 존재하지 않는 경로를 가리키는 SSLCertificateFile, 또는 활성화되지 않은 모듈 참조 등입니다. Syntax OK이 출력될 때까지 수정 후 Certbot을 다시 실행하십시오.

도메인과 일치하는 vhost가 없습니다.

Unable to find a virtual host listening on port 80 which is currently the only challenge port.

이는 이전 단계에서 발생한 missing-ServerName 오류가 인증 시점에 발견된 것입니다. Certbot이 활성화된 모든 port-80 vhost에서 -d와 일치하는 ServerName/ServerAlias를 검색했으나 찾지 못했습니다. sudo apache2ctl -S을 통해 Apache의 실제 라우팅 상태를 확인할 수 있습니다. 올바른 vhost에 ServerName 라인을 추가하고, reload한 뒤 다시 시도하십시오. 이와 유사한 사례로, 인증 요청이 잘못된 vhost로 전달되는 경우가 있습니다. 다른 사이트가 요청을 가로채서 challenge response가 Invalid response ... 404으로 반환됩니다. 진단 방법과 도구는 동일합니다: apache2ctl -S.

인증 시간 초과(Validation timeout).

Certbot failed to authenticate some domains (authenticator: apache).
...
Detail: ...: Timeout during connect (likely firewall problem)

Let's Encrypt가 DNS에 등록된 주소의 port 80으로 TCP 연결을 할 수 없습니다. 발생 가능성이 높은 순서는 다음과 같습니다: 호스팅 패널에서 설정된 provider의 네트워크 방화벽(ufw와 별개), 443 또는 SSH만 허용하는 ufw 규칙, 이전 서버를 가리키고 있는 DNS, 또는 stale-AAAA 문제입니다. 후자는 Let's Encrypt 서버는 IPv6로 시도하지만, 서버는 IPv4로만 응답하는 경우입니다. VPS 외부에서 테스트하십시오: 노트북에서 curl -I http://example.com를 실행하면 Let's Encrypt validator가 보는 상태를 재현할 수 있습니다.

반복된 재시도로 인해 rate limit에 도달했습니다.

Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/

Let's Encrypt는 계정당, 호스트명당 시간당 5회의 인증 실패를 허용합니다. 2025년 rate-limit 개편 이후, 이는 refilling bucket 방식으로 운영되며 약 12분마다 1회의 재시도 권한이 회복됩니다. 방화벽 오류 상태에서 계속 재시도하면 권한을 빠르게 소진하게 됩니다. 대기하는 방법도 있지만, 근본적인 해결책은 행동 방식의 변경입니다. 실패 시에는 staging 환경에서 성공할 때까지 디버깅을 수행하십시오.

sudo certbot certonly --apache --dry-run -d example.com -d www.example.com

certonly에 주의하십시오: --dry-run은 certonly 및 renew 서브커맨드에서만 허용되며, certbot --apache --dry-run 형태는 실행 자체가 거부되며 --dry-run currently only works with the 'certonly' or 'renew' subcommands 메시지를 출력합니다. dry run은 staging 환경을 대상으로 검증하며, staging은 허용 한도가 넉넉하고 실제 인증서를 발급하지 않으므로 오후 내내 테스트해도 무방합니다. staging 검증이 통과된 후에만 실제 명령어를 실행하십시오. 다른 제한 사항인 등록된 도메인당 주당 50개의 인증서, 주당 동일 이름 세트 5개의 중복 인증서 제한은 스크립트가 루프를 돌며 재발급을 시도할 때만 발생합니다.

HTTPS 설정이 완료된 후, 인증서는 서버가 아닌 전송(transport)을 보호한다는 점을 기억하십시오. port 22는 여전히 비밀번호 무차별 대입 공격을 받고 있습니다. 이를 Fail2ban on Ubuntu 24.04와 함께 설정하는 것이 다음 단계입니다.

FAQ

Ubuntu 24.04의 Apache 환경에서 Certbot을 snap 또는 apt 중 무엇으로 설치해야 합니까?

apt를 사용하십시오. Ubuntu 24.04에는 Certbot 2.9.0이 포함되어 있으며, 이는 이 가이드의 모든 작업을 수행하기에 충분한 최신 버전입니다. 또한 unattended-upgrades를 통해 보안 패치를 받으며 snapd가 필요하지 않습니다. 최신 릴리스가 즉시 필요하거나 snap으로만 배포되는 DNS plugin이 필요한 경우에만 snap을 선택하십시오. 만약 snap으로 전환한다면, 두 개의 갱신 스케줄러가 공존하지 않도록 먼저 apt remove certbot python3-certbot-apache을 수행하십시오.

Certbot에서 "Unable to find a virtual host listening on port 80" 오류가 발생하는 이유는 무엇입니까?

-d으로 전달한 도메인과 일치하는 ServerName 또는 ServerAlias를 가진 활성화된 port-80 vhost가 없기 때문입니다. Ubuntu의 기본 vhost는 ServerName이 주석 처리되어 있습니다. sudo apache2ctl -S을 실행하여 해당 이름을 가져야 하는 vhost를 찾거나 생성하십시오. 그 다음 ServerName example.com을 추가하고 Apache를 재시작한 뒤 Certbot을 다시 실행하십시오.

"Timeout during connect (likely firewall problem)" 오류를 어떻게 해결합니까?

Let's Encrypt가 DNS에 게시된 주소의 port 80에 접속할 수 없는 상태입니다. 제공업체의 패널 수준 네트워크 방화벽과 ufw를 확인하십시오. dig +short example.com이 해당 VPS를 반환하는지 확인하고, 오래된 AAAA 레코드가 있다면 삭제하거나 수정하십시오. 검증 과정에서 IPv6가 존재하면 IPv6를 우선적으로 사용합니다. 서버 외부에서 curl -I http://example.com을 사용하여 해결 여부를 확인한 후, 실제 인증서를 발급받기 전에 sudo certbot certonly --apache --dry-run -d example.com로 테스트하십시오.

Ubuntu 24.04에서 Certbot이 인증서를 자동으로 갱신합니까?

예, 그렇습니다. apt 패키지는 하루에 두 번 실행되어 만료까지 30일 이내인 모든 인증서를 갱신하고 이후 Apache를 재시작하는 systemd timer인 certbot.timer을 설치합니다. snap은 동일한 작업을 위해 snap.certbot.renew.timer를 사용합니다. systemctl list-timers certbot.timer으로 확인하고 sudo certbot renew --dry-run으로 테스트하십시오. 별도의 cron job을 추가하지 마십시오.

Certbot과 Apache를 사용하여 와일드카드 인증서를 어떻게 발급받습니까?

와일드카드는 DNS-01 챌린지가 필요합니다. Certbot이 _acme-challenge.example.com에 TXT 레코드를 배치해야 하며, 이를 위해 DNS 제공업체의 API 자격 증명이 포함된 certbot-dns-* plugin이 필요합니다(--manual 대안은 갱신할 때마다 TXT 레코드를 수동으로 편집해야 합니다). 알려진 서브도메인이 몇 개뿐이라면, 각 도메인을 명시적으로 나열하는 SAN 인증서를 사용하는 것이 더 간단하며 서버에 DNS API 키를 보관하지 않아도 됩니다.