가이드

작성자 Matt Connor 2026-10-21

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

Q: Certbot이 "Unable to find a virtual host listening on port 80" 오류를 내는 이유는 무엇입니까?

활성화된 포트 80 가상 호스트(vhost) 중에 -d으로 전달한 도메인과 일치하는 ServerName나 ServerAlias가 없기 때문입니다. Ubuntu의 기본 가상 호스트 설정은 ServerName이 주석 처리된 상태로 제공됩니다. sudo apache2ctl -S을 실행하여 해당 도메인을 관리할 가상 호스트를 찾거나 생성하고, ServerName example.com를 추가한 뒤 Apache를 리로드하고 Certbot을 다시 실행하십시오.

Q: Certbot과 Apache로 와일드카드 인증서를 받으려면 어떻게 해야 합니까?

와일드카드는 DNS-01 챌린지가 필요합니다. Certbot이 _acme-challenge.example.com에 TXT 레코드를 생성해야 하므로, DNS 제공업체의 API 자격 증명을 사용하는 certbot-dns-* 플러그인이 필요합니다(--manual 대안은 갱신할 때마다 수동으로 TXT 레코드를 수정해야 합니다). 알려진 서브도메인이 몇 개뿐이라면, 서브도메인을 명시적으로 나열하는 SAN 인증서가 더 간단하며 서버에 DNS API 키를 저장할 필요도 없습니다.

Ubuntu 24.04에서 apt로 Certbot 2.9.0을 설치하고 Let's Encrypt 인증서를 적용합니다. 인증 실패의 주원인인 ServerName 설정 오류를 해결하고 한 줄의 명령어로 자동 갱신까지 완료하는 실전 가이드를 확인하세요.

구축할 환경

Ubuntu 24.04 환경에서 HTTPS로 응답하며 브라우저가 신뢰하는 무료 Let's Encrypt 인증서를 사용하는 Apache 사이트를 구축합니다. 인증서는 Certbot으로 발급하며, systemd 타이머를 통해 자동으로 갱신되므로 이후 별도의 관리가 필요 없습니다. 이 작업을 수행하는 명령어는 단 한 줄입니다. 문제가 발생하는 지점은 항상 이 명령어 실행 이전입니다. 예를 들어 ServerName 설정이 없는 가상 호스트(vhost), 제공업체 방화벽에서 닫힌 80번 포트, 이전 서버를 가리키고 있는 DNS 설정 등이 원인입니다. 따라서 이 가이드는 사전 조건 점검에 대부분의 시간을 할애하며, 각 실수로 인해 발생하는 정확한 오류 메시지를 명시합니다.

두 가지 참고 사항이 있습니다. 웹 서버가 nginx인 경우 전체적인 흐름은 같으나 플러그인과 설정 파일이 다르므로 nginx 버전 가이드를 사용하십시오. 또한 보안을 적용하려는 대상이 내부 전용 서비스, 사설 주소의 관리자 패널, 외부 접근이 없는 스테이징 서버라면 인증 기관이 전혀 필요하지 않습니다. 자체 서명 인증서(self-signed certificate)를 사용하는 것이 구성이 더 간단하며 오프라인 환경에서도 작동합니다.

사전 요구 사항 및 Certbot 실행 전 실패하는 세 가지 경우

Apache가 이미 일반 HTTP로 사이트를 서비스 중이어야 합니다. Certbot의 Apache 플러그인은 기존 사이트 설정을 수정하는 도구이며, 사이트를 새로 생성하지 않습니다. 초기 상태의 VPS에서 시작한다면 먼저 Ubuntu 24.04의 LAMP 스택을 구축한 뒤 이 가이드로 돌아오십시오. 이 가이드는 해당 구축 과정의 누락된 TLS 챕터입니다.
VPS 주소를 가리키는 A 레코드가 설정된 공개 도메인이 필요합니다. Let's Encrypt의 HTTP-01 챌린지는 인증 서버가 인터넷을 통해 귀하의 서버에 직접 연결됨을 의미합니다. 포트 포워딩이 없는 NAT 환경의 홈랩이나 .local 이름은 사용할 수 없습니다. HTTP-01은 IP 주소로도 검증할 수 있으나, Let's Encrypt는 옵트인 shortlived 프로필(160시간 유효 기간)에서만 IP 인증서를 발급합니다. 또한 apt로 설치한 Certbot 2.9.0은 ACME 프로필이나 IP 주소 요청을 지원하지 않으므로, 이 가이드에는 도메인 이름이 필수입니다. dig +short example.com은 반드시 귀하의 VPS 주소를 반환해야 하며, 최근 1시간 이내에 DNS를 변경했다면 이전 레코드의 TTL이 만료될 때까지 기다린 후 발급을 시도하십시오.
AAAA 레코드가 존재한다면 정확해야 합니다. Let's Encrypt는 AAAA 레코드가 게시되어 있으면 항상 IPv6를 우선 시도합니다. 해당 연결이 시간 초과되면 IPv4로 재시도하지만, 그 외의 오류는 재시도 기회가 없습니다. 연결을 거부하는 주소나 현재 서버가 아닌 다른 서버를 가리키는 AAAA 레코드는 검증에 실패합니다. 노트북에서 IPv4로 curl를 실행했을 때 정상 작동하더라도 검증은 실패할 수 있습니다. 정확한 AAAA 레코드를 게시하거나, 아예 게시하지 마십시오.

포트 80과 443은 ufw뿐만 아니라 제공업체의 네트워크 방화벽에서도 열려 있어야 합니다. 대부분의 호스팅 패널은 운영체제가 인식하지 못하는 별도의 방화벽을 가지고 있습니다. 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에서는 이러한 문제가 해결되었습니다. 저장소에서 2024년 2월에 릴리스된 최신 2.x 라인의 Certbot 2.9.0 버전을 제공하며, unattended-upgrades를 통해 Ubuntu가 배포하는 모든 보안 업데이트를 설치할 수 있습니다. 업스트림은 이미 5.x 시리즈로 넘어갔지만, 이 가이드의 내용은 해당 버전이 필요하지 않습니다. 이 운영체제에서는 apt 사용을 권장합니다. snapd 데몬을 설치할 필요가 없고, Apache 플러그인이 동일한 트랜잭션으로 설치되며, 갱신 타이머가 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 플러그인(일부 certbot-dns-* 제공자 플러그인이 해당함)이 필요한 경우입니다. snap을 선택한다면 다음을 수행하십시오:

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에서 찾아내는 certbot가 실제 인증서를 관리하는 실행 파일이 아닐 수 있습니다. 위의 apt remove 줄은 선택 사항이 아닙니다.

Certbot이 수정할 vhost는 이미 존재해야 하며, ServerName 설정이 핵심입니다

certbot --apache은 전달받은 각 -d 도메인과 일치하는 ServerName 또는 ServerAlias를 가진 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가 해당 설정을 구문 분석하여 이름을 올바르게 라우팅하는지 확인합니다:

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가 아닌 전역 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 심볼릭 링크를 보고합니다. 만약 80번 포트에 example.com이 나열되지 않는다면, Certbot 역시 해당 설정을 찾지 못할 것입니다.

인증서 발급: certbot --apache

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

최초 실행 시 세 가지를 묻습니다. 이메일 주소(Let's Encrypt는 더 이상 ACME 계정에 이메일을 저장하지 않으며 만료 알림도 보내지 않으므로, 갱신 모니터링은 사용자가 직접 해야 합니다), Let's Encrypt 이용 약관 동의, 그리고 EFF와 이메일 공유 여부입니다. 이제 리다이렉트 여부를 묻지 않습니다. Certbot 1.0부터 Apache 설치 프로그램은 기본적으로 HTTP를 HTTPS로 리다이렉트하며(질문 자체는 1.4 버전에서 삭제됨), 이는 권장되는 동작입니다. 만약 일반 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 2027-01-09.

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에 있는 가상 호스트의 복사본인 example.com-le-ssl.conf를 생성하여 SSLEngine on 및 인증서 경로를 추가했으며, 이를 활성화하고, 기존 80번 포트 가상 호스트에 모든 요청을 HTTPS로 301 리다이렉트하는 RewriteRule 블록을 추가했습니다. 기존 가상 호스트 파일은 대체되지 않고 수정되었으며, SSL 쌍은 그 옆에 생성되어 추가된 모든 줄을 확인할 수 있습니다.

인증서가 실제로 저장되는 위치와 인증서를 복사하면 안 되는 이유

모든 파일은 /etc/letsencrypt/live/example.com/ 아래에 저장됩니다. fullchain.pem는 서버가 참조해야 할 인증서와 중간 인증서 체인을 포함하며, privkey.pem은 root 사용자만 읽을 수 있는 개인 키입니다. 또한 cert.pem과 chain.pem은 각 구성 요소를 별도로 요구하는 소프트웨어를 위해 존재합니다. 이 파일들은 /etc/letsencrypt/archive/ 내부를 가리키는 심볼릭 링크이며, 이러한 간접 참조 방식이 갱신 메커니즘의 핵심입니다. 갱신이 발생하면 archive/에 새로운 파일이 생성되고 심볼릭 링크가 이를 다시 가리키도록 변경됩니다. 다른 소프트웨어가 live/ 경로를 참조하도록 설정하면 갱신 시마다 자동으로 최신 인증서를 불러옵니다. 만약 파일을 다른 곳으로 복사해 두면 90일 뒤 인증서가 만료될 때 서비스 중단이 발생합니다.

알아두어야 할 또 다른 파일은 /etc/letsencrypt/renewal/example.com.conf입니다. 이 파일에는 인증서 발급 방식, authenticator = apache, installer = apache, 도메인 정보가 기록되어 있습니다. 이를 통해 Apache 재시작을 포함한 갱신 과정을 자동으로 반복할 수 있습니다.

갱신은 이미 예약되어 있으므로 확인만 하고 별도로 설정하지 마십시오

Let's Encrypt 인증서는 설계상 기본적으로 90일 동안 유효하며, apt 패키지는 이미 필요한 메커니즘을 설치해 두었습니다. 이는 하루에 두 번 무작위 시간에 실행되어 만료 30일 이내의 인증서를 갱신하는 systemd 타이머입니다. 별도의 cron 작업을 추가하지 마십시오. 두 번째 스케줄러는 로그 노이즈와 속도 제한(rate-limit) 노출 외에는 아무런 이득이 없습니다. Let's Encrypt는 2027년 2월 10일부터 신규 인증서의 기본 유효 기간이 64일로 변경된다고 발표했습니다. 30일 갱신 주기는 그대로 유지되므로, 갱신 시점이 60일 차가 아닌 34일 차 근처로 당겨질 뿐이며 서버에서 변경해야 할 사항은 없습니다.

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

첫 번째 명령은 타이머가 활성화되어 있으며 향후 24시간 이내에 다음 실행 시간이 예정되어 있음을 보여줍니다. 스케줄은 무작위 지연 시간을 포함하여 하루 두 번 실행되므로 정확한 시간은 의도적으로 예측할 수 없게 되어 있습니다(snap 설치의 경우 타이머는 snap.certbot.renew.timer입니다). dry run은 Let's Encrypt의 스테이징 환경에서 전체 갱신 과정을 연습하며, 실제 챌린지를 수행하지만 인증서가 발급되지는 않으므로 속도 제한에 영향을 주지 않습니다. 올바른 결과는 다음 문구로 끝납니다:

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

dry run이 실패하면 약 60일 뒤의 실제 갱신도 동일하게 실패할 것이므로, 현재 인증서의 유효 기간이 충분히 남아 있는 지금 문제를 해결해야 합니다. 가장 흔한 원인은 인증서 발급 이후 방화벽 규칙이 추가되어 80번 포트가 다시 닫힌 경우입니다.

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

첫 번째 명령은 Certbot이 설치한 리다이렉트 설정에 따라 Location: https://example.com/ 헤더와 함께 HTTP/1.1 301 Moved Permanently를 반환해야 합니다. 두 번째 명령은 curl에서 TLS 관련 오류 없이 HTTP/1.1 200 OK을 반환해야 합니다. 세 번째 명령은 발급자 정보를 출력하며, YE1 또는 YE2(ECDSA 키 사용 시), 혹은 YR1 또는 YR2(RSA 키 사용 시)과 같은 짧은 CN을 포함한 O = Let's Encrypt 라인과 약 90일 뒤의 notAfter 만료일을 보여줍니다. Let's Encrypt가 이전 중간 인증서를 폐기하기 전에 발급된 인증서는 다음 갱신 시점까지 R12 또는 E7와 같은 CN을 계속 표시할 수 있으며, 이는 오류가 아닙니다. 브라우저에서는 자물쇠 아이콘이 표시되며, 이를 클릭하면 동일한 발급자 정보를 확인할 수 있습니다. curl 명령은 정상적으로 작동하는데 브라우저에서 경고가 발생한다면, 이는 인증서 문제가 아니라 캐시된 페이지를 보고 있거나 잘못된 호스트 이름을 입력했을 가능성이 매우 높습니다.

여러 사이트: SAN 인증서 하나 또는 사이트당 인증서 하나

두 방식 모두 가능하며 갱신 방법도 동일합니다. 같은 서버에서 서로 관련 없는 사이트를 운영한다면 사이트마다 발급 명령을 한 번씩 실행하십시오. 각 사이트는 live/ 아래에 고유한 디렉터리와 갱신 설정을 갖게 되며, 한 도메인에 문제가 생겨도 다른 도메인의 갱신을 방해하지 않습니다. 이것이 제가 권장하는 기본 방식입니다.

여러 도메인 이름을 가진 하나의 사이트라면 SAN 인증서 하나에 모두 포함하십시오. 하나의 인증서에 최대 100개의 이름을 담을 수 있습니다. 위에서 example.com와 www.example.com를 사용하여 이미 이 작업을 수행했습니다. 나중에 기존 인증서에 이름을 추가하려면, 인증서 이름과 전체 새 목록을 지정하여 재발급하십시오.

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

Certbot은 도메인 구성이 변경된 것을 감지하고 확장 확인을 요청합니다. 이후 기존 live/ 경로에 있는 인증서를 그대로 교체하므로 다른 설정을 수정할 필요가 없습니다. 목록은 추가가 아닌 교체 방식이라는 점에 유의하십시오. 해당 명령에서 www을 생략하면 새 인증서에서 해당 도메인이 자동으로 제외됩니다.

와일드카드 인증서에는 DNS-01이 필요하며, 일반적으로 와일드카드는 필요하지 않습니다

HTTP-01은 *.example.com을 발급할 수 없습니다. 웹 서버에 파일을 배치하는 방식은 특정 호스트 이름에 대한 제어권만 증명할 뿐, 전체 네임스페이스에 대한 제어권을 증명하지 못하기 때문입니다. 와일드카드 인증서에는 DNS-01 챌린지가 필요합니다. Certbot은 _acme-challenge.example.com에 TXT 레코드를 설정하는데, 이는 실제 환경에서 DNS 공급자의 API 자격 증명을 사용하는 certbot-dns-* 플러그인이 필요하거나, 갱신할 때마다 --manual을 사용하여 TXT 레코드를 직접 수정해야 함을 의미합니다(매우 번거로우므로 이 방식을 계획하지 마십시오). TXT 레코드의 작동 원리부터 무인 갱신을 지원하는 플러그인 설정까지의 전체 과정은 Certbot을 이용한 DNS-01 기반 와일드카드 인증서에서 확인할 수 있습니다. 솔직한 조언을 드리자면, 알고 있는 서브도메인이 4개라면 4개를 모두 나열한 SAN 인증서를 사용하는 것이 와일드카드보다 간단하며, 서버에 DNS API 키를 보관할 필요도 없습니다.

실패 유형 및 확인되는 메시지

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 설정에 문제가 있으면 즉시 중단합니다. \n은 Certbot이 예외의 repr을 출력하기 때문에 나타나는 문자열입니다. 직접 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.

이는 앞서 언급한 ServerName 누락으로 인한 실패이며, 인증서 발급 시점에 확인됩니다. Certbot은 활성화된 모든 80번 포트 vhost를 검색하여 귀하의 -d과 일치하는 ServerName/ServerAlias을 찾지만, 아무것도 발견하지 못합니다. sudo apache2ctl -S를 실행하면 Apache가 실제로 어떤 경로로 요청을 처리하는지 확인할 수 있습니다. 올바른 vhost에 ServerName 줄을 추가하고 설정을 다시 불러온 뒤 재시도하십시오. 이와 유사한 문제로 검증 요청이 잘못된 vhost에 도달하는 경우가 있습니다. 다른 사이트가 요청을 가로채기 때문에 챌린지 응답이 Invalid response ... 404로 돌아옵니다. 진단 방법과 도구는 동일합니다: apache2ctl -S를 사용하십시오.

검증 시간 초과

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

Let's Encrypt가 귀하의 DNS가 가리키는 주소의 80번 포트로 TCP 연결을 맺지 못했습니다. 가능성이 높은 순서대로 나열하면 다음과 같습니다: 호스팅 패널에서 설정하는 제공업체의 네트워크 방화벽(ufw와는 별개), 443번 포트나 SSH만 허용하는 ufw 규칙, 또는 DNS가 여전히 이전 서버를 가리키는 경우입니다. 단순히 AAAA 레코드가 오래된 것만으로는 보통 이 문제가 발생하지 않습니다. IPv6 시도가 시간 초과되면 Let's Encrypt가 IPv4로 재시도하기 때문입니다. AAAA 레코드 문제는 보통 잘못된 서버로부터 Connection refused이나 Invalid response 오류가 발생하는 형태로 나타납니다. VPS 외부에서 테스트하십시오. 노트북에서 curl -I http://example.com를 실행하면 검증 서버가 보는 것과 동일한 환경을 재현할 수 있습니다.

재시도로 인한 속도 제한(Rate limit) 도달

Error creating new order :: too many failed authorizations (5) for "example.com" in the last 1h0m0s, retry after ... UTC: see https://letsencrypt.org/docs/rate-limits/...

Let's Encrypt는 호스트명당, 계정당 시간당 5회의 검증 실패를 허용합니다. 이는 약 12분마다 1회씩 복구되는 버킷 방식이며, 방화벽 문제로 실패하는 상황에서 계속 재시도하면 금방 제한에 도달합니다. 기다리는 것도 방법이지만, 근본적인 해결책은 습관을 바꾸는 것입니다. 실패가 발생하면 성공할 때까지 스테이징 환경에서 디버깅하십시오.

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은 자체적인 관대한 제한을 가지며 실제 인증서를 발급하지 않는 스테이징 환경을 대상으로 검증하므로, 오후 내내 실패해도 괜찮습니다. 스테이징에서 성공한 후에만 실제 명령을 다시 실행하십시오. 등록된 도메인당 주당 50개의 인증서 발급 제한이나, 동일한 이름 세트에 대한 주당 5개의 중복 발급 제한은 스크립트가 반복적으로 재발급을 시도하지 않는 한 도달하기 어렵습니다.

HTTPS 설정이 완료되면 인증서는 서버가 아닌 전송 구간을 보호한다는 점을 기억하십시오. 22번 포트는 여전히 하루 종일 비밀번호 추측 공격에 노출되어 있습니다. 이 설정을 Ubuntu 24.04의 Fail2ban과 연동하는 것은 다음 30분 동안 수행해야 할 당연한 작업입니다.

FAQ

Ubuntu 24.04의 Apache 환경에서 Certbot을 snap으로 설치해야 합니까, apt로 설치해야 합니까?

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

Certbot이 "Unable to find a virtual host listening on port 80" 오류를 내는 이유는 무엇입니까?

활성화된 포트 80 가상 호스트(vhost) 중에 -d으로 전달한 도메인과 일치하는 ServerName나 ServerAlias가 없기 때문입니다. Ubuntu의 기본 가상 호스트 설정은 ServerName이 주석 처리된 상태로 제공됩니다. sudo apache2ctl -S을 실행하여 해당 도메인을 관리할 가상 호스트를 찾거나 생성하고, ServerName example.com를 추가한 뒤 Apache를 리로드하고 Certbot을 다시 실행하십시오.

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

Let's Encrypt가 귀하의 DNS에 게시된 주소의 포트 80에 도달할 수 없는 상태입니다. ufw뿐만 아니라 서비스 제공업체의 패널 수준 네트워크 방화벽도 확인하십시오. dig +short example.com이 현재 VPS를 가리키는지 확인하고, 오래된 AAAA 레코드가 있다면 수정하거나 삭제하십시오. 검증 과정은 IPv6를 먼저 시도하며 타임아웃 이후에만 IPv4로 전환하기 때문입니다. 서버 외부에서 curl -I http://example.com을 사용하여 해결 여부를 확인한 뒤, 실제 발급 전에 sudo certbot certonly --apache --dry-run -d example.com로 모의 테스트를 진행하십시오.

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

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

Certbot과 Apache로 와일드카드 인증서를 받으려면 어떻게 해야 합니까?

와일드카드는 DNS-01 챌린지가 필요합니다. Certbot이 _acme-challenge.example.com에 TXT 레코드를 생성해야 하므로, DNS 제공업체의 API 자격 증명을 사용하는 certbot-dns-* 플러그인이 필요합니다(--manual 대안은 갱신할 때마다 수동으로 TXT 레코드를 수정해야 합니다). 알려진 서브도메인이 몇 개뿐이라면, 서브도메인을 명시적으로 나열하는 SAN 인증서가 더 간단하며 서버에 DNS API 키를 저장할 필요도 없습니다.

#certbot #apache #lets-encrypt #tls #ubuntu