가이드

작성자 Matt Connor 2026-07-16 · 업데이트됨 2026-08-07

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

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

활성화된 80번 포트 가상 호스트(vhost) 중에 -d으로 전달한 도메인과 일치하는 ServerName 또는 ServerAlias가 없기 때문입니다. Ubuntu의 기본 vhost는 ServerName이 주석 처리된 상태로 제공됩니다. sudo apache2ctl -S을 실행하여 해당 도메인을 처리할 vhost를 찾거나 생성하고, 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 도메인, IP 주소 직접 사용은 불가능합니다. dig +short example.com은 반드시 귀하의 VPS 주소를 반환해야 하며, 최근 1시간 이내에 DNS를 변경했다면 기존 레코드의 TTL이 만료될 때까지 기다린 후 인증서를 발급받으십시오.
AAAA 레코드가 존재한다면 반드시 정확해야 합니다. Let's Encrypt는 AAAA 레코드가 게시되어 있을 경우 IPv6를 우선적으로 사용합니다. 따라서 노트북에서 IPv4로 curl를 수행했을 때는 정상적으로 작동하더라도, 오래된 AAAA 레코드가 남아있으면 검증에 실패할 수 있습니다. 정확한 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에서는 이러한 이유가 사라졌습니다. 저장소에서 최신 세대 릴리스인 Certbot 2.9.0을 제공하며, unattended-upgrades이 패치를 지속적으로 관리합니다. 해당 운영체제에서는 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

최초 실행 시 세 가지를 묻습니다. 이메일 주소(ACME 계정 및 긴급 CA 통지에 사용됩니다. Let's Encrypt는 더 이상 만료 알림을 보내지 않으므로 갱신 모니터링은 사용자의 책임입니다), Let's Encrypt 이용 약관 동의, 그리고 EFF와 이메일 주소를 공유할지 여부입니다. 이제 리다이렉트 여부를 묻지 않습니다. Certbot 2.0부터 Apache 설치 프로그램은 기본적으로 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에 인증서 경로와 SSLEngine on가 포함된 가상 호스트(vhost)의 복사본인 example.com-le-ssl.conf을 작성했으며, 이를 활성화했습니다. 또한 기존 80번 포트 가상 호스트에 모든 요청을 HTTPS로 301 리다이렉트하는 RewriteRule 블록을 추가했습니다. 기존 가상 호스트 파일은 대체되지 않고 수정되었으며, SSL 쌍(twin) 파일이 그 옆에 생성되어 추가된 모든 줄을 확인할 수 있습니다.

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

모든 파일은 /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 패키지는 이미 관련 메커니즘을 설치해 둡니다. 이는 하루에 두 번 무작위 시간에 Certbot을 실행하여 만료 30일 이내의 인증서를 갱신하는 systemd 타이머입니다. 별도의 cron 작업을 추가하지 마십시오. 두 번째 스케줄러는 로그 노이즈와 속도 제한(rate-limit) 노출 외에는 아무런 이득이 없습니다.

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이 설치한 리다이렉트 설정에 따라 HTTP/1.1 301 Moved Permanently 상태 코드와 Location: https://example.com/ 헤더를 반환해야 합니다. 두 번째 명령은 TLS 오류 없이 HTTP/1.1 200 OK 상태 코드를 반환해야 합니다. 세 번째 명령은 발급 기관 정보, O = Let's Encrypt 행, R12 또는 E7와 같은 짧은 CN(Common Name), 그리고 약 90일 뒤의 notAfter 만료일을 출력합니다. 웹 브라우저에서는 자물쇠 아이콘이 표시되며, 이를 클릭하면 동일한 발급 기관 정보를 확인할 수 있습니다. 만약 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, 또는 IPv6는 시도하지만 서버는 IPv4로만 응답하는 stale-AAAA 문제입니다. VPS 외부에서 테스트하십시오. 노트북에서 curl -I http://example.com를 실행하면 검증 서버가 보는 것과 동일한 환경을 재현할 수 있습니다.

재시도 횟수 초과로 속도 제한(rate limit)에 걸린 경우

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

Let's Encrypt는 호스트 이름당 계정별로 시간당 5회의 검증 실패를 허용합니다. 2025년 속도 제한 정책 개편 이후에는 재시도 횟수가 약 12분마다 하나씩 회복되는 버킷 방식을 사용하므로, 방화벽 문제로 계속 재시도를 반복하면 제한에 빠르게 도달합니다. 기다리는 것도 방법이지만, 근본적인 해결책은 습관을 바꾸는 것입니다. 실패 후에는 성공할 때까지 스테이징 환경에서 디버깅하십시오.

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를 통해 보안 패치를 지원하고 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의 기본 vhost는 ServerName이 주석 처리된 상태로 제공됩니다. sudo apache2ctl -S을 실행하여 해당 도메인을 처리할 vhost를 찾거나 생성하고, ServerName example.com를 추가한 뒤 Apache를 리로드하고 Certbot을 다시 실행하십시오.

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

Let's Encrypt가 DNS에 게시된 주소의 80번 포트에 접근할 수 없는 상태입니다. ufw뿐만 아니라 클라우드 제공업체의 패널 수준 네트워크 방화벽을 확인하십시오. dig +short example.com이 현재 VPS를 가리키는지 확인하고, 유효하지 않은 AAAA 레코드가 있다면 삭제하거나 수정하십시오. 검증 과정은 IPv6가 존재할 경우 이를 우선시합니다. 서버 외부에서 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