기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # AWS Certificate Manager 퍼블릭 인증서에 대한 도메인 소유권 검증 Amazon 인증 기관(CA)에서 사용자 사이트에 대한 인증서를 발급하려면 AWS Certificate Manager (ACM)에서 요청에 지정하는 모든 도메인 이름에 대한 소유권 또는 제어권이 사용자에게 있음을 증명해야 합니다. 인증서 요청 시 도메인 이름 시스템(DNS) 검증, 이메일 검증 또는 HTTP 검증을 통해 소유권을 증명하도록 선택할 수 있습니다. **참고** 검증은 ACM에서 발급한 공개적으로 신뢰할 수 있는 인증서에만 적용됩니다. ACM은 [가져온 인증서](import-certificate.md) 또는 프라이빗 CA에서 서명한 인증서에 대해 도메인 소유권을 검증하지 않습니다. ACM은 Amazon VPC [프라이빗 호스팅 영역](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-private-hosted-zones) 또는 기타 비공개 도메인의 리소스를 검증할 수 없습니다. 자세한 내용은 [인증서 검증 문제 해결](certificate-validation.md) 단원을 참조하십시오. 다음과 같은 이유로 이메일 검증을 통한 DNS 검증을 사용하는 것이 좋습니다. + Amazon Route 53 사용하여 퍼블릭 DNS 레코드를 관리하는 경우 ACM을 통해 레코드를 직접 업데이트할 수 있습니다. + ACM은 인증서를 아직 사용 중이고 DNS 레코드가 존재하는 한 DNS에서 확인한 인증서를 자동으로 갱신합니다. + 이메일로 검증된 인증서를 갱신하려면 도메인 소유자의 조치가 필요합니다. ACM은 만료 45일 전에 갱신 통지를 전송하기 시작합니다. 이러한 알림은 도메인의 공통 관리자 주소 5개 중 하나 이상으로 이동합니다. 이 알림에는 도메인 소유자가 클릭하여 손쉽게 갱신 작업을 수행할 수 있는 링크가 포함되어 있습니다. 나열된 모든 도메인이 검증되면 ACM은 동일한 ARN 사용하여 갱신된 인증서를 발급합니다. 도메인의 DNS 데이터베이스를 편집할 수 없는 경우 [이메일 검증](email-validation.md)을 대신 사용해야 합니다. HTTP 검증은 CloudFront에서 사용되는 인증서에 사용할 수 있습니다. 이 방식은 HTTP 리디렉션을 사용하여 도메인 소유권을 증명하고 DNS 검증과 유사한 자동 갱신을 제공합니다. **참고** 이메일 검증을 통해 인증서를 생성한 후에는 해당 인증서를 DNS를 통한 인증으로 전환할 수 없습니다. DNS 검증을 사용하려면 인증서를 삭제한 다음, DNS 검증을 사용하는 새 인증서를 생성합니다. **Topics** + [AWS Certificate Manager DNS 검증](dns-validation.md) + [AWS Certificate Manager 이메일 검증](email-validation.md) + [AWS Certificate Manager HTTP 검증](http-validation.md) # AWS Certificate Manager DNS 검증 도메인 이름 시스템(DNS)은 네트워크에 연결되는 리소스를 위한 디렉터리 서비스입니다. DNS 공급자는 도메인을 정의하는 레코드가 포함된 데이터베이스를 유지 관리합니다. DNS 검증을 선택하면 ACM은 이 데이터베이스에 추가해야 하는 하나 이상의 CNAME 레코드를 제공합니다. 이 레코드에는 사용자가 도메인을 통제함을 증명하는 역할을 하는 고유한 키-값 페어가 포함되어 있습니다. **참고** 이메일 검증을 통해 인증서를 생성한 후에는 해당 인증서를 DNS를 통한 인증으로 전환할 수 없습니다. DNS 검증을 사용하려면 인증서를 삭제한 다음, DNS 검증을 사용하는 새 인증서를 생성합니다. 예를 들면 추가 이름이 `www.example.com`인 `example.com` 도메인에 대해 인증서를 요청할 경우 ACM은 CNAME 레코드 두 개를 자동으로 생성합니다. 사용자의 도메인 및 계정용으로 특별히 생성된 각 레코드에는 이름과 값이 포함되어 있습니다. 값은 ACM이 인증서를 자동으로 갱신하는 데 사용하는 AWS 도메인을 가리키는 별칭입니다. CNAME 레코드는 DNS 데이터베이스에 한 번만 추가해야 합니다. 인증서가 사용 중이고 CNAME 레코드가 여전히 존재하는 경우에 한해 ACM은 인증서를 자동으로 갱신합니다. **중요** Amazon Route 53을 사용하여 퍼블릭 DNS 레코드를 관리하지 않는 경우 DNS 공급자에게 문의하여 레코드를 추가하는 방법을 확인하세요. 도메인의 DNS 데이터베이스를 편집할 권한이 없는 경우 [이메일 검증](email-validation.md)을 대신 사용해야 합니다. 검증을 반복할 필요 없이 CNAME 레코드가 유지되는 동안 정규화된 도메인 이름(FQDN)에 대한 추가 ACM 인증서를 요청할 수 있습니다. 즉, 도메인 이름이 동일한 대체 인증서 또는 다른 하위 도메인을 포함하는 인증서를 만들 수 있습니다. CNAME 검증 토큰은 모든 AWS 리전에서 작동하므로 여러 리전에서 동일한 인증서를 다시 생성할 수 있습니다. 또한 삭제된 인증서를 교체할 수도 있습니다. 연결된 AWS 서비스에서 인증서를 제거하거나 CNAME 레코드를 삭제하여 자동 갱신을 중지할 수 있습니다. Route 53이 DNS 공급자가 아닌 경우에는 공급자에게 연락하여 레코드를 삭제하는 방법을 알아보세요. Route 53이 공급자인 경우 *Route 53 개발자 가이드*에서 [리소스 레코드 세트 삭제](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-deleting.html)를 참조하세요. 관리형 인증서 갱신에 대한 자세한 내용은 [에서 관리형 인증서 갱신 AWS Certificate Manager](managed-renewal.md) 섹션을 참조하세요. **참고** DNS 구성에서 5개 이상의 CNAME 하나로 연결되어 있으면 CNAME 확인이 실패합니다. 더 긴 체인이 필요한 경우 [이메일 검증](email-validation.md)을 사용하는 것이 좋습니다. ## ACM에 대한 CNAME 레코드의 작동 방식 **참고** 이 섹션은 Route 53을 DNS 공급자로 사용하지 않는 고객에게 적용됩니다. Route 53을 DNS 공급자로 사용하지 않는 경우, ACM에서 제공하는 CNAME 레코드를 일반적으로 웹 사이트를 통해 공급자의 데이터베이스에 수동으로 입력해야 합니다. CNAME 레코드는 리디렉션 메커니즘, 공급업체별 메타데이터의 컨테이너 등 다양한 용도로 사용됩니다. ACM의 경우 이러한 레코드를 통해 초기 도메인 소유권 확인 및 지속적인 자동 인증서 갱신을 수행할 수 있습니다. 다음 테이블에는 6개 도메인 이름에 대한 CNAME 레코드의 예제가 나와 있습니다. 각 레코드의 **레코드 이름**-**레코드 값** 페어는 도메인 이름 소유권을 인증하는 역할을 합니다. 이 표에서 처음 2개의 **레코드 이름**-**레코드 값** 페어는 동일합니다. 이는 `*.example.com`과 같은 와일드 카드 도메인의 경우 ACM이 생성한 문자열이 기본 도메인 `example.com`에 대해 생성된 문자열과 동일함을 보여줍니다. 그렇지 않으면 **레코드 이름** 및 **레코드 값** 페어는 각 도메인 이름별로 다릅니다. **CNAME 레코드 예** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/acm/latest/userguide/dns-validation.html) 밑줄(\$1) 다음에 오는 *xN* 값은 ACM이 생성한 긴 문자열입니다. 예를 들면 다음과 같습니다. ``` _3639ac514e785e898d2646601fa951d5.example.com. ``` 이 예는 결과로 생성된 **레코드 이름**을 보여줍니다. 연결된 **레코드 값**은 다음과 같은 값일 수 있습니다. ``` _98d2646601fa951d53639ac514e785e8.acm-validation.aws. ``` 위의 예는 동일한 DNS 레코드에 대한 결과입니다. **참고** DNS 공급자가 앞에 밑줄이 붙은 CNAME 값을 지원하지 않을 경우 [DNS 검증 문제 해결](troubleshooting-DNS-validation.md)을 참조하세요. 인증서를 요청하고 DNS 검증을 지정하면, ACM이 CNAME 정보를 다음 형식으로 제공합니다. **** | 도메인 이름 | 레코드 이름 | 레코드 형식 | 레코드 값 | | --- | --- | --- | --- | | example.com | \$1a79865eb4cd1a6ab990a45779b4e0b96.example.com. | CNAME | \$1424c7224e9b0146f9a8808af955727d0.acm-validations.aws. | *도메인 이름*은 인증서와 연결된 FQDN입니다. *레코드 이름*은 키-값 페어의 키로, 레코드를 고유하게 식별합니다. *레코드 값*은 키-값 페어의 값으로 사용됩니다. DNS 레코드를 추가하려면 이 세 가지 값(*도메인 이름*, *레코드 이름*, *레코드 값*)을 모두 DNS 공급자 웹 인터페이스의 해당 필드에 입력해야 합니다. 레코드 이름(또는 ‘이름’) 필드를 처리하는 방식이 공급자 간에 일관되지 않습니다. 경우에 따라 위에 표시된 것처럼 전체 문자열을 제공해야 합니다. 일부 공급자의 경우에는 사용자가 입력한 문자열에 도메인 이름이 자동으로 추가됩니다. 즉, 이 예에서는 이름 필드에 ``` _a79865eb4cd1a6ab990a45779b4e0b96 ``` 만 입력해야 합니다. 이 규칙을 잘못 알고 도메인 이름이 포함된 레코드 이름(예: *`.example.com`*)을 입력하면 다음과 같이 될 수 있습니다. ``` _a79865eb4cd1a6ab990a45779b4e0b96.example.com.example.com. ``` 이 경우 검증이 실패합니다. 따라서 공급자에 맞는 입력 유형을 미리 확인해야 합니다. ## DNS 검증 설정 이 섹션에서는 DNS 검증을 사용하도록 퍼블릭 인증서를 구성하는 방법에 대해서 설명합니다. **콘솔에서 DNS 검증을 설정하려면** **참고** 이 절차에서는 이미 하나 이상의 인증서를 생성했으며 인증서를 생성한 AWS 리전에서 작업하고 있다고 가정합니다. 콘솔을 열려고 하는데 처음 사용 화면이 대신 표시되거나 콘솔을 성공적으로 열었지만 목록에 인증서가 표시되지 않는 경우, 올바른 리전을 지정했는지 확인합니다. 1. [https://console.aws.amazon.com/acm/](https://console.aws.amazon.com/acm/)에서 ACM 콘솔을 엽니다. 1. 인증서 목록에서 **검증 보류 중(Pending validation)** 상태인 구성하려는 **인증서 ID(Certificate ID)**를 선택합니다. 그러면 인증서에 대한 세부 정보 페이지가 열립니다. 1. **도메인(Domains)** 섹션에서 다음 두 절차 중 하나를 완료합니다. 1. (선택 사항) Route 53로 검증합니다. 다음 조건에 해당할 경우 활성 상태의 **Route 53에 레코드 생성(Create record in Route 53)** 버튼이 표시됩니다. + Route 53을 DNS 공급자로 사용합니다. + Route 53에서 호스팅한 영역에 대한 쓰기 권한이 있습니다. + FQDN이 아직 검증되지 *않았습니다*. **참고** Route 53을 사용하고 있지만 **Route 53에 레코드 생성**이 표시되지 않거나 비활성화된 경우, [ACM 콘솔에서 ‘Route 53에 레코드 생성’ 버튼이 나타나지 않음](troubleshooting-DNS-validation.md#troubleshooting-route53-1) 섹션을 참조하세요. **Route 53에 레코드 생성**을 선택한 다음 **레코드 생성**을 선택합니다. **인증서 상태(Certificate status)** 페이지가 **DNS 레코드가 생성됨(Successfully created DNS records)**이라고 표시되는 상태 배너와 함께 열립니다. 새 인증서의 상태가 최대 30분 동안 계속 **검증 보류 중(Pending validation)**으로 표시될 수 있습니다. **작은 정보** ACM이 Route 53에서 레코드를 자동으로 생성하도록 프로그래밍 방식으로 요청할 수 없습니다. 그러나 Route 53 DNS 데이터베이스에 레코드를 생성하기 위해 Route 53에 AWS CLI 또는 API를 호출할 수 있습니다. Route 53 레코드 세트에 대한 자세한 내용은 [리소스 레코드 세트 관련 작업](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)을 참조하세요. 1. (선택 사항) Route 53을 DNS 공급자로 사용하지 않는 경우 CNAME 정보를 검색하여 DNS 데이터베이스에 추가해야 합니다. 새 인증서의 세부 정보 페이지에서 이 작업은 다음 두 가지 방법 중 하나로 수행할 수 있습니다. + **도메인(Domains)** 섹션에 표시된 CNAME 구성 요소를 복사합니다. 이 정보를 DNS 데이터베이스에 수동으로 추가해야 합니다. + 또는 **CSV로 내보내기(Export to CSV)**를 선택합니다. 결과 파일의 정보를 DNS 데이터베이스에 수동으로 추가해야 합니다. **중요** 검증 문제를 방지하려면 DNS 공급자의 데이터베이스에 정보를 추가하기 전에 [ACM에 대한 CNAME 레코드의 작동 방식](#cnames-overview)를 검토하세요. 문제가 발생하면 [DNS 검증 문제 해결](troubleshooting-DNS-validation.md) 섹션을 참조하세요. ACM이 사용자를 위해 CNAME 값을 생성한 시각으로부터 72시간 내에 도메인 이름을 검증할 수 없는 경우, ACM은 인증서 상태를 [**검증 시간 초과(Validation timed out)**]로 변경합니다. 이러한 결과가 발생하는 가장 큰 이유는 ACM이 생성한 값으로 DNS 구성을 성공적으로 업데이트하지 않았기 때문입니다. 이 문제를 해결하려면 CNAME 지침을 검토한 후 새 인증서를 요청해야 합니다. # AWS Certificate Manager 이메일 검증 Amazon 인증 기관(CA)에서 사용자 사이트에 대한 인증서를 발급하려면 AWS Certificate Manager (ACM)는 요청에 지정한 모든 도메인에 대한 소유권 또는 제어권이 사용자에게 있는지 확인해야 합니다. 이메일 혹은 DNS를 사용하여 확인할 수 있습니다. 이 주제에서는 이메일 검증에 대해 설명합니다. 이메일 검증 사용 시 문제가 발생하면 [이메일 검증 문제 해결](troubleshooting-email-validation.md) 단원을 참조하세요. ## 이메일 검증 작동 방식 ACM은 각 도메인에 대해 다음 5개의 공통 시스템 이메일로 검증 이메일 메시지를 전송합니다. 또는 대신 해당 도메인에서 이러한 이메일을 수신하려는 경우 슈퍼 도메인을 검증 도메인으로 지정할 수 있습니다. 최소 웹 사이트 주소까지의 모든 하위 도메인이 유효하며, 이메일 주소의 도메인으로 `@` 뒤에 접미사로 사용됩니다. 예를 들어, example.com을 subdomain.example.com의 검증 도메인으로 지정하는 경우 admin@example.com으로 이메일을 받을 수 있습니다. + administrator@해당\$1도메인\$1이름 + hostmaster@해당\$1도메인\$1이름. + postmaster@해당\$1도메인\$1이름 + webmaster@해당\$1도메인\$1이름 + admin@해당\$1도메인\$1이름 도메인을 소유하고 있음을 증명하려면 이러한 이메일에 포함된 검증 링크를 선택해야 합니다. 또한 ACM은 인증서가 만료된 지 45일이 되면 인증서를 갱신하기 위해 동일한 주소로 검증 이메일을 전송합니다. ACM API 또는 CLI를 사용하여 다중 도메인 인증서 요청에 대한 이메일 검증을 수행하면 요청이 요청에 있는 다른 도메인의 하위 도메인을 포함해도 요청된 각 도메인에서 이메일 메시지를 전송합니다. ACM이 인증서를 발급하려면 도메인 소유자가 이러한 각 도메인의 이메일 메시지를 확인해야 합니다. **이 프로세스의 예외** **www** 또는 와일드카드 별표(**\$1**)로 시작하는 도메인 이름에 대한 ACM 인증서를 요청하는 경우, ACM은 맨 앞의 **www** 또는 별표를 제외하고 관리 주소로 이메일을 전송합니다. 이 주소는 도메인 이름의 나머지 부분에 admin@, administrator@, hostmaster@, postmaster@ 및 webmaster@를 추가한 양식입니다. 예를 들어 www.example.com에 대한 ACM 인증서를 요청하는 경우, admin@www.example.com이 아닌 admin@example.com으로 이메일을 보냅니다. 마찬가지로 \$1.test.example.com에 대한 ACM 인증서를 요청하는 경우 admin@test.example.com으로 이메일을 보냅니다. 나머지 공통 관리 주소도 비슷하게 구성됩니다. **중요** ACM은 더 이상 새 인증서 또는 갱신에 대한 WHOIS 이메일 검증을 지원하지 않습니다. 공통 시스템 주소는 계속 지원됩니다. 자세한 내용은 [블로그 게시물](https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-whois-lookup-for-email-validated-certificates/)을 참조하세요. ## 고려 사항 이메일 검증에 대한 다음과 같은 고려 사항을 따르세요. + 이메일 검증을 사용하려면 도메인에 등록된 유효한 이메일 주소가 필요합니다. 이메일 주소 설정 절차는 이 설명서에서는 다루지 않습니다. + 검증은 ACM에서 발급한 공개적으로 신뢰할 수 있는 인증서에만 적용됩니다. ACM은 [가져온 인증서](import-certificate.md) 또는 프라이빗 CA에서 서명한 인증서에 대해 도메인 소유권을 검증하지 않습니다. ACM은 Amazon VPC [프라이빗 호스팅 영역](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-private-hosted-zones) 또는 기타 비공개 도메인의 리소스를 검증할 수 없습니다. 자세한 내용은 [인증서 검증 문제 해결](certificate-validation.md) 단원을 참조하십시오. + 이메일 검증을 통해 인증서를 생성한 후에는 해당 인증서를 DNS를 통한 인증으로 전환할 수 없습니다. DNS 검증을 사용하려면 인증서를 삭제한 다음, DNS 검증을 사용하는 새 인증서를 생성합니다. ## 인증서 만료 및 갱신 ACM 인증서는 198일 동안 유효합니다. 인증서를 갱신하려면 도메인 소유자의 작업이 필요합니다. ACM은 만료 45일 전에 도메인과 연결된 이메일 주소로 갱신 알림을 전송하기 시작합니다. 이 알림에는 도메인 소유자가 갱신을 위해 클릭할 수 있는 링크가 포함되어 있습니다. 나열된 모든 도메인이 검증되면 ACM은 동일한 ARN 사용하여 갱신된 인증서를 발급합니다. ## (선택 사항) 검증 이메일 재전송 각 검증 이메일에는 인증서 요청을 승인하는 데 사용할 수 있는 토큰이 포함되어 있습니다. 하지만 승인 프로세스에 필요한 검증 이메일이 스팸 필터에 의해 차단되거나 전송 중에 손실될 수 있으므로 토큰은 72시간이 경과하면 자동으로 만료됩니다. 원래 이메일을 수신하지 못하거나 토큰이 만료된 경우 이메일을 재전송하도록 요청할 수 있습니다. 검증 이메일을 재전송하는 방법에 대한 자세한 내용은 [검증 이메일 재전송](email-renewal-validation.md#request-domain-validation-email-for-renewal) 섹션을 참조하세요. 이메일 검증과 관련된 지속적인 문제는 [의 문제 해결 AWS Certificate Manager](troubleshooting.md)의 [이메일 검증 문제 해결](troubleshooting-email-validation.md) 단원을 참조하세요. # AWS Certificate Manager 이메일 검증 자동화 이메일 검증 ACM 인증서의 경우 일반적으로 도메인 소유자의 수작업이 필요합니다. 많은 수의 이메일 검증 인증서를 사용하는 조직의 경우 필요한 응답을 자동화하는 파서를 만드는 것이 좋을 수 있습니다. 이메일 검증을 사용할 수 있도록, 이 섹션의 정보에서는 도메인 검증 이메일 메시지에 사용되는 템플릿, 그리고 검증 프로세스 수행과 관련한 워크플로에 대해 설명합니다. ## 검증 이메일 템플릿 검증 이메일 메시지의 형식은 새 인증서를 요청하는지 또는 기존 인증서를 갱신하는지에 따라 다음 두 가지 중 하나로 정해집니다. 강조 표시된 문자열의 내용은 검증되는 도메인에 특정 값으로 바꾸어야 합니다. ### 새 인증서 생성 이메일 템플릿 텍스트: ``` Greetings from Amazon Web Services, We received a request to issue an SSL/TLS certificate for requested_domain. Verify that the following domain, AWS account ID, and certificate identifier correspond to a request from you or someone in your organization. Domain: fqdn AWS account ID: account_id AWS Region name: region_name Certificate Identifier: certificate_identifier To approve this request, go to Amazon Certificate Approvals (https://region_name.acm-certificates.amazon.com/approvals?code=validation_code&context=validation_context) and follow the instructions on the page. This email is intended solely for authorized individuals for fqdn. To express any concerns about this email or if this email has reached you in error, forward it along with a brief explanation of your concern to validation-questions@amazon.com. Sincerely, Amazon Web Services ``` ### 갱신을 위한 인증서 검증 이메일 템플릿 텍스트: ``` Greetings from Amazon Web Services, We received a request to issue an SSL/TLS certificate for requested_domain. This email is a request to validate ownership of the domain in order to renew the existing, currently in use, certificate. Certificates have defined validity periods and email validated certificates, like this one, require you to re-validate for the certificate to renew. Verify that the following domain, AWS account ID, and certificate identifier correspond to a request from you or someone in your organization. Domain: fqdn AWS account ID: account_id AWS Region name: region_name Certificate Identifier: certificate_identifier To approve this request, go to Amazon Certificate Approvals at https://region_name.acm-certificates.amazon.com/approvals?code=$validation_code&context=$validation_context and follow the instructions on the page. This email is intended solely for authorized individuals for fqdn. You can see more about how AWS Certificate Manager validation works here - https://docs.aws.amazon.com/acm/latest/userguide/email-validation.html. To express any concerns about this email or if this email has reached you in error, forward it along with a brief explanation of your concern to validation-questions@amazon.com. Sincerely, Amazon Web Services -- Amazon Web Services, Inc. is a subsidiary of Amazon.com, Inc. Amazon.com is a registered trademark of Amazon.com, Inc. This message produced and distributed by Amazon Web Services, Inc., 410 Terry Ave. North, Seattle, WA 98109-5210. (c)2015-2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Our privacy policy is posted at https://aws.amazon.com/privacy ``` 에서 새 검증 메시지를 받으면 구문 분석기에 대한 가장 up-to-date의 신뢰할 수 있는 템플릿으로 사용하는 것이 AWS좋습니다. 2020년 11월 이전에 설계된 메시지 파서를 사용하는 고객은 템플릿에 대해 다음과 같은 변경 사항을 확인해야 합니다. + 이제 이메일 제목 줄에 ‘`"Certificate approval for domain name`’ 대신 ‘`Certificate request for domain name`’이 표시됩니다. + `AWS account ID`가 이제 대시 또는 하이픈 없이 표시됩니다.  + 이제 `Certificate Identifier`가 단축된 양식 대신 전체 인증서 ARN을 표시합니다(예: `3b4d78e1-0882-4f51-954a-298ee44ff369` 대신 `arn:aws:acm:us-east-1:000000000000:certificate/3b4d78e1-0882-4f51-954a-298ee44ff369` 표시). + 이제 인증서 승인 URL에 `certificates.amazon.com` 대신 `acm-certificates.amazon.com`이 포함됩니다. + 인증서 승인 URL을 클릭하여 연 승인 양식에 이제 승인 버튼이 포함됩니다. 이제 승인 버튼 div의 이름이 `approval_button` 대신 `approve-button`이 됩니다. + 새로 요청된 인증서와 갱신 인증서 모두의 검증 메시지 이메일 형식이 동일합니다. ## 검증 워크플로 이 섹션에서는 이메일 검증 인증서의 갱신 워크플로에 대한 정보를 제공합니다. + ACM 콘솔이 다중 도메인 인증서 요청을 처리하면 퍼블릭 인증서를 요청할 때 지정한 도메인 이름 또는 검증 도메인으로 검증 이메일 메시지를 전송합니다. ACM이 인증서를 발급하려면 도메인 소유자가 각 도메인의 이메일 메시지를 확인해야 합니다. 자세한 내용은 [이메일을 사용하여 도메인 소유권 확인](https://docs.aws.amazon.com/acm/latest/userguide/email-validation.html)을 참조하세요. + ACM API 또는 CLI를 사용하여 다중 도메인 인증서 요청에 대한 이메일 검증을 수행하면 요청이 요청에 있는 다른 도메인의 하위 도메인을 포함해도 요청된 각 도메인에서 이메일 메시지를 전송합니다. ACM이 인증서를 발급하려면 도메인 소유자가 이러한 각 도메인의 이메일 메시지를 확인해야 합니다. ACM 콘솔을 통해 기존 인증서에 대한 이메일을 재전송하면 원본 인증서 요청에 지정된 검증 도메인 또는 검증 도메인이 지정되지 않은 경우 정확한 도메인으로 이메일이 전송됩니다. 다른 도메인에서 검증 이메일을 수신하려면 검증에 사용할 검증 도메인을 지정하여 새 인증서를 요청할 수 있습니다. 또는 API, SDK 또는 CLI를 사용하여 `ValidationDomain` 파라미터를 통해 [ResendValidationEmail](https://docs.aws.amazon.com/acm/latest/APIReference/API_ResendValidationEmail.html)을 직접 호출할 수 있습니다. 그러나 `ResendValidationEmail` 요청에 지정된 검증 도메인은 해당 직접 호출에만 사용되며 향후 검증 이메일을 위해 인증서 Amazon 리소스 이름(ARN)에 저장되지 않습니다. 원본 인증서 요청에 지정되지 않은 도메인 이름으로 검증 이메일을 수신하려면 매번 `ResendValidationEmail`을 직접 호출해야 합니다. **참고** 2020년 11월 이전에는 고객이 apex 도메인만 검증해야 했으며 ACM은 모든 하위 도메인에도 적용되는 인증서를 발급했습니다. 이 시점 이전에 설계된 메시지 파서를 사용하는 고객은 이메일 검증 워크플로의 변경 사항을 확인해야 합니다. + ACM API 또는 CLI를 사용하면 다중 도메인 인증서 요청에 대한 모든 검증 이메일 메시지를 apex 도메인으로 보낼 수 있습니다. API에서 [RequestCertificate](https://docs.aws.amazon.com/acm/latest/APIReference/API_RequestCertificate.html) 작업의 `DomainValidationOptions` 파라미터를 사용하여 [DomainValidationOption](https://docs.aws.amazon.com/acm/latest/APIReference/API_DomainValidationOption.html) 유형의 멤버인 `ValidationDomain`의 값을 지정합니다. CLI에서 [request-certificate](https://docs.aws.amazon.com/cli/latest/reference/acm/request-certificate.html) 명령의 **--domain-validation-options** 파라미터를 사용하여 `ValidationDomain`의 값을 지정합니다. # AWS Certificate Manager HTTP 검증 Hypertext Transfer Protocol(HTTP)은 월드 와이드 웹에서의 데이터 통신을 위한 기본 프로토콜입니다. CloudFront에 사용되는 인증서에 대해 HTTP 검증을 선택하면 ACM은 이 프로토콜을 활용하여 도메인 소유권을 검증합니다. ACM은 CloudFront와 함께 작동하여 특정 URL을 제공하고 도메인의 해당 URL에서 액세스할 수 있어야 하는 고유한 토큰을 제공합니다. 이 토큰은 도메인에 대한 통제권이 있다는 증거 역할을 합니다. 도메인에서 CloudFront 인프라 내의 ACM 제어 위치로 리디렉션을 설정하는 것은 도메인의 콘텐츠를 수정할 수 있는 기능을 보여주는 것이며 결과적으로 소유권을 검증해 줍니다. ACM과 CloudFront 간의 원활한 통합은 특히 CloudFront 배포의 경우 인증서 발급 프로세스를 간소화합니다. **중요** HTTP 검증은 와일드카드 도메인 인증서(예: \$1.example.com)를 지원하지 않습니다. 와일드카드 인증서의 경우 DNS 검증 또는 이메일 검증을 대신 사용해야 합니다. 예를 들어 CloudFront로 `www.example.com`을 추가 이름으로 사용하는 `example.com` 도메인에 대한 인증서를 요청하는 경우 ACM은 HTTP 검증을 위한 두 세트의 URL을 제공합니다. 각 세트에는 도메인 및 AWS 계정을 위해 특별히 생성된 `redirectFrom` URL과 `redirectTo` URL이 포함됩니다. `redirectFrom` URL은 구성해야 하는 도메인의 경로(예: `http://example.com/.well-known/pki-validation/example.txt`)입니다. `redirectTo` URL은 고유한 검증 토큰이 저장된 CloudFront 인프라 내의 ACM 제어 위치를 가리킵니다. 이러한 리디렉션은 한 번만 설정하면 됩니다. 인증 기관은 도메인 소유권의 검증을 시도할 때 `redirectFrom` URL에서 파일을 요청하고, 이 URL은 CloudFront에서 `redirectTo` URL로 리디렉션하여 검증 토큰에 대한 액세스를 허용합니다. 인증서가 CloudFront에서 사용 중이고 리디렉션이 여전히 존재하는 한 ACM은 인증서를 자동으로 갱신합니다. CloudFront를 사용하여 정규화된 도메인 이름(FQDN)에 대한 HTTP 검증을 설정했으면 HTTP 리디렉션이 그대로 유지되는 한 검증 프로세스를 반복하지 않고 해당 FQDN에 대한 추가 ACM 인증서를 요청할 수 있습니다. 즉, 동일한 도메인 이름으로 대체 인증서를 생성할 수 있습니다. 리디렉션이 여전히 활성 상태인 한 검증 프로세스를 다시 거치지 않고 삭제된 인증서를 교체할 수도 있습니다. HTTP 검증 인증서의 자동 갱신을 중지하려면 두 가지 옵션이 있습니다. 연결된 CloudFront 배포에서 인증서를 제거하거나 검증을 위해 설정한 HTTP 리디렉션을 삭제할 수 있습니다. CloudFront 이외의 콘텐츠 전송 네트워크(CDN) 또는 웹 서버를 사용하여 리디렉션을 관리하는 경우 해당 설명서를 참조하여 리디렉션을 제거하는 방법을 알아봅니다. CloudFront를 사용하여 리디렉션을 관리하는 경우 배포의 구성을 업데이트하여 리디렉션을 제거할 수 있습니다. 관리형 인증서 갱신에 대한 자세한 내용은 [에서 관리형 인증서 갱신 AWS Certificate Manager](managed-renewal.md) 섹션을 참조하세요. 자동 갱신을 중지하면 인증서 만료로 이어져 HTTPS 트래픽이 중단될 수 있다는 점을 기억하세요. ## ACM에 대한 HTTP 리디렉션 작동 방식 **참고** 이 섹션은 콘텐츠 전송을 위해 CloudFront를 사용하고 SSL/TLS 인증서 관리를 위해 ACM을 사용하는 고객을 위한 것입니다. ACM 및 CloudFront에서 HTTP 검증을 사용하는 경우 HTTP 리디렉션을 설정해야 합니다. 이러한 리디렉션을 통해 ACM은 초기 인증서 발급 및 지속적인 자동 갱신에 대한 도메인 소유권을 검증할 수 있습니다. 이 리디렉션 메커니즘은 도메인의 특정 URL이 고유한 검증 토큰이 저장된 CloudFront 인프라 내의 ACM 제어 위치를 가리키게 하는 방식으로 작동합니다. 다음 표는 도메인 이름에 대한 리디렉션 구성의 예를 보여줍니다. 참고로 HTTP 검증은 와일드카드 도메인(예: \$1.example.com)을 지원하지 않습니다. 각 구성의 **리디렉션 소스**-**리디렉션 대상** 페어는 도메인 이름 소유권을 인증하는 역할을 합니다. **HTTP 리디렉션 구성의 예** | 도메인 이름 | 리디렉션 소스 | 리디렉션 대상 | 설명 | | --- | --- | --- | --- | | example.com | `http://example.com/.well-known/pki-validation/x2.txt` | `https://validation.region.acm-validations.aws/y2/.well-known/pki-validation/x2.txt` | 고유 | | www.example.com | `http://www.example.com/.well-known/pki-validation/x3.txt` | `https://validation.region.acm-validations.aws/y3/.well-known/pki-validation/x3.txt` | 고유 | | host.example.com | `http://host.example.com/.well-known/pki-validation/x4.txt` | `https://validation.region.acm-validations.aws/y4/.well-known/pki-validation/x4.txt` | 고유 | | subdomain.example.com | `http://subdomain.example.com/.well-known/pki-validation/x5.txt` | `https://validation.region.acm-validations.aws/y5/.well-known/pki-validation/x5.txt` | 고유 | | host.subdomain.example.com | `http://host.subdomain.example.com/.well-known/pki-validation/x6.txt` | `https://validation.region.acm-validations.aws/y6/.well-known/pki-validation/x6.txt` | 고유 | 파일 이름의 *xN* 값과 ACM 제어 도메인의 *yN* 값은 ACM에서 생성하는 고유 식별자입니다. 예: ``` http://example.com/.well-known/pki-validation/3639ac514e785e898d2646601fa951d5.txt ``` 은(는) 결과로 생성된 **리디렉션 소스** URL를 나타냅니다. 연결된 **리디렉션 대상** URL은 동일한 검증 레코드에 대해 ``` https://validation.region.acm-validations.aws/98d2646601fa/.well-known/pki-validation/3639ac514e785e898d2646601fa951d5.txt ``` 일 수 있습니다. **참고** 웹 서버 또는 콘텐츠 전송 네트워크가 지정된 경로에서 리디렉션 설정을 지원하지 않는 경우 [HTTP 검증 문제 해결](troubleshooting-HTTP-validation.md)을 참조하세요. 인증서를 요청하고 HTTP 검증을 지정하면, ACM이 리디렉션 정보를 다음 형식으로 제공합니다. **** | 도메인 이름 | 리디렉션 소스 | 리디렉션 대상 | | --- | --- | --- | | example.com | http://example.com/.well-known/pki-validation/a79865eb4cd1a6ab990a45779b4e0b96.txt | https://validation.region.acm-validations.aws/a424c7224e9b/.well-known/pki-validation/a79865eb4cd1a6ab990a45779b4e0b96.txt | *도메인 이름*은 인증서와 연결된 FQDN입니다. *리디렉션 소스*는 ACM이 검증 파일을 찾을 도메인의 URL입니다. *리디렉션 대상*은 실제 검증 파일이 호스팅되는 ACM 제어 URL입니다. *리디렉션 소스* URL에서 *리디렉션 대상* URL로 요청을 리디렉션하도록 웹 서버 또는 CloudFront 배포를 구성해야 합니다. 이 리디렉션을 설정하는 정확한 방법은 웹 서버 소프트웨어 또는 CloudFront 구성에 따라 다릅니다. ACM이 도메인 소유권을 검증하고 인증서를 발급하거나 갱신할 수 있도록 리디렉션이 올바르게 설정되어 있는지 확인합니다. ## HTTP 검증 설정 ACM은 CloudFront에서 사용할 퍼블릭 SSL/TLS 인증서를 발급할 때 HTTP 검증을 사용하여 도메인 소유권을 확인합니다. 이 섹션에서는 HTTP 검증을 사용하도록 퍼블릭 인증서를 구성하는 방법에 대해서 설명합니다. **콘솔에서 HTTP 검증을 설정하려면** **참고** 이 절차에서는 이미 CloudFront를 통해 인증서를 요청했으며 인증서를 생성한 AWS 리전에서 작업하고 있다고 가정합니다. HTTP 검증은 CloudFront Distribution Tenants 기능을 통해서만 사용할 수 있습니다. 1. [https://console.aws.amazon.com/acm/](https://console.aws.amazon.com/acm/)에서 ACM 콘솔을 엽니다. 1. 인증서 목록에서 **검증 보류 중(Pending validation)** 상태인 구성하려는 **인증서 ID(Certificate ID)**를 선택합니다. 그러면 인증서에 대한 세부 정보 페이지가 열립니다. 1. **도메인** 섹션에서 인증서 요청의 각 도메인에 대한 **리디렉션 소스** 및 **리디렉션 대상** 값을 볼 수 있습니다. 1. 각 도메인에 대해 **리디렉션 소스** URL에서 **리디렉션 대상** URL로의 HTTP 리디렉션을 설정합니다. CloudFront 배포 구성을 통해이 작업을 수행할 수 있습니다. 1. **리디렉션 소스** URL에서 **리디렉션 대상** URL로 요청을 리디렉션하도록 CloudFront 배포를 구성합니다. 이 리디렉션을 설정하는 방법은 CloudFront 구성에 따라 다릅니다. 1. 리디렉션을 설정한 후에는 ACM이 도메인 소유권 검증을 자동으로 시도합니다. 이 프로세스는 최대 30분이 걸릴 수 있습니다. ACM이 리디렉션 값을 생성한 시각으로부터 72시간 내에 도메인 이름을 검증할 수 없는 경우, ACM은 인증서 상태를 **검증 시간 초과**로 변경합니다. 이 결과의 가장 가능성이 높은 이유는 HTTP 리디렉션을 성공적으로 설정하지 않았기 때문입니다. 이 문제를 해결하려면 리디렉션 지침을 검토한 후 새 인증서를 요청해야 합니다. **중요** 검증 문제를 방지하려면 **리디렉션 소스** 위치의 콘텐츠가 **리디렉션 대상** 위치의 콘텐츠와 일치해야 합니다. 문제가 발생하면 [HTTP 검증 문제 해결](troubleshooting-HTTP-validation.md) 단원을 참조하세요. **참고** DNS 검증과 달리 ACM이 HTTP 리디렉션의 자동 생성을 프로그래밍 방식으로 요청할 수 없습니다. CloudFront 배포 설정을 통해 이러한 리디렉션을 구성해야 합니다. HTTP 검증 작업 방법에 대한 자세한 내용은 [ACM에 대한 HTTP 리디렉션 작동 방식](#http-redirects-overview) 섹션을 참조하세요.