DNS CAA 리소스 레코드 확인

인증 기관은 인증서 발급 전에 CAA 리소스 레코드를 확인

CA(인증 기관)에서 도메인에 대한 SSL/TLS 인증서를 발급하기 전에 도메인의 DNS CAA(인증 기관 권한 부여) RR(리소스 레코드)를 확인, 처리 및 준수해야 합니다. (투표 125 – CAA 레코드[통과], RFC 6844, 및 투표 219: "issue"/"issuewild" 속성 태그가 없는 CAA 레코드 설정의 처리를 설명을 참조하십시오.)

DigiCert가 귀하의 도메인에 대한 SSL/TLS인증서를 발급하기 위해 CAA 리소스 레코드는 필수가 아닙니다. 여기에 제공된 정보는 다음과 같은 상황에 있는 경우에만 중요합니다.

  • 이미 도메인에 대한 CAA 리소스 레코드를 설정했습니다.
  • 도메인에 대한 CAA 리소스 레코드를 추가하려고 합니다.

CAA의 혜택에 대한 정보는 CAA의 보안에 혜택을 참조하십시오.

CAA RR 절차의 작동 방식

도메인에 대한 SSL/TLS 인증서를 발급하기 전에 CA(예를 들어 DigiCert)는 CAA RR을 확인하여 도메인에 대한 인증서를 발급할 수 있는지 확인합니다. CA는 다음 조건 중 한 개가 충족되는 경우 도메인에 대한 인증서를 발급할 수 있습니다.

  • 도메인에 대한 CAA RR을 찾을 수 없습니다.
  • 도메인에 대한 CAA RR을 찾으며 이에 대한 이 유형의 인증서를 발급하는 것을 승인합니다.
  • 도메인에 대해 "issue" 또는 "issuewild" 속성 태그가 없는 CAA RR만 찾습니다.

단일 CAA RR의 영향

DigiCert가 도메인에 대한 SSL/TLS 인증서를 발급하는 것을 승인하는 CAA RR(리소스 레코드)을 만든 후에는 실질적으로 모든 다른 CA(인증 기관)가 해당 도메인에 대한 인증서를 발급하는 것을 제외한 것입니다. 다른 CA가 해당 도메인에 대해 인증서를 발급할 수 있게 승인하는 유일한 방법은 해당 CA에 대해 다른 CAA RR을 만드는 것입니다.

해당 도메인에 대한 CAA RR이 없으면 모든 CA가 해당 도메인에 대한 모든 유형의 SSL/TLS 인증서를 발급할 수 있습니다.

도메인에 대해 한 개의 CAA RR이 있으면 CA는 해당 도메인에 대해 SSL/TLS 인증서 발급을 승인하는 CAA RR을 찾아야 합니다. 도메인에 대해 첫 CAA RR을 만들 때 조직의 SSL/TLS 인증서 요구 사항을 지원하는 도메인에 대한 충분한 정책을 만들어야 한다는 것을 이해하는 것이 중요합니다.

이렇게 하면 CAA 리소스 레코드는 해당 도메인에 대한 인증서 발급에 대한 정확한 제어가 가능하게 됩니다. 이 제어는 권한이 없는 인증 기관이 도메인에 대한 인증서를 발급하는 것을 방지합니다.

DigiCert, Symantec, Thawte, GeoTrust, RapidSSL 브랜드 인증서에 대한 CA 권한 부여

Symantec의 웹 사이트 보안 및 관련 PKI 솔루션의 인수로, DigiCert는 업계 최고의 인증서 브랜드를 한 개의 인증 기관, 즉 DigiCert로 모았습니다. yourdoman.com에 대한 CAA RR을 만들고 DigiCert가 SSL/TLS 인증서를 발급하도록 승인하면(yourdomain CAA 0 issue "digicert.com"), DigiCert가 해당 도메인에 대한DigiCert, Symantec, Thawte, GeoTrust 및 RapidSSL 브랜드의 SSL/TLS 인증서를 발급하도록 권한을 부여하는 것입니다.

yourdomain.com에 대한 CAA RR을 만들고 Symantec이 SSL/TLS 인증서를 발급하도록 권한을 부여할 때도 동일합니다(yourdomain CAA 0 issue "symantec.com"). 이 한 개의 레코드로 해당 도메인에 대해 DigiCert가 DigiCert, Symantec, Thawte, GeoTrust 및 RapidSSL 브랜드 SSL/TLS 인증서를 발급할 수 있게 합니다.

유효한 CAA 리소스 레코드 값

다음은 DigiCert가 SSL/TLS 인증서를 발급하도록 권한을 부여하도록 CAA 레코드에서 현재 사용할 수 있는 유효한 CAA RR 값입니다.

  • digicert.com
  • www.digicert.com
  • digicert.ne.jp
  • cybertrust.ne.jp
  • symantec.com
  • thawte.com
  • geotrust.com
  • rapidssl.com

모든 나열한 값은 동등합니다. 즉 이 값 중에서 한 개를 사용하여 DigiCert가 DigiCert 인증서 브랜드, 포털, 제품 등에 대한 SSL/TLS 인증서를 발급하게 할 수 있습니다.

CAA RR이 적합하게 구성되었는지 확인

도메인에 대한 DNS CAA RR을 만들거나 만들 계획이십니까? 레코드가 최신이고 정확한지 확인하는 것이 중요합니다.

DigiCert는 도메인에 대한 SSL/TLS 인증서를 주문하기 전에 도메인의 기존 DNS CAA RR을 확인할 것을 권장합니다. 도메인에 대한 SSL/TLS 인증서를 발급할 권한이 있는 각 CA에 대해 필요한 레코드가 있는지 확인합니다. 또한 DNS CAA RR을 만드는 사용자들은 이 절차를 이해하는 것이 좋습니다. 잘못 구성된 CAA RR로 인한 실수로 급하게 필요한 인증서를 발급해야 할 때 CA가 발급할 수 없는 상황을 피하십시오.

도메인의 DNS CAA RR을 편집하여 DigiCert 인증서 브랜드 받기를 참조하십시오.

DNS CAA 리소스 레코드란 무엇입니까?

CAA(인증 기관 권한 부여) RR(리소스 레코드)를 사용하여 도메인 소유자는 특정 CA(인증 기관)가 도메인 소유자와 연결된 도메인에 대해 SSL 인증서를 발급할 수 있는 권한을 부여합니다. 도메인 소유자는 CAA RR을 사용하여 전체 도메인(예, example.com) 또는 특정 호스트 이름(예, mail.example.com)에 대한 보안 정책을 만들 수 있습니다.

기본 도메인에 대한 CAA RR을 만들면 특정 하위 도메인에 대한 별도의 CAA RR을 만들지 않은 경우 정책 내의 하위 도메인에 대한 우산 정책을 만드는 것입니다. example.com에 대한 CAA RR을 가지고 있지만 mail.example.com에 대해 다른 보안 정책을 만들고 싶습니까? 메일 하위 도메인에 대한 추가 CAA RR을 만드세요.

이 레코드를 만든 상태에서 mail.example.com에 대한 SSL/TLS 인증서를 주문하면 CA는 DNS에서 해당 하위 도메인에 대한 CAA RR을 쿼리합니다. CA가 mail.example.com에 대한 레코드를 찾으면 검색은 멈추고 인증서 주문에 정책을 적용합니다. CA가 mail.example.com에 대한 레코드를 찾을 수 없는 경우, 상위 도메인 example.com에서 CAA RR에 대한 DNS 쿼리를 계속합니다. CA가 example.com에 대한 레코드를 찾으면, 부모 도메인의 정책을 mail.example.com에 대한 인증서 주문에 적용합니다.

DNS CAA 리소스 레코드 구문

CAA(인증 기관 권한 부여) RR(리소스 레코드)은 속성이라고 부르는 단일 바이트 flatag-value 쌍으로 구성되어(RFC 6844 섹션 3, 5.1) 있습니다. flag는 0~255 사이의 할당되지 않은 정수입니다. 태그 값 쌍의 tag는 US-ASCII 글자 및 숫자로 구성될 수 있으며 값은 태그 값 속성의 값을 나타내는 옥텟 문자열입니다.

CAA RR 속성 태그

도메인 이름에 대한 여러 CAA RR을 게시하여 동일한 도메인에 대한 여러 속성을 연결할 수 있습니다. 하지만 각 CAA RR은 도메인에 대해 한 CA만 인증서를(또는 일부 경우 한 유형의 인증서를) 발급하도록 권한을 부여할 수 있습니다.

도메인에 대해 여러 CA가 인증서를 발급하도록 허용하려면 각 CA(및 일부 경우 두 개 CAA RR)에 대해 최소 1개 CAA RR을 만들어야 합니다. CAA RR 설정에 대한 도움날은 CAA 레코드 도우미를 방문하십시오.

"issue" 속성 태그

이 속성 태그를 사용하여 CA(예를 들어 DigiCert)가 도메인에 대해 와일드카드 인증서만 발급하게 합니다. *.yourdomain에 대한 와일드카드 인증서 주문을 처리할 때 CA는 "issuewild" 속성 태그를 포함하는 CAA RR에 대해서 도메인의 DNS를 쿼리합니다. CA가 "issuewild" 속성 태그를 찾는 경우, 해당 도메인에 대한 "issue" 속성 태그를 포함하는 모든 CAA RR은 무시됩니다. 다른 CA가 같은 도메인에 대한 와일드카드 인증서만 발급할 수 있게 권한을 부여하려면 각 CA에 대한 고유한 CAA RR을 만들어야 합니다.

generic
yourdomain CAA 0 issuewild "digicert.com"

작동 방식:"issuewild" 속성 태그

"issuewild" 속성 태그는 CA가 도메인(*.domain.com, *.sub.domain.com, *.sub.sub.domain.com 등)에 대해 와일드카드 인증서만 발급하는 것을 권한 부여합니다. CA가 도메인(*.domain.com, *.sub.domain.com, *.sub.sub.domain.com 등)에 대해 와일드카드가 아닌 인증서를 발급하는 것을 허용하지 않습니다.

사용 방법:"issuewild" 속성 태그

"issuewild" 속성을 적절하게 사용하면 와일드카드 인증서 발급 정책에 대한 효과적인 도구가 될 수 있습니다.

예를 들어 도메인에 대해 새 개의 "issue" CAA RR을 만듭니다. 나중에 이들 CA 중에서 한 개만 도메인에 대한 와일드카드 인증서를 발급하기로 결정합니다. 그러므로 이 CA가 *.yourdomain 와일드카드 인증서를 발급하도록 권한을 부여하는 "issuewild" CAA RR을 만듭니다. 3개 CA 모두 계속해서 와일드카드가 아닌 인증서 발급할 수 있지만 이제 한 개 CA만 와일드카드 인증서를 발급할 수 있습니다.

DigiCert가 도메인에 대해 와일드카드 인증서를 발급을 권한 부여

*.yourdomain에 대한 와일드카드 인증서를 주문하면 DigiCert는 추가 비용 없이 인증서에 yourdomain을 포함합니다. 이것은 "issuewild" CAA RR(yourdomain CAA 0 issuewild "digicert.com")을 만들어서 기본 및 하위 도메인에 대한 와일드카드 인증서만 발급하도록 DigiCert에게 권한 부여할 때 문제가 됩니다.

*.yourdomain (또는 *.mail.yourdomain)에 대한 와일드카드 인증서 주문에 yourdomain (또는 mail.yourdomain)을 포함하기 때문에 와일드카드 인증서를 발급할 수 있도록 아래 옵션 중 한 개를 선택해야 합니다.

  1. DigiCert에 대한 “issue” CAA RR 만들기

    yourdomain에 대한 "issuewild" CAA RR을 만들어야 하는 특정 이유가 없으면 만들지 마십시오. "issue" CAA RR만 관리하는 것이 더 간단합니다.

generic
yourdomain CAA 0 issue "digicert.com"
  1. DigiCert에 대한 “issue” CAA RR 및 “issuewild” 만들기

    조직의 정책에서 허용되는 경우, domain.com에 대한 “issuewild” CAA RR을 만든 후에 2개 규칙을 만들어야 합니다.

generic
yourdomain CAA 0 issue "digicert.com"
yourdomain CAA 0 issuewild "digicert.com"
  1. 당사에 연락

    조직의 정책이 DigiCert에서 와일드카드가 아닌 인증서를 발급에 대한 권한 부여를 금지하는 경우, 저희에게 연락하시면, 와일드카드 인증서를 발급할 수 있도록 문제에 대한 솔루션을 찾도록 협력할 것입니다.

부적합한 사용:"issuewild" 속성

"issuewild" 속성을 적절하기 사용하지 않으면 CA가 도메인에 필요한 인증서를 효과적으로 발급할 수 없게 됩니다. 인증서 주문을 처리할 때, 다음과 같은 경우가 아니면 CA는 "issuewild" 속성 태그가 있는 모든 CAA RR을 무시합니다: (1) CA가 와일드카드 인증서에 대한 주문을 처리 중이거나, (2) "issuewild" 태그가 도메인에 대한 유일한 CAA RR입니다.

  1. CA가 와일드카드 인증서에 대한 주문 처리

    도메인에 대해 한 개의 "issuewild" 레코드를 만들면(yourdomain CAA 0 issuewild "digicert.com") 도메인에 대한 와일드카드 인증서 발급에서 "issuewild" 레코드가 없는 모든 다른 CA를 제외하게 됩니다. 이것이 레코드를 만들 때 의도한 것이 아닌 경우, yourdomain에 대한 와일드카드 도메인을 발급하도록 권한을 부여하는 각 도메인에 대한 추가 "issuewild" 레코드를 만들어야 합니다.

  2. "issuewild" CAA RR – 도메인에 대해 만든 유일한 유형의 레코드

    yourdomain에 대해 와일드카드가 아닌 인증서를 주문할 때 CA는 "issuewild" CAA RR이 찾은 유일한 유형의 레코드가 아니면 도메인에 대한 모든 "issuewild" CAA RR를 무시합니다. 이런 경우, CA는 yourdomain에 대한 와일드카드 이외의 인증서를 발급할 수 없습니다.

    CAA RR을 사용하는 기본적 이유는 도메인에 대한 인증서 발급 정책을 만드는 것입니다. 추가된 "issue" 레코드 없이 도메인에 대한 한 개의 "issuewild" 레크드를 만들면(yourdomain CAA 0 issuewild "digicert.com") 두 개를 지정하게 됩니다.

    1. 이 CA가(및 이 CA만) yourdomain에 대한 와일드카드 인증서를 발급하게 권한 부여합니다.
    2. 다른 CA가 yourdomain에 대해 와일드카드가 아닌 인증서가 발급하는 것을 원하지 않습니다.
      이것이 CAA RR이 작동하는 방식이며 yourdomain.com에 대한 "issuewild" CAA RR만 만들 때 의도해야 합니다.

    도메인에 대해 첫 "issuewild" CAA RR을 만들 때 앞으로 두 개 유형(와일드카드 및 와일드카드 이외)의 SSL/TLS 인증서 모두에 대해 정책(CAA RR)을 만들어야 하는 것을 이해해야 합니다.

CAA RR 및 CNAME이 함께 작동하는 방식

다른 도메인(예, my.blog.example.net)을 가리키는 CNAME 레코드를 포함하는 도메인(예, my.blog.example.com)에 대한 SSL/TLS 인증서를 요청할 때 CA(인증 기관)는 특정 절차를 따라서(기준선 요건에[BR]설명) 인증서 발급을 권하는 승인하는 CAA RR을 찾습니다.

CNAME 대상

리소스 고갈 공격에 대한 예방적 조치로 CA는 8개 CNAME 대상(8개 이하 CNAME 레코드: blog.example.com은 blog.example.net에 대한 CNAME이며 blog.example.org에 대한 CNAME 등으로 8개 레벨)만 따를 필요가 있습니다.

이 절차는 인증서 요청에서 도메인 이름에서 시작하여 최상위 도메인까지 계속됩니다. CAA RR을 찾으면 이 절차는 그 지점에서 중지합니다. 다음으로 CAA RR은 CA가 인증서를 발급한 권한이 부여되었는지 확인합니다.

CNAME이 있을 때 CAA RR 확인 워크플로의 예

이 다이어그램을 더 크게 보는 버전은 여기를 클릭하십시오.

단계 1: CA에서 인증서 요청에 도메인 이름(my.blog.example.com)에 대한 CAA RR을 확인합니다.

CA에서 인증서 요청의 도메인에 대한 CAA 레코드를 찾는 경우, 검색을 중지합니다. CA는 인증서를 발급하도록 권한 부여하는 CAA 레코드가 있는 확인합니다. 레코드를 찾으면 CA는 인증서를 발급합니다. 레코드를 찾을 수 없으면 CA는 인증서를 발급할 수 없습니다.

CA가 인증서 요청의 도메인에 대한 CAA 레코드를 찾을 수 없는 경우, CAA 레코드 검색을 계속합니다.

단계 2: CA에서 CNAME 대상 도메인(my.blog.example.net)에 대한 CAA RR을 확인합니다.

CA에서 CNAME 대상 도메인에 대한 CAA 레코드를 찾는 경우, 검색을 중지합니다. CA는 인증서를 발급하도록 권한 부여하는 CAA 레코드가 있는 확인합니다. 레코드를 찾으면 CA는 인증서를 발급합니다. 레코드를 찾을 수 없으면 CA는 인증서를 발급할 수 없습니다.

CA가 CNAME 대상 도메인에 대한 CAA 레코드를 찾을 수 없는 경우, CAA 레코드 검색을 계속합니다.

단계 3: CA에서 원래 도메인의 상위 도메인(blog.example.com)에 대한 CAA RR을 확인합니다.

CA에서 원래 도메인의 상위 도메인에 대한 CAA 레코드를 찾는 경우, 검색을 중지합니다. CA는 인증서를 발급하도록 권한 부여하는 CAA 레코드가 있는 확인합니다. 레코드를 찾으면 CA는 인증서를 발급합니다. 레코드를 찾을 수 없으면 CA는 인증서를 발급할 수 없습니다.

CA가 원래 도메인의 상위 도메인에 대한 CAA 레코드를 찾을 수 없는 경우, CAA 레코드 검색을 계속합니다.

단계 4: CA에서 원래 도메인의 기본 도메인(example.com)에 대한 CAA RR을 확인합니다.

CA에서 원래 도메인의 기본 도메인에 대한 CAA 레코드를 찾는 경우, 검색을 중지합니다. CA는 인증서를 발급하도록 권한 부여하는 CAA 레코드가 있는 확인합니다. 레코드를 찾으면 CA는 인증서를 발급합니다. 레코드를 찾을 수 없으면 CA는 인증서를 발급할 수 없습니다.

CA가 원래 도메인의 기본 도메인에 대한 CAA 레코드를 찾을 수 없는 경우, CAA 레코드 검색을 계속합니다.

단계 5: CA에서 원래 도메인의 최상위 도메인(com)에 대한 CAA RR을 확인합니다.

CA에서 원래 도메인의 최상위 도메인에 대한 CAA 레코드를 찾는 경우, 검색을 중지합니다. CA는 인증서를 발급하도록 권한 부여하는 CAA 레코드가 있는 확인합니다. 레코드를 찾으면 CA는 인증서를 발급합니다. 레코드를 찾을 수 없으면 CA는 인증서를 발급할 수 없습니다.

CA가 원래 도메인의 최상위 도메인에 대한 CAA 레코드를 찾을 수 없는 경우, CA가 인증서를 발급합니다.

추가 정보: