Aktualizováno před 1 měsícem
전통적인 모델에서는 수백 개의 신뢰된 인증 기관(CA) 중 어느 곳이든 모든 도메인에 대해 인증서를 발급할 수 있었습니다. 여러분의 도메인에도. 허락 없이.
CAA(Certificate Authority Authorization) 레코드는 이것을 바꿉니다. 어떤 CA가 여러분의 도메인에 인증서를 발급할 수 있는지를 선언하는 DNS 레코드입니다. CA가 인증서 요청을 받으면, 먼저 여러분의 CAA 레코드를 확인해야 합니다. 목록에 없으면 발급을 거부해야 합니다.
이것이 바로 여러분이 직접 제어하는 화이트리스트입니다.
CAA 레코드의 작동 방식
CAA 레코드는 플래그(flags), 태그(tag), 값(value)의 세 부분으로 구성됩니다.
플래그 필드는 일반적으로 0입니다. 128로 설정하면 해당 레코드를 중요(critical) 항목으로 표시하며, CA는 태그를 이해하지 못할 경우 발급을 거부해야 합니다.
태그는 무엇을 허용할지 지정합니다:
- issue: CA가 표준 인증서를 발급하도록 허용합니다
- issuewild: CA가 와일드카드 인증서(예:
*.example.com)를 발급하도록 허용합니다 - issuemail: CA가 해당 도메인의 이메일 주소에 대한 S/MIME 인증서를 발급하도록 허용합니다
- iodef: CA가 정책 위반 사항을 보고할 연락처를 지정합니다
값에는 CA의 도메인 이름이나 연락 방법이 들어갑니다.
일반적인 설정 방법
단일 CA 허용:
Let's Encrypt는 인증서를 발급할 수 있습니다. 지구상의 다른 모든 CA는 불가능합니다.
여러 CA 허용:
표준 인증서와 와일드카드 인증서에 서로 다른 CA 사용:
일반 인증서는 Let's Encrypt가 담당하고, 와일드카드는 DigiCert만 발급할 수 있습니다.
모든 인증서 발급 차단:
세미콜론은 "아무도 허용하지 않음"을 의미합니다. 공개 서비스를 운영하지 않는 도메인에 유용합니다.
위반 사항 알림 받기:
상속
CAA 레코드는 DNS 계층 구조를 따라 아래로 적용됩니다. CA가 CAA 레코드를 확인할 때는 요청된 도메인부터 시작해서, 레코드를 찾을 때까지 상위 도메인으로 올라갑니다.
example.com에 CAA 레코드가 있지만 blog.example.com에는 없다면, 상위 도메인의 정책이 하위 도메인에 그대로 적용됩니다. 이를 통해 루트 도메인에서 기본 정책을 설정하고, 필요한 곳에서만 재정의할 수 있습니다:
대부분의 하위 도메인은 Let's Encrypt를 사용합니다. API 하위 도메인만 DigiCert를 사용합니다.
CAA 레코드가 전혀 없으면 아무런 제한이 없으므로, 모든 CA가 인증서를 발급할 수 있습니다.
2017년 의무화
CAA 레코드는 2017년 이전에도 존재했지만, 확인은 선택 사항이었습니다. 2017년 9월 8일, CA/Browser Forum은 공개적으로 신뢰받는 모든 CA에 대해 CAA 확인을 의무화했습니다.
이를 계기로 CAA는 단순한 권고에서 실질적인 강제 수단으로 거듭났습니다. CAA 정책을 위반하는 CA는 신뢰 상태를 잃을 수 있습니다. 브라우저 신뢰 저장소(trust store)에서 제거된다는 것은 사실상 사업을 접는 것과 다름없습니다.
도메인 소유자들은 비로소 실질적인 통제권을 갖게 되었습니다. 무단 인증서 발급의 위험도 크게 줄었습니다.
범위 확장
CAA는 계속 발전하고 있습니다. 2024년, CA/Browser Forum은 Ballot SMC051를 통해 CAA의 적용 범위를 S/MIME 인증서까지 확장했습니다. RFC 9495에 정의된 새로운 issuemail 속성 태그를 사용하면 어떤 CA가 도메인의 이메일 인증서를 발급할 수 있는지 제어할 수 있습니다. CA들은 2024년 9월 15일부터 issuemail 레코드를 확인하도록 권고받았으며, 2025년 3월 15일부터는 의무사항이 됩니다.
더 나아가, Ballot SC-085는 CA가 CAA 조회 시 DNSSEC 검증을 사용하도록 요구하며, 이는 2026년 3월 15일부터 적용됩니다2. 이는 공격자가 DNS 응답을 조작하여 CAA 제한을 우회할 수 있는 허점을 막기 위한 조치입니다.
CAA가 보호하는 것과 그렇지 않은 것
CAA는 승인되지 않은 CA가 여러분의 도메인에 대해 인증서를 발급하는 것을 막아줍니다. CA가 침해되거나 악의적으로 행동하더라도, 화이트리스트에 없다면 CAA 레코드가 이를 차단합니다.
하지만 CAA로는 막을 수 없는 것들이 있습니다:
- CAA 레코드를 게시하기 전에 이미 발급된 인증서
- 여러분이 허용한 CA 자체에 대한 공격
- 허용된 CA를 대상으로 한 사회 공학적 공격
- CAA 레코드를 수정하거나 삭제하는 DNS 공격 (2026년 DNSSEC 검증 의무화 전까지)
CAA는 방어 체계의 한 층입니다. 인증서 투명성 모니터링(무단 인증서 감지), DNSSEC(의무화 전에 미리 DNS 레코드 보호), 그리고 허용된 CA에 대한 정기적인 감사와 함께 활용하세요.
CAA 레코드 자주 묻는 질문
CAA 레코드가 없으면 어떻게 되나요?
신뢰받는 모든 인증 기관이 해당 도메인에 대해 인증서를 발급할 수 있습니다. 이것은 CAA가 등장하기 전 모든 도메인의 기본 동작이었으며, CAA 레코드를 게시하지 않으면 지금도 그렇습니다.
값 필드에는 어떤 CA 도메인 이름을 써야 하나요?
CA의 웹사이트가 아닌 발급 도메인을 사용해야 합니다. Let's Encrypt는 letsencrypt.org, DigiCert는 digicert.com, Amazon은 amazon.com을 씁니다. 정확한 값은 각 CA의 공식 문서에서 확인하세요.
CAA 레코드가 인증서 갱신에도 영향을 미치나요?
네. CA는 갱신을 포함한 모든 발급 시 CAA 레코드를 확인합니다. CAA 레코드를 변경하여 특정 CA를 제거하면, 해당 CA는 기존 인증서를 갱신할 수 없게 됩니다.
CAA 레코드를 변경하면 기존 인증서가 작동을 멈추나요?
아니요. CAA는 발급 여부만 제어하고 실제 사용에는 영향을 주지 않습니다. 기존 인증서는 CAA 변경 여부와 관계없이 계속 정상 작동합니다. 다만, 발급한 CA가 더 이상 허용되지 않으면 갱신은 불가능해집니다.
issue와 issuemail은 어떻게 다른가요?
issue 태그는 TLS/SSL 인증서(웹사이트용)를 제어합니다. issuemail 태그는 S/MIME 인증서(이메일용)를 제어합니다. 각 용도에 따라 서로 다른 CA를 허용할 수 있습니다.
출처
Byla tato stránka užitečná?