CAA 레코드란?
CAA(인증기관 승인) 레코드는 어떤 인증기관(CA)이 도메인의 SSL/TLS 인증서를 발급할 수 있는지 지정하는 DNS 레코드입니다. CAA는 CA가 침해되더라도 무단 인증서 발급을 막는 보안 통제입니다.
CAA 레코드가 중요한 이유
CAA가 없으면 신뢰할 수 있는 수백 개 CA 중 어디서든 도메인 인증서를 발급할 수 있습니다. 그 결과 CA 침해, 잘못된 발급, 사회공학 공격의 위험이 생깁니다. CAA는 발급 가능한 CA를 제한해 공격 표면을 줄입니다.
CAA의 작동 방식
1. 도메인 소유자 게시: DNS에 CAA 레코드를 게시합니다.
2. 인증서 요청: 요청자가 CA에 인증서를 신청합니다.
3. CA 확인: CA가 도메인의 CAA 레코드를 확인합니다.
4. 허가 시 발급: 허가된 경우에만 발급합니다(또는 CAA가 없을 때).
5. 비허가 시 거부: 허가되지 않은 요청은 거부해야 합니다.
CA 확인 의무
2017년 9월부터 모든 CA는 인증서 발급 전에 CAA를 확인해야 합니다. 이는 CA/Browser Forum Baseline Requirements의 일부입니다.
CAA 레코드 형식
example.com. IN CAA 0 issue "letsencrypt.org"구성 요소:
- 0: 플래그(0 = 중요하지 않음, 128 = 중요)
- issue/issuewild/iodef: 속성 태그
- "letsencrypt.org": 속성 값(허가된 CA)
속성 태그
| 태그 | 목적 | 예시 |
|---|---|---|
| issue | 모든 인증서에 CA 허가 | issue "letsencrypt.org"(발급 허가) |
| issuewild | 와일드카드 인증서에 CA 허가 | issuewild "digicert.com"(와일드카드 허가) |
| iodef | 무단 시도 보고 | iodef "mailto:[email protected]"(보고 주소) |
CAA 레코드 예시
단일 CA(Let's Encrypt만)
example.com. CAA 0 issue "letsencrypt.org"여러 CA
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issue "digicert.com"
example.com. CAA 0 issue "sectigo.com"
와일드카드 제한
일반 인증서는 Let's Encrypt, 와일드카드는 DigiCert가 발급하도록 합니다.
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild "digicert.com"
모두 거부(인증서 없음)
인증서가 절대 필요 없는 도메인에 유용합니다.
example.com. CAA 0 issue ";"보고 포함
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 iodef "mailto:[email protected]"
일반적인 CA 식별자
| CA | 식별자 |
|---|---|
| Let's Encrypt 인증기관 | letsencrypt.org(발급 기관 식별자) |
| DigiCert 인증기관 | digicert.com(발급 기관 식별자) |
| Sectigo (Comodo) 인증기관 | sectigo.com(발급 기관 식별자) |
| GlobalSign 인증기관 | globalsign.com(발급 기관 식별자) |
| GoDaddy 인증기관 | godaddy.com(발급 기관 식별자) |
| Amazon 인증기관 | amazon.com(발급 기관 식별자) |
| Google Trust Services 인증기관 | pki.goog(발급 기관 식별자) |
사용할 정확한 식별자는 CA의 문서에서 확인하세요.
CAA 레코드 구현
DNS 제공업체 이용
대부분의 DNS 제공업체는 관리 화면에서 CAA 레코드를 지원합니다.
존 파일 이용
; Allow Let's Encrypt and DigiCert
@ IN CAA 0 issue "letsencrypt.org"
@ IN CAA 0 issue "digicert.com"
@ IN CAA 0 iodef "mailto:[email protected]"
CAA 상속
CAA 레코드는 DNS 계층 구조를 따릅니다.
- example.com의 CAA는 하위 도메인에 적용됩니다.
- 하위 도메인은 자체 CAA로 부모를 재정의할 수 있습니다.
- CAA가 없으면 어느 CA든 발급할 수 있습니다.
example.com. CAA 0 issue "letsencrypt.org" ; Applies to all
api.example.com. CAA 0 issue "digicert.com" ; Override for api
CAA 레코드 확인
dig 사용:dig example.com CAA
; ANSWER SECTION:
example.com. 300 IN CAA 0 issue "letsencrypt.org"
curl "https://domscan.net/v1/health?domain=example.com"
# Reports hasCAA in security details
CAA 모범 사례
1. 항상 CAA 구성: 공격 표면을 줄입니다.
2. 사용하는 모든 CA 포함: CDN과 클라우드 제공업체의 CA도 확인합니다.
3. iodef 설정: 무단 시도를 통지받습니다.
4. 강제 전에 테스트: CA가 계속 발급할 수 있는지 확인합니다.
5. 레코드 최신화: 인증서 요청 전에 새 CA를 추가합니다.
일반적인 CAA 문제
인증서 갱신 실패: CAA에 CA가 없으므로 인증서 만료 전에 추가합니다. CDN 인증서 실패: CDN 제공업체의 CA가 허가되지 않았는지 확인합니다. 하위 도메인 CAA 누락: 하위 도메인은 부모 CAA를 상속하므로 필요하면 특정 레코드를 설정합니다.CAA는 모든 도메인이 구현해야 하는 단순하면서도 강력한 보안 통제입니다.