크롬(Chrome)이 신뢰하는 인증 기관(CA) 기업 중 절반이 자사 도메인에 대한 TLS 인증서 발급 권한에 아무런 제한을 두지 않고 있다.
크롬이 신뢰하는 44개 CA 전체의 CAA 레코드를 점검한 결과, 22곳이 CAA 제한을 전혀 설정하지 않은 것으로 확인되었다.
본 글에서는 CAA 레코드의 작동 방식과 적용 현황 측정 방법, 그리고 현재 소유한 도메인을 직접 점검할 수 있는 명령어까지 함께 살펴본다.
CAA 레코드의 역할
CAA(Certification Authority Authorization) DNS 레코드는 특정 도메인에 대한 인증서를 발급할 수 있는 CA를 지정한다. 주요 태그는 다음 세 가지다.
issue: 특정 CA가 해당 도메인의 인증서를 발급할 수 있도록 허용한다.issuewild: 특정 CA가 와일드카드 인증서를 발급할 수 있도록 명시적으로 허용한다.iodef: 거부된 발급 요청을 CA가 보고할 이메일 주소나 URL을 지정한다. 이 태그는 발급 자체를 제한하지는 않는다.
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 iodef "mailto:security@example.com"
2017년 9월 8일부터 공개적으로 신뢰받는 모든 CA는 TLS 인증서를 발급하기 전에 CAA 레코드를 반드시 확인해야 한다. CA/Browser Forum은 Ballot 187을 통해 CAA 확인을 의무화했으며, 이 규정은 현재 Baseline Requirements §4.2.2.1에 따라 적용되고 있다. 즉, CA는 "RFC 8659에 의거하여 CAA 레코드를 조회하고 처리해야 한다(MUST)."
CAA 조회는 DNS 트리를 상위로 거슬러 올라가며 수행된다. RFC 8659 §3에 따르면, CA는 요청된 호스트이름부터 시작하여 CAA 레코드를 찾을 때까지 라벨 단위로 상위 도메인으로 이동한다. 예를 들어 shop.example.com에 대한 발급 요청은 서브도메인 자체 레코드가 없는 한 example.com의 레코드를 적용받는다.
핵심은 CAA 제한이 레코드가 존재할 때만 적용된다는 점이다. DNS 계층 구조 어디에서도 CAA 레코드가 발견되지 않으면, 도메인 소유권 검증을 거친 후 어떤 공공 CA라도 인증서를 발급할 수 있다.
CA는 자사 도메인에 CAA를 사용하는가?
기술적으로 CA가 운영되는 데 CAA가 반드시 필요한 것은 아니다. 하지만 CA 스스로가 이 표준을 준수하고 있는지 궁금해졌다.
이에 주요 브라우저 루트 프로그램들이 공유 데이터베이스로 사용하는 Common CA Database (CCADB)를 활용해 Chrome Root Program에서 '포함(Included)' 상태인 모든 루트 인증서를 평가했다. 그 결과 44개 CA 기업에 걸쳐 총 101개의 루트 인증서가 도출되었다.
CCADB는 각 CA가 issue 태그에서 인식하는 도메인 이름을 정리한 CAA 식별자 보고서를 공개한다. 44개 기업은 97개의 식별자를 등록했으며, 이는 서로 다른 93개 도메인에 해당한다.
2026년 9월 28일, 두 개의 공개 DNS 리졸버인 1.1.1.1과 8.8.8.8을 사용하여 93개 고유 도메인 전체의 CAA 레코드를 조회했다.
각 쿼리의 DNS 상태 코드를 기록하고 RFC 8659 규정에 따라 DNS 트리를 탐색했다. 레코드가 없는 것으로 분류된 도메인은 두 리졸버 모두에서 정상적인 NOERROR 또는 NXDOMAIN 상태를 반환했다.
모든 도메인을 다음 두 그룹 중 하나로 분류했다.
- 제한된 도메인: CAA 레코드에 하나 이상의
issue태그가 존재함. - 제한 없는 도메인: CAA 레코드가 없거나
issue태그가 존재하지 않음. 요청자가 도메인 소유권을 입증하면 어떤 공공 CA라도 인증서를 발급할 수 있음.
참고: 이 식별자들은 각 CA가 CAA 레코드에서 인식하는 도메인을 나타내며, 보통 CA의 기본 웹사이트를 포함한다. DigiCert가 등록한 4개의 digitalcertvalidation.com 서브도메인처럼 순수하게 운영 목적으로만 쓰이는 식별자도 있다.
44개 CA 중 22곳이 CAA 제한을 두지 않음
issue 태그 상태 |
CA 기업 수 |
|---|---|
| 모든 식별자 도메인에 존재 | 17 (39%) |
| 일부 식별자 도메인에 존재 | 5 (11%) |
| 모든 식별자 도메인에 누락 | 22 (50%) |
발급 제한이 없는 22개 CA에는 Amazon Trust Services, GoDaddy, HARICA, SECOM, D-TRUST, Microsoft 등 널리 알려진 기관들이 포함되어 있다.
제한된 도메인이 없는 CA 전체 목록: Agence Nationale de Certification Electronique (TunTrust), Amazon Trust Services, ANF AC, Asseco (Certum), Atos, Buypass, CFCA, D-TRUST, eMudhra, FNMT, GDCA, GoDaddy, HARICA, Hongkong Post / Certizen, iTrusChina, KIR, Microsoft, NAVER Cloud Trust Services, SECOM, SHECA, Telia, TWCA.
이 그룹에 속한 두 CA는 발급을 완전히 제한하지 않는 CAA 레코드를 게시하고 있다.
microsoft.com: 도메인 검증 연락처를 위한contactemail태그만 포함한다.$ dig CAA microsoft.com +short 0 contactemail "caarecordaware@microsoft.com"telia.fi:issuewild ";"를 사용하여 와일드카드 인증서는 차단하지만 일반 인증서는 제한 없이 남겨두었다.
제한된 도메인과 제한 없는 도메인을 모두 가지고 있는 중간 부류(5개 CA)의 두 가지 예시는 다음과 같다.
- DigiCert:
digicert.com은 제한하지만,thawte.com,geotrust.com,rapidssl.com은 CAA 레코드 없이 제한 없는 상태로 남겨두었다. - Sectigo:
sectigo.com은 제한하지만,comodo.com,comodoca.com,usertrust.com은 제한 없는 상태로 남겨두었다.
참고로 Scott Helme의 2026년 6월 조사(Tranco 상위 100만 개 사이트 대상)에 따르면, 응답한 819,002개 도메인 중 CAA 레코드를 게시한 곳은 53,130개(6.5%)에 불과했다.
모든 도메인을 제한한 CA 비율이 39%로 일반 웹사이트보다는 높지만, 절반은 여전히 제한 없이 열어두고 있는 셈이다.
CAA 레코드 누락의 의미
CAA 레코드가 없으면 도메인 소유권 검증만 거친 후 어떤 공공 CA든 해당 도메인의 인증서를 발급할 수 있다. CAA 레코드는 지정된 CA로만 발급 권한을 엄격히 제한한다.
CA 자사 도메인을 겨냥한 무단 인증서 발급 사례가 보고된 바는 없으나, 레코드가 누락되면 자기보호를 위한 필수 CAA 검사가 무용지물이 된다.
제한된 도메인이 없는 22개 CA 중 6곳(GoDaddy, HARICA, GDCA, SHECA, CFCA, Buypass)은 2017년 Ballot 187 표결 당시 찬성표를 던졌던 곳이다. 주의할 점은, 해당 안건이 CA에게 고객의 CAA 레코드를 검사하도록 의무화했을 뿐 자사 도메인의 레코드 게시까지 의무화한 것은 아니라는 사실이다.
내 도메인의 CAA 레코드 확인하기
dig 명령어를 사용하여 소유한 도메인의 CAA 레코드를 조회해보자.
dig CAA yourdomain.com +short
응답이 비어 있다면 CAA 레코드가 존재하지 않는다는 뜻이다(쿼리 결과가 NOERROR 또는 NXDOMAIN 상태인 경우). 네트워크 오류 발생 시에도 빈 결과가 나올 수 있으므로 +short 옵션을 제거하고 전체 응답 코드를 확인하는 것이 좋다. 조회가 DNS 트리를 타고 올라가므로 서브도메인의 경우 상위 도메인도 함께 점검해야 한다.
권장 CAA 설정 방식
일반적인 CAA 레코드는 허용할 CA와 보고용 연락처를 명시한다.
yourdomain.com. CAA 0 issue "letsencrypt.org"
yourdomain.com. CAA 0 iodef "mailto:security@yourdomain.com"
- 사용 중인 모든 CA 허용: CDN이나 클라우드 제공업체가 사용하는 제3자 CA도 포함해야 한다. 그렇지 않으면 추후 인증서 갱신이 실패할 수 있다.
- 필요한 경우에만
issuewild사용: 기본issue태그만으로도 와일드카드 인증서가 자동으로 포함된다. 와일드카드 발급에 별도의 규칙이 필요한 경우에만issuewild를 사용한다. iodef주소 설정: 무단 발급 요청이 거부될 때마다 CA가 이 주소로 보고서를 전송할 수 있다.
궁금한 점이 있다. 최근에 소유한 도메인의 CAA 레코드를 확인해 본 적이 있는가?
참고 문헌
- IETF — RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record (2019년 11월)
- CA/Browser Forum — Ballot 187 – Make CAA Checking Mandatory (2017년 9월 8일 시행)
- CA/Browser Forum — Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, v2.3.0, §4.2.2.1
- CCADB — Resources: All Certificate Records and All CAA Identifiers reports (2026년 9월 28일 조회)
- Scott Helme — Top 1 Million Analysis – June 2026: The State of Crypto
- Google — Chrome Root Program Policy
Instagram