와일드카드 무료 SSL 인증서 자동 갱신 적용 방법 (Let’s Encrypt + acme-dns)

와일드카드 SSL 자동 갱신은 DNS 관리 권한이 분리된 서버 환경에서 구성하기 까다로운 작업 중 하나입니다.

최근 SSL 인증서의 유효기간이 단계적으로 단축되면서 인증서 갱신 자동화의 중요성도 커지고 있습니다. 특히 Let’s Encrypt 무료 와일드카드 인증서는 DNS-01 인증이 필수이기 때문에,

DNS API를 사용할 수 없는 환경에서는 갱신할 때마다 TXT 레코드를 수동으로 변경해야 하는 불편함이 있습니다.

이번에는 기존 네임서버를 유지하면서 acme-dns를 이용해 이러한 문제를 해결한 구축 과정을 정리했습니다.

1. SSL 인증서 유효기간 단축, 무엇이 달라지나?

2025년 CA/Browser Forum은 공개 TLS 인증서의 최대 유효기간을 단계적으로 단축하는 정책을 승인했습니다.

2026년 10월 기준 인증서 최대 유효기간과 향후 변경 일정은 다음과 같습니다.

이는 공개적으로 신뢰되는 TLS 인증서에 적용되는 업계 최대 유효기간입니다. 실제 인증서 유효기간은 인증기관의 정책에 따라 더 짧을 수 있습니다.

무료 SSL 인증서 발급기관인 Let’s Encrypt도 유효기간 단축 계획을 발표했습니다.

적용 시점	Let’s Encrypt 기본 인증서 유효기간
2026년 10월 현재	90일
2027년 2월 10일부터	64일 예정
2028년 2월 16일부터	45일 예정

인증서 유효기간이 짧아지는 이유는 보안 때문입니다. 인증서의 개인키가 유출되거나 잘못된 인증서가 발급됐을 때 해당 인증서가 유효하게 사용될 수 있는 기간을 줄일 수 있습니다.

반면 서버 운영자 입장에서는 인증서 갱신 주기가 짧아지는 만큼 관리 부담이 증가합니다.

갱신을 수동으로 처리하는 환경이라면 작업 누락으로 인증서가 만료될 위험도 커집니다.

따라서 앞으로는 무료 인증서와 유료 인증서를 구분하기보다 인증서 갱신과 서비스 반영 과정이 자동화되어 있는지가 더욱 중요해질 것으로 보입니다.

2. 와일드카드 SSL 인증서는 왜 자동 갱신이 어려울까?

Let’s Encrypt 인증서를 발급할 때 일반적으로 사용하는 인증 방식은 HTTP-01과 DNS-01입니다.

HTTP-01(Webroot) 방식

웹서버의 특정 경로에 인증 파일을 생성하고, Let’s Encrypt가 해당 파일에 접근하여 도메인 소유 여부를 확인합니다.

예를 들어 다음 경로를 사용합니다.

http://www.example.com/.well-known/acme-challenge/인증값

외부에서 웹서버의 80번 포트에 접근할 수 있다면 Certbot으로 비교적 간단하게 자동 갱신을 구성할 수 있습니다.

하지만 HTTP-01 방식은 와일드카드 인증서를 발급할 수 없습니다.

DNS-01 방식

DNS에 TXT 레코드를 등록하여 도메인 소유 여부를 확인하는 방식입니다.

_acme-challenge.example.com

와일드카드 인증서를 발급하려면 DNS-01 인증이 필요합니다.

예를 들어 다음과 같은 인증서를 발급하는 경우입니다.

example.com
*.example.com

이렇게 발급하면 www.example.com, shop.example.com, mall.example.com 등 한 단계 하위 서브도메인을 하나의 인증서로 보호할 수 있습니다.

고객 계정을 생성할 때마다 새로운 서브도메인이 추가되는 서비스에서는 와일드카드 인증서가 특히 유용합니다.

문제는 DNS 인증에 사용되는 TXT 값이 인증 과정에서 새롭게 생성된다는 점입니다.

DNS API를 사용할 수 없는 환경에서는 인증서를 갱신할 때마다 다음 작업을 반복해야 합니다.

Certbot에서 새 인증값 생성
DNS 관리자에게 TXT 레코드 변경 요청
DNS 전파 대기
Let’s Encrypt 인증 진행
인증서 갱신 후 웹서버 반영

인증서 유효기간이 90일에서 45일로 줄어들면 이러한 작업의 빈도도 늘어나게 됩니다.

이 문제를 해결하기 위해 적용한 방법이 acme-dns를 이용한 DNS 인증 위임입니다.

3. acme-dns란?

acme-dns는 ACME DNS-01 인증을 처리하기 위해 만들어진 경량 DNS 서버입니다.

일반적인 DNS 서버와 달리 인증서 발급에 필요한 TXT 레코드 관리에 집중한 서비스이며, API를 통해 TXT 값을 자동으로 변경할 수 있습니다.

공개 테스트 및 활용이 가능한 서비스로 auth.acme-dns.io가 있으며, 필요하다면 별도 서버에 acme-dns를 직접 구축할 수도 있습니다.

핵심은 기존 DNS 서버의 관리자 권한이 필요하지 않다는 점입니다.

기존 DNS 관리자는 인증에 필요한 레코드 한 개만 최초에 설정하면 됩니다.

이후 인증서 갱신 시에는 Certbot이 acme-dns API를 통해 TXT 레코드를 자동으로 등록합니다.

DNS 위임의 동작 원리

일반적으로 도메인은 다음과 같은 DNS 레코드를 사용합니다.

A 레코드: 웹서버 IP 주소
MX 레코드: 메일 서버 정보
NS 레코드: 권한 네임서버
TXT 레코드: 도메인 인증 및 기타 정보

acme-dns를 도입한다고 해서 이러한 레코드를 다른 DNS 서버로 이전할 필요는 없습니다.

기존 네임서버는 그대로 사용하고, _acme-challenge에 대한 인증 조회만 다른 DNS 서버로 연결합니다.

예를 들어 다음과 같이 설정합니다.

_acme-challenge.example.com.  IN CNAME  고유식별자.auth.acme-dns.io.

이후 Let’s Encrypt가 _acme-challenge.example.com의 TXT 값을 조회하면 CNAME을 따라 acme-dns에서 관리하는 TXT 값을 확인하게 됩니다.

정리하면 다음과 같습니다.

일반 웹사이트 접속

사용자 → 기존 DNS 서버 → 웹서버

SSL 인증서 갱신

Certbot → acme-dns API → 인증용 TXT 등록 → Let’s Encrypt 검증

기존 웹사이트와 메일 서비스를 위한 DNS 구성에는 영향을 주지 않고, 인증서 갱신에 필요한 DNS 작업만 분리할 수 있습니다.

단, 최초 CNAME 등록 과정에서는 동일한 이름에 기존 TXT 레코드가 있는지 확인하고 정리해야 합니다. 동일한 DNS 이름에는 일반적으로 CNAME과 다른 레코드를 함께 둘 수 없습니다.

4. acme-dns를 이용한 와일드카드 인증서 자동 갱신 구성

실제 운영 환경에서는 기존 와일드카드 인증서를 유지하면서 인증 방식만 자동화하는 방향으로 작업했습니다.

기존 인증서를 삭제하고 다시 구성하기보다는 현재 인증서의 이름과 경로를 유지하는 편이 웹서버 설정 변경을 최소화할 수 있기 때문입니다.

작업 과정은 다음과 같습니다.

4-1. 기존 인증서 및 웹서버 설정 확인

먼저 Certbot과 웹서버 상태를 확인합니다.

certbot --version
certbot certificates
apachectl -t
apachectl -S

기존 인증서의 도메인과 만료일도 확인합니다.

openssl x509 \
  -in /etc/letsencrypt/live/example.com/cert.pem \
  -noout -dates -ext subjectAltName

기존 인증서가 example.com과 *.example.com을 모두 포함하는지 확인해야 합니다.

이후 작업에 앞서 /etc/letsencrypt와 Apache 설정을 백업합니다.

인증서 백업에는 개인키가 포함될 수 있으므로 백업 디렉터리와 파일 권한을 제한해야 합니다.

4-2. acme-dns 계정 등록

acme-dns에 인증용 계정을 등록하면 고유한 DNS 주소와 API 인증 정보가 발급됩니다.

공식 프로젝트에서는 Certbot 연동을 위한 클라이언트 및 인증 훅 구현 예제를 제공합니다.

계정 등록 과정에서 생성되는 정보에는 고유 서브도메인과 TXT 레코드 변경에 필요한 인증 정보가 포함됩니다.

이 중 API 인증 정보는 서버 내부에 안전하게 보관하고, 외부에 공개하지 않아야 합니다.

4-3. 기존 DNS에 CNAME 등록

acme-dns 계정을 등록한 뒤 DNS 관리자에게 CNAME 설정을 요청합니다.

_acme-challenge.example.com. IN CNAME 고유식별자.auth.acme-dns.io.

여기서 고유식별자는 acme-dns에서 실제 발급한 값으로 변경해야 합니다.

이 단계가 기존 DNS 관리자에게 요청해야 하는 최초 설정 작업입니다.

CNAME 등록이 끝난 뒤에는 인증서를 갱신할 때마다 DNS 관리자에게 TXT 레코드 변경을 요청할 필요가 없습니다.

단, CNAME 대상 또는 acme-dns 계정이 변경되는 경우에는 다시 설정해야 할 수 있습니다.

4-4. DNS 위임 상태 확인

DNS 설정이 완료됐다면 권한 네임서버와 공개 DNS를 통해 확인합니다.

dig @1.1.1.1 CNAME _acme-challenge.example.com +short

dig @8.8.8.8 CNAME _acme-challenge.example.com +short

dig @1.1.1.1 TXT _acme-challenge.example.com +short

CNAME이 등록된 주소를 정상적으로 반환하고, acme-dns에 등록한 TXT 값이 조회되면 DNS 연결을 확인할 수 있습니다.

이때 단순히 CNAME이 조회되는 것뿐 아니라 acme-dns API를 통해 TXT 값을 실제로 변경할 수 있는지까지 확인하는 것이 좋습니다.

4-5. TXT 레코드 자동 등록 테스트

example.com과 *.example.com을 함께 발급하는 경우에는 DNS 인증값 두 개가 필요할 수 있습니다.

두 도메인의 인증 레코드 이름이 모두 _acme-challenge.example.com이기 때문입니다.

acme-dns는 이러한 상황을 처리하기 위해 TXT 레코드 두 개를 순환 갱신하는 기능을 지원합니다.

인증 훅을 구성할 때는 각각의 인증값이 정상 등록되고 동시에 조회되는지 확인해야 합니다.

실제 테스트에서는 다음 과정을 점검했습니다.

acme-dns API 연결
첫 번째 TXT 값 등록
두 번째 TXT 값 등록
공개 DNS에서 TXT 두 개 조회
Let’s Encrypt 시험 인증 진행

TXT 등록이 성공하더라도 Let’s Encrypt 인증까지 반드시 성공한다는 의미는 아닙니다. DNS 전파와 인증 과정 전체를 시험해야 합니다.

4-6. Let’s Encrypt 시험 인증

Certbot의 --dry-run 옵션을 이용하면 운영 인증서를 교체하지 않고 시험 인증을 진행할 수 있습니다.

다음은 인증 훅이 별도로 설치되어 있다는 전제의 명령 예시입니다.

certbot certonly \
  --manual \
  --preferred-challenges dns \
  --manual-auth-hook "/usr/local/sbin/acmedns-hook.sh auth" \
  --manual-cleanup-hook "/usr/local/sbin/acmedns-hook.sh cleanup" \
  --dry-run \
  -d example.com \
  -d '*.example.com'

acmedns-hook.sh는 acme-dns 계정 정보를 이용해 TXT 값을 등록하도록 구현한 스크립트의 예시 경로입니다. 실제 사용 시에는 해당 환경에 맞는 인증 훅을 준비해야 합니다.

운영 중인 Certbot 인증서에 영향을 주지 않으려면 시험용 config-dir, work-dir, logs-dir를 별도로 지정하는 방법도 있습니다.

시험이 정상적으로 완료되면 다음과 같은 메시지를 확인할 수 있습니다.

The dry run was successful.

실제 작업에서는 기본 도메인과 와일드카드 도메인 모두 DNS-01 인증에 성공하는 것을 확인한 뒤 운영 인증서 갱신을 진행했습니다.

4-7. 기존 와일드카드 인증서 갱신

시험 인증에 성공하면 실제 운영 인증서를 갱신합니다.

기존 인증서 이름을 유지하면 Apache에서 참조하는 인증서 경로를 변경하지 않아도 됩니다.

갱신이 완료되면 다음 항목을 다시 확인합니다.

certbot certificates

openssl x509 \
  -in /etc/letsencrypt/live/example.com/cert.pem \
  -noout -dates -ext subjectAltName

기존 와일드카드 도메인이 그대로 포함되어 있는지, 인증서 만료일이 연장됐는지 확인합니다.

또한 Certbot의 갱신 설정에 DNS 인증 훅이 저장되었는지 확인해야 합니다.

authenticator = manual
manual_auth_hook = /usr/local/sbin/acmedns-hook.sh auth
manual_cleanup_hook = /usr/local/sbin/acmedns-hook.sh cleanup

여기서 manual이라고 표시되더라도 인증 훅이 자동으로 DNS 작업을 수행하도록 구성했다면 비대화형 갱신이 가능합니다.

단, 실제로 자동 갱신이 가능한지는 certbot renew --dry-run으로 검증해야 합니다.

5. Certbot 자동 갱신 및 Apache 자동 반영

인증서 발급이 끝났다고 모든 작업이 완료된 것은 아닙니다.

인증서 파일이 갱신되더라도 Apache가 기존 인증서를 메모리에 유지하고 있다면 실제 HTTPS 서비스에서는 이전 인증서가 계속 표시될 수 있습니다.

따라서 인증서 갱신 이후 웹서버가 새로운 인증서를 다시 읽도록 구성해야 합니다.

자동 갱신 예약

운영 환경에서는 cron을 이용해 하루 두 번 인증서 갱신 여부를 확인하도록 구성했습니다.

17 3,15 * * * root /usr/bin/flock -n /var/lock/acme-renew.lock /usr/bin/certbot renew --cert-name example.com --deploy-hook /usr/local/sbin/acmedns-deploy.sh >> /var/log/acme-renew.log 2>&1

위 명령은 예시이며, acmedns-deploy.sh는 별도로 구현·검증한 Apache 반영 스크립트가 있어야 합니다.

주요 설정의 목적은 다음과 같습니다.

--cert-name: 지정한 인증서만 갱신
flock: 중복 실행 방지
--deploy-hook: 인증서 갱신 성공 후 명령 실행
로그 리다이렉션: 실행 결과 및 오류 기록

cron은 하루 두 번 실행되지만 인증서를 매번 새로 발급하는 것은 아닙니다.

Certbot이 갱신 필요 여부를 판단하며, 갱신이 필요하지 않으면 기존 인증서를 유지합니다.

인증서 유효기간이 앞으로 더 짧아지는 점을 고려하면 특정 날짜에 강제로 갱신하도록 만들기보다는 Certbot의 갱신 판단 기능을 활용하는 편이 관리하기 수월합니다.

Apache 인증서 자동 반영

인증서 갱신 성공 시에는 다음 명령을 통해 Apache에 신규 인증서를 반영할 수 있습니다.

apachectl -t
apachectl -k graceful

apachectl -t로 설정 문법을 먼저 확인하고, 문제가 없을 때 graceful 방식으로 반영합니다.

운영 스크립트에서는 단순히 graceful을 실행하는 것에서 끝내지 않고, 반영된 인증서가 실제 파일과 동일한지도 확인하도록 구성하는 것이 좋습니다.

openssl s_client를 이용하면 특정 도메인에서 제공하는 인증서를 확인할 수 있습니다.

openssl s_client \
  -connect 127.0.0.1:443 \
  -servername www.example.com \
  </dev/null 2>/dev/null | \
  openssl x509 -noout -dates -fingerprint -sha256

이렇게 확인한 인증서 지문을 실제 갱신된 인증서 파일의 지문과 비교하면 Apache가 새로운 인증서를 정상적으로 사용하고 있는지 검증할 수 있습니다.

실제 적용 과정에서도 대표 도메인과 여러 서브도메인에 대해 인증서 지문을 비교하고 정상 반영 여부를 확인했습니다.

6. 운영 환경에서 확인해야 할 사항

구축 과정에서 몇 가지 주의할 부분이 있었습니다.

① 인증서 갱신 성공과 웹서버 반영 성공은 다르다

Certbot에서 인증서 갱신에 성공하더라도 웹서버가 기존 인증서를 계속 제공할 수 있습니다.

따라서 인증서 만료일뿐 아니라 실제 HTTPS 연결에서 반환하는 인증서까지 검증해야 합니다.

② Dry-run에서는 배포 훅이 실행되지 않을 수 있다

Certbot 버전에 따라 시험 갱신 과정에서 다음 메시지가 나타날 수 있습니다.

Dry run: skipping deploy hook command

인증 시험은 성공했지만 인증서 반영 훅은 실행되지 않았다는 뜻입니다.

이 경우 배포 훅을 별도로 시험해 Apache graceful과 인증서 검증 기능까지 확인해야 합니다.

③ DNS 전파 시간을 고려해야 한다

acme-dns에 TXT 값을 등록한 직후 모든 DNS 조회 경로에서 새로운 값이 확인되는 것은 아닙니다.

인증 훅에 적절한 DNS 전파 대기 및 재조회 기능이 필요합니다.

특히 기본 도메인과 와일드카드 도메인을 함께 갱신할 때는 두 TXT 값이 정상적으로 유지되는지 확인해야 합니다.

④ acme-dns 인증 정보는 반드시 백업해야 한다

acme-dns 인증 정보가 분실되면 기존 계정으로 TXT 값을 변경할 수 없게 될 수 있습니다.

계정을 다시 생성하면 위임 대상 CNAME도 변경해야 할 수 있으므로, 인증 정보는 접근 권한을 제한하여 안전하게 백업해야 합니다.

이 정보는 전체 DNS 관리 권한과는 다르지만, 위임된 도메인의 인증서 발급에 사용될 수 있는 중요한 권한입니다.

⑤ 공개 acme-dns 서비스의 안정성을 고려해야 한다

auth.acme-dns.io와 같은 공개 서비스를 이용하면 별도의 DNS 서버 구축 없이 자동화를 시작할 수 있습니다.

다만 외부 서비스에 의존하므로 서비스 장애, 계정 정보 유실, 보안 문제 등이 발생하면 인증서 갱신에 영향을 받을 수 있습니다.

운영 중요도가 높은 환경이라면 자체 acme-dns 구축이나 관리되는 별도 DNS 인증 환경을 고려하는 것이 좋습니다.

인증서 만료일 모니터링과 갱신 실패 알림도 함께 운영하는 것을 권장합니다.

7. 적용 결과

이번 구성에서는 기존 네임서버와 웹서버 설정을 유지한 상태에서 DNS 인증에 필요한 부분만 acme-dns로 위임했습니다.

작업 후 다음 항목을 확인했습니다.

기존 와일드카드 인증서 유지
DNS 관리자 요청은 최초 CNAME 설정 1회
acme-dns를 통한 TXT 자동 등록 확인
Let’s Encrypt DNS-01 시험 인증 성공
운영용 와일드카드 인증서 실제 갱신 성공
기존 인증서 경로 유지
Apache 신규 인증서 반영 확인
대표 서브도메인 HTTPS 인증서 검증
cron 자동 갱신 등록 및 시험 완료

기존에는 인증서 갱신마다 DNS 관리자에게 TXT 레코드 변경을 요청해야 했지만, 자동화 구성 이후에는 해당 과정이 Certbot과 acme-dns를 통해 처리되도록 변경했습니다.

최초 구성과 갱신 시험은 정상적으로 완료됐으며, 이후 정기 갱신의 성공 여부는 운영 로그와 만료일 모니터링을 통해 지속적으로 확인해야 합니다.

마치며

무료 SSL 인증서는 비용 부담이 없다는 장점이 있지만, 갱신 체계가 갖춰져 있지 않으면 오히려 관리 부담이 커질 수 있습니다.

특히 와일드카드 인증서는 DNS-01 방식이 필수이기 때문에 DNS 관리 권한이 분리된 환경에서는 자동 갱신 구성이 쉽지 않은 편입니다.

acme-dns를 사용하면 기존 네임서버를 변경하거나 전체 DNS 관리 권한을 서버에 제공하지 않고도 이러한 문제를 해결할 수 있습니다.

인증서 유효기간이 계속 짧아지는 추세를 고려하면 앞으로는 인증서 발급 자체보다 갱신, 서비스 반영, 장애 감지까지 자동화하는 것이 중요합니다.

다만 자동 갱신은 한 번 설정했다고 끝나는 작업은 아닙니다. 인증 서비스의 가용성, 인증 정보 백업, 웹서버 반영 여부를 지속적으로 점검해야 안정적으로 운영할 수 있습니다.

Certbot Hook으로 Let’s Encrypt 갱신 시 80번 포트 임시 허용하기

참고 자료

※ 이 글은 AI의 도움을 받아 작성 되었습니다.

와일드카드 무료 SSL 인증서 자동 갱신 방법 | Let’s Encrypt acme-dns 설정