CAA 레코드가 이미 발급된 인증서도 보호하나요?

아니요. CA는 발급 시점에만 CAA를 확인하고, 브라우저는 아예 읽지 않습니다. CAA는 이미 존재하는 인증서를 폐기하거나 차단하지 못하며, 오직 새 발급만 통제합니다.

CAA를 고쳤는데도 발급이 계속 실패합니다. 왜인가요?

Baseline Requirements는 CA가 CAA 결과를 레코드 TTL과 8시간 중 더 긴 시간 동안 유효한 것으로 캐싱하도록 허용합니다. 그 시간이 지나길 기다리고, 다음 변경 전에는 TTL을 미리 낮추며, 상위 도메인에 충돌하는 레코드가 남아 있지 않은지 확인하세요.

issue만 설정하고 issuewild를 두지 않으면 와일드카드는 허용되나요?

네. issuewild가 없으면 와일드카드 발급은 issue 속성을 따릅니다. 일반 인증서는 허용하되 와일드카드만 막으려면 issuewild ";" 를 추가하세요.

조회수: 31

CAA 레코드로 인증서 발급 CA 제한하기

CAA DNS 레코드로 도메인 인증서를 발급할 수 있는 CA를 제한하고, 정상 갱신까지 막아버리는 상위 도메인·캐시 함정을 피하는 방법입니다.

내 도메인에 이 문제가 있는지 지금 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.

Problem

도메인 인증서를 어떤 CA가 발급할 수 있는지 직접 정하고 싶거나, 방금 인증서 요청이 CAA record for <domain> prevents issuance 로 실패해 원인 레코드를 찾아야 하는 상황입니다. CAA 레코드는 “이 이름은 누가 발급할 수 있는가”라는 단 하나의 질문에 답하는 DNS 항목이며, 공개 신뢰 CA는 2017년 9월 8일부터 이 레코드를 의무적으로 준수해야 합니다.

Symptoms

ACME 클라이언트(Let’s Encrypt, ZeroSSL 등)가 urn:ietf:params:acme:error:caa 또는 CAA record for <domain> prevents issuance 를 반환합니다.
지난 분기까지 잘 되던 갱신이, DNS는 그대로인데 지금은 실패합니다.
새로 바꾼 CA는 발급하지 못하는데, 이전 CA는 발급할 수 있었습니다.
CAA 레코드가 아예 없어서, 수백 개 신뢰 CA 중 어느 곳이든 도메인 인증서를 발급할 수 있습니다.

Top 3 Causes

레코드가 실제 발급 CA와 다른 CA를 지정함. issue "letsencrypt.org" 는 Let’s Encrypt만 허용하므로, DigiCert나 Google Trust Services를 통한 요청은 거부됩니다.
상위 도메인에 차단 레코드가 있음. CA는 트리를 거슬러 올라갑니다. 정확한 이름을 먼저 확인하고, 맨 앞 라벨을 떼어내며 apex까지 다시 확인합니다. example.com 의 CAA는 app.example.com 에 자체 레코드가 없는 한 그 서브도메인까지 통제하며, 오류 메시지는 실제로 막은 상위 도메인이 아니라 서브도메인을 가리키는 경우가 많습니다.
빈 값 또는 와일드카드 제한 값이 정확히 설정대로 동작함. issue ";" 는 모든 발급을 금지하고, issuewild ";" 는 일반 인증서는 두고 와일드카드만 막습니다. 과거 잠금 설정에서 남은 이 값들이 조용히 갱신을 멈춥니다.

Diagnose with DechoNet

DNS Lookup으로 실패한 호스트명과 apex까지의 모든 상위 라벨에 있는 CAA 레코드를 읽습니다. 차단 레코드는 오류가 가리키는 곳보다 한 단계 위에 있는 경우가 잦습니다.
SSL Certificate Check로 현재 운영 인증서를 실제로 발급한 CA를 확인해, 짐작이 아니라 진짜 발급자에 맞춰 issue 값을 설정합니다.

Resolution Checklist

실패한 호스트명에서 CAA를 조회한 뒤 apex까지 상위 도메인을 차례로 올라갑니다. CAA 레코드가 처음 나타나는 라벨이 적용되고, 그보다 위의 라벨은 무시됩니다.
CA가 요구하는 발급자 식별자를 확인하고(Let’s Encrypt는 letsencrypt.org, Google Trust Services는 pki.goog, DigiCert는 digicert.com, Sectigo는 sectigo.com) 해당 issue 항목을 추가합니다.
와일드카드 인증서가 필요하면 그에 맞는 issuewild 값을 추가합니다. 없으면 와일드카드 발급은 조용히 issue 를 따릅니다.
CAA 레코드를 변경하기 전에 TTL을 낮춥니다. 수정 후에는 CA 캐시가 만료될 때까지(레코드 TTL과 8시간 중 더 긴 시간) 기다린 다음 재시도합니다.
iodef 항목(mailto: 또는 https:// URL)을 추가해, 무단 발급 시도를 CA가 보고하도록 합니다.
중요한 영역이라면 RFC 8657의 accounturi 와 validationmethods 파라미터로 발급을 하나의 ACME 계정에 묶습니다. 이 파라미터 처리는 2027년부터 공개 CA에 의무화됩니다.

When to Escalate

DNS 제공업체 패널이 CAA 레코드(타입 257)를 만들지 못하거나 따옴표 값을 깨뜨린다면 제공업체에 문의합니다. 일부 구형 패널은 여전히 이를 제대로 다루지 못합니다.
CAA 레코드와 계정 바인딩이 명백히 올바른데도 발급이 실패하면 CA 지원팀에 문의합니다. 일부 검증 방식과 예외 케이스는 CA마다 다릅니다.
직접 수정할 수 없는 상위 영역의 CAA 레코드가 본인이 관리하는 이름을 막고 있다면, 그 상위 영역 소유자를 함께 끌어들입니다.