기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # AWS Certificate Manager 퍼블릭 인증서 퍼블릭 인증서를 요청한 후에는 [AWS Certificate Manager 퍼블릭 인증서에 대한 도메인 소유권 검증](domain-ownership-validation.md)에서 설명한 대로 도메인 소유권을 검증해야 합니다. 퍼블릭 ACM 인증서는 X.509 표준을 따르며 다음 제한 사항이 적용됩니다. + **이름:** DNS를 준수하는 주체 이름을 사용해야 합니다. 자세한 내용은 [도메인 이름](acm-concepts.md#concept-dn) 단원을 참조하십시오. + **알고리즘:** 암호화를 위해서는 인증서 프라이빗 키 알고리즘이 2048비트 RSA, 256비트 ECDSA 또는 384비트 ECDSA 중 하나에 해당해야 합니다. + **만료:** 각 인증서는 198일 동안 유효합니다. + **갱신:** ACM은 만료 45일 전에 퍼블릭 인증서를 자동으로 갱신하려고 시도합니다. **참고** 퍼블릭 ACM 인증서는 [Nitro Enclave](acm-services.md#acm-nitro-enclave)에 연결된 Amazon EC2 인스턴스에 설치할 수 있습니다. 모든 Amazon EC2 인스턴스에서 사용할 [퍼블릭 인증서를 내보낼 수도 있습니다](export-public-certificate.md). Nitro Enclave에 연결되지 않은 Amazon EC2 인스턴스에서 독립형 웹 서버를 설정하는 방법에 대한 자세한 내용은 [자습서: Amazon Linux 2에 LAMP 웹 서버 설치](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-lamp-amazon-linux-2.html) 또는 [자습서: Amazon Linux AMI를 사용하여 LAMP 웹 서버 설치](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/install-LAMP.html)를 참조하세요. 관리자는 ACM [조건부 키 정책](https://docs.aws.amazon.com/acm/latest/userguide/acm-conditions.html)을 사용하여 최종 사용자가 새 인증서를 발급하는 방법을 제어할 수 있습니다. 이러한 조건부 키를 사용하면 도메인, 유효성 검사 방법 및 인증서 요청과 관련된 기타 속성에 제한을 둘 수 있습니다. 인증서를 요청할 때 문제가 발생하면 [인증서 요청 문제 해결](troubleshooting-cert-requests.md) 단원을 참조하세요. 를 사용하여 프라이빗 PKI에 대한 인증서를 요청하려면 섹션을 AWS Private CA참조하세요[에서 프라이빗 인증서 요청 AWS Certificate Manager프라이빗 인증서 요청](gs-acm-request-private.md). **Topics** + [AWS Certificate Manager 퍼블릭 인증서 특성 및 제한 사항](acm-certificate-characteristics.md) + [에서 퍼블릭 인증서 요청 AWS Certificate Manager](acm-public-certificates.md) + [AWS Certificate Manager 내보내기 가능한 퍼블릭 인증서](acm-exportable-certificates.md) + [AWS Certificate Manager 퍼블릭 인증서에 대한 도메인 소유권 검증](domain-ownership-validation.md) # AWS Certificate Manager 퍼블릭 인증서 특성 및 제한 사항 ACM이 제공하는 퍼블릭 인증서에는 다음과 같은 특성과 제한 사항이 있습니다. 이러한 사항은 ACM에서 제공하는 인증서에만 적용되고, [가져온 인증서](import-certificate.md)에는 적용되지 않습니다. **브라우저 및 애플리케이션 신뢰** Google Chrome, Microsoft Edge, Mozilla Firefox, Apple Safari 등 모든 주요 브라우저에서 ACM 인증서를 신뢰합니다. 브라우저는 TLS에 의해 ACM 인증서를 사용하여 사이트에 연결될 때 자물쇠 아이콘을 표시합니다. Java는 ACM 인증서도 신뢰합니다. **인증 기관 및 계층 구조** ACM을 통해 요청하는 공인 인증서는 아마존 관리형 퍼블릭 [인증 기관(CA)](https://docs.aws.amazon.com/acm/latest/userguide/acm-concepts.html#concept-ca)인 [Amazon Trust Services](https://www.amazontrust.com/repository/)에서 제공합니다. Amazon Root CA 1\$14는 Starfield G2 Root Certificate Authority - G2에 의해 상호 서명됩니다. Starfield 루트는 Android(최신 Gingerbread 버전) 및 iOS(버전 4.1 이상)에서 신뢰할 수 있습니다. Amazon 루트는 iOS 11 이상에서 신뢰할 수 있습니다. Amazon 또는 Starfield 루트가 포함된 모든 브라우저, 애플리케이션 또는 OS는 ACM 퍼블릭 인증서를 신뢰합니다. ACM은 인증서 유형(RSA 또는 ECDSA)을 기반으로 무작위 할당된 중간 CA를 통해 고객에게 리프 또는 최종 엔터티 인증서를 발급합니다. 이 무작위 선택으로 인해 ACM은 중간 CA 정보를 제공하지 않습니다. **도메인 검증(DV)** ACM 인증서는 도메인 검증을 거쳐 도메인 이름만 식별합니다. ACM 인증서를 요청할 때는 지정된 모든 도메인의 소유권 또는 제어권을 증명해야 합니다. 이메일 혹은 DNS를 사용해 소유권을 검증할 수 있습니다. 자세한 내용은 [AWS Certificate Manager 이메일 검증](email-validation.md) 및 [AWS Certificate Manager DNS 검증DNS 검증](dns-validation.md) 섹션을 참조하세요. **HTTP 검증** ACM은 CloudFront에서 사용할 퍼블릭 TLS 인증서를 발급할 때 도메인 소유권 확인을 위한 HTTP 검증을 지원합니다. 이 방식은 HTTP 리디렉션을 사용하여 도메인 소유권을 증명하고 DNS 검증과 유사한 자동 갱신을 제공합니다. HTTP 검증은 현재 CloudFront Distribution Tenants 기능을 통해서만 사용할 수 있습니다. **HTTP 리디렉션** HTTP 검증을 위해 ACM은 `RedirectFrom` URL 및 `RedirectTo` URL을 제공합니다. 도메인 제어권을 증명하려면 `RedirectFrom`에서 `RedirectTo`로의 리디렉션을 설정해야 합니다. `RedirectFrom` URL에는 검증된 도메인이 포함되는 반면, `RedirectTo`는 고유한 검증 토큰이 포함된 CloudFront 인프라의 ACM 제어 위치를 가리킵니다. **에서 관리** 다른 서비스에서 관리하는 ACM의 인증서는 `ManagedBy` 필드에 해당 서비스의 ID를 보여줍니다. CloudFront에서 HTTP 검증을 사용하는 인증서의 경우 이 필드에 "CLOUDFRONT"가 표시됩니다. 이러한 인증서는 CloudFront를 통해서만 사용할 수 있습니다. `ManagedBy` 필드는 **DescribeCertificate** 및 **ListCertificates** API와 ACM 콘솔의 인증서 인벤토리 및 세부 정보 페이지에 표시됩니다. `ManagedBy` 필드는 "Can be used with" 속성과 상호 배타적입니다. CloudFront 관리형 인증서의 경우 다른 AWS 서비스를 통해 새 사용량을 추가할 수 없습니다. 이러한 인증서는 CloudFront API를 통해서만 더 많은 리소스에 사용할 수 있습니다. **중간 및 루트 CA 교체** Amazon은 복원력이 뛰어난 인증서 인프라를 유지하기 위해 통지 없이 중간 CA를 중단할 수 있습니다. 이러한 변경 사항은 고객에게 영향을 주지 않습니다. 자세한 내용은 ["Amazon introduces dynamic intermediate certificate authorities(Amazon, 동적 중간 인증 기관 도입)](https://aws.amazon.com/blogs/security/amazon-introduces-dynamic-intermediate-certificate-authorities/)"를 참조하세요. Amazon이 루트 CA를 중단하는 경우, 필요에 따라 빠르게 변경이 이루어집니다. Amazon은 , Health Dashboard이메일, 기술 계정 관리자에게 연락 등 사용 가능한 모든 방법을 사용하여 AWS 고객에게 알립니다. **해지를 위한 방화벽 액세스** 취소된 최종 엔터티 인증서는 OCSP 및 CRL을 사용하여 취소 정보를 확인하고 게시합니다. 이러한 메커니즘을 허용하기 위해 일부 고객 방화벽에 추가 규칙이 필요할 수 있습니다. 다음 URL 와일드카드 패턴을 사용하여 취소 트래픽을 식별합니다. + **OCSP** `http://ocsp.?????.amazontrust.com` `http://ocsp.*.amazontrust.com` + **CRL** `http://crl.?????.amazontrust.com/?????.crl` `http://crl.*.amazontrust.com/*.crl` 별표(\$1) 와일드카드는 하나 이상의 영숫자 문자에 해당하고, 물음표(?)는 단일 영숫자를 나타내고, 해시 마크(\$1)는 숫자를 나타냅니다. **키 알고리즘** 인증서는 반드시 알고리즘과 키 크기를 지정해야 합니다. ACM은 다음과 같은 RSA 및 ECDSA 퍼블릭 키 알고리즘을 지원합니다. + RSA 1024비트(`RSA_1024`) + RSA 2048비트(`RSA_2048`)\$1 + RSA 3072비트(`RSA_3072`) + RSA 4096비트(`RSA_4096`) + ECDSA 256비트(`EC_prime256v1`)\$1 + ECDSA 384비트(`EC_secp384r1`)\$1 + ECDSA 521비트(`EC_secp521r1`) ACM에서는 별표(\$1)로 표시된 알고리즘을 사용하여 새 인증서를 요청할 수 있습니다. 기타 알고리즘은 [가져온](import-certificate.md) 인증서에만 사용됩니다. AWS Private CA CA에서 서명한 프라이빗 PKI 인증서의 경우 서명 알고리즘 패밀리(RSA 또는 ECDSA)가 CA의 보안 키 알고리즘 패밀리와 일치해야 합니다. ECDSA 키는 유사한 보안 수준의 RSA 키보다 작고 컴퓨팅 효율성이 뛰어나지만 모든 네트워크 클라이언트가 ECDSA를 지원하는 것은 아닙니다. [NIST](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf)에서 발췌한 이 표는 RSA 및 ECDSA 키 크기(비트)를 비교하여 동등한 보안 강도를 제공합니다. **알고리즘과 키의 보안 비교** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/acm/latest/userguide/acm-certificate-characteristics.html) 2의 거듭제곱으로 표현되는 보안 강도는 암호를 해제하는 데 필요한 추측의 수와 연관되어 있습니다. 예를 들어 3072비트 RSA 키와 256비트 ECDSA 키는 모두 2128회 이하의 추측으로 검색이 가능합니다. 알고리즘 선택에 도움이 필요하면 AWS 블로그 게시물에서 [ECDSA 인증서를 평가하고 사용하는 방법을 참조하세요 AWS Certificate Manager](https://aws.amazon.com/blogs/security/how-to-evaluate-and-use-ecdsa-certificates-in-aws-certificate-manager/). [통합 서비스](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html)는 리소스에 대해 지원되는 알고리즘 및 키 크기만 허용합니다. 지원은 인증서를 IAM으로 가져오는지 ACM으로 가져오는지에 따라 달라집니다. 세부 정보는 각 서비스 문서를 참조하세요. + Elastic Load Balancing의 경우 [Application Load Balancer를 위한 HTTPS 리스너](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html)를 참조하세요. + CloudFront의 경우 [지원되는 SSL/TLS 프로토콜 및 암호](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/secure-connections-supported-viewer-protocols-ciphers.html)를 참조하세요. **관리형 갱신 및 배포** ACM은 ACM 인증서의 갱신 및 프로비저닝을 관리합니다. 자동 갱신은 잘못된 구성, 취소 또는 만료된 인증서로 인한 가동 중지를 방지하는 데 도움이 됩니다. 자세한 내용은 [에서 관리형 인증서 갱신 AWS Certificate Manager](managed-renewal.md) 단원을 참조하십시오. **여러 도메인 이름** 각 ACM 인증서에는 하나 이상의 정규화된 도메인 이름(FQDN)이 포함되어 있어야 하며 이름을 추가할 수 있습니다. 예를 들어 `www.example.com`에 대한 인증서에는 `www.example.net`도 포함될 수 있습니다. 이는 베어 도메인(zone apex 또는 네이키드 도메인)에도 적용됩니다. www.example.com에 대한 인증서를 요청하고 example.com을 추가할 수 있습니다. 자세한 내용은 [AWS Certificate Manager 퍼블릭 인증서](gs-acm-request-public.md) 단원을 참조하십시오. **퓨니코드** [다국어 도메인 이름](https://www.icann.org/resources/pages/idn-2012-02-25-en)에 대한 다음 [Punycode](https://datatracker.ietf.org/doc/html/rfc3492) 요구 사항을 충족해야 합니다. 1. ‘--’ 패턴으로 시작하는 도메인 이름은 ‘xn--’과 일치해야 합니다. 1. ‘xn--’으로 시작하는 도메인 이름도 유효한 다국어 도메인 이름이어야 합니다. **Punycode 예제** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/acm/latest/userguide/acm-certificate-characteristics.html) **유효성 기간** ACM 인증서는 198일 동안 유효합니다. **와일드카드 이름** ACM은 도메인 이름에 별표(\$1)를 사용하여 동일한 도메인에서 여러 사이트를 보호할 수 있는 와일드카드 인증서를 생성할 수 있게 해 줍니다. 예를 들어 `*.example.com`은 `www.example.com` 및 `images.example.com`을 보호합니다. 와일드카드 인증서에서 별표(`*`)는 도메인 이름의 맨 왼쪽에 와야 하며 하나의 하위 도메인 수준만 보호합니다. 예를 들어, `*.example.com`은 `login.example.com` 및 `test.example.com`을 보호하지만 `test.login.example.com`은 보호하지 않습니다. 또한 `*.example.com`은 의 하위 도메인*만* 보호하고 베어 또는 apex 도메인(`example.com`)은 보호하지 않습니다. `example.com` 및 `*.example.com`과 같은 여러 도메인 이름을 지정하여 베어 도메인과 해당 하위 도메인 모두에 대한 인증서를 요청할 수 있습니다. 참고로, CloudFront를 사용하는 경우 HTTP 검증은 와일드카드 인증서를 지원하지 않습니다. 와일드카드 인증서의 경우 DNS 검증 또는 이메일 검증을 사용해야 합니다. 자동 인증서 갱신을 지원하는 DNS 검증을 사용하는 것이 좋습니다. # 에서 퍼블릭 인증서 요청 AWS Certificate Manager ACM 콘솔 AWS CLI또는 API에서 AWS Certificate Manager 퍼블릭 인증서를 요청할 수 있습니다. 이러한 인증서를 통합과 함께 AWS 서비스 사용하거나 외부에서 사용할 수 있도록 내보낼 수 있습니다 AWS 클라우드. 다음 목록은 퍼블릭 인증서와 익스포터블 퍼블릭 인증서의 차이점을 설명하고 있습니다. **퍼블릭 인증서** Elastic Load Balancing, Amazon CloudFront 및 Amazon API Gateway와 AWS 서비스 같이 통합된와 함께 ACM 퍼블릭 인증서를 사용합니다. 자세한 내용은 [ACM에 통합된 서비스](acm-services.md) 단원을 참조하십시오. 2025년 6월 17일 이전에 생성된 ACM 퍼블릭 인증서는 내보낼 수 없습니다. **익스포터블 퍼블릭 인증서** 내보내기 가능한 퍼블릭 인증서는 통합에서 작동 AWS 서비스 하며 외부에서도 사용할 수 있습니다 AWS 클라우드. 자세한 내용은 [AWS Certificate Manager 내보내기 가능한 퍼블릭 인증서](acm-exportable-certificates.md) 및 [ACM에 통합된 서비스](acm-services.md) 섹션을 참조하세요. 퍼블릭 인증서를 내보낼 수 있으려면 새 ACM 퍼블릭 인증서를 생성하고 익스포터블을 활성화해야 합니다. 다음 섹션에서는 퍼블릭 ACM 인증서를 요청, 내보내기 및 취소하는 방법을 설명합니다. **Topics** + [콘솔을 사용하여 퍼블릭 인증서 요청](#request-public-console) + [CLI를 사용하여 퍼블릭 인증서 요청](#request-public-cli) ## 콘솔을 사용하여 퍼블릭 인증서 요청 **ACM 퍼블릭 인증서를 요청하려면(콘솔)** 1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/acm/home](https://console.aws.amazon.com/acm/home) ACM 콘솔을 엽니다. **인증서 요청**을 선택합니다. 1. **도메인 이름(Domain names)** 섹션에서 도메인 이름을 입력합니다. **www.example.com** 같은 FQDN(Fully Qualified Domain Name)이나 **example.com** 같은 베어 또는 apex 도메인 이름을 사용할 수 있습니다. 맨 왼쪽에서 별표(**\$1**)를 와일드카드로 사용하여 동일한 도메인 내에서 여러 사이트 이름을 보호할 수도 있습니다. 예를 들어 **\$1.example.com**은 **corp.example.com** 및 **images.example.com**을 보호합니다. 와일드카드 이름은 **주체(Subject)** 필드와 ACM 인증서의 **주체 대체 이름(Subject Alternative Name)** 확장에 표시됩니다. 와일드카드 인증서를 요청할 때 별표(**\$1**)는 도메인 이름의 맨 왼쪽에 와야 하며 하나의 하위 도메인 수준만 보호할 수 있습니다. 예를 들어 **\$1.example.com**은 **login.example.com** 및 **test.example.com**을 보호할 수 있지만 **test.login.example.com**은 보호할 수 없습니다. 또한 **\$1.example.com**은 **example.com**의 하위 도메인*만* 보호하고 베어 또는 apex 도메인(**example.com**)은 보호하지 못합니다. 둘 모두를 보호하려면 다음 단계를 참조하세요. **참고** [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280)에 따라, 이 단계에서 입력하는 도메인 이름(일반 이름)의 길이는 마침표를 포함하여 64 옥텟(자)을 초과할 수 없습니다. 다음 단계에서 보듯이 사용자가 제공하는 각 주체 대체 이름(SAN)의 길이는 최대 253옥텟입니다. 1. 다른 이름을 추가하려면 **이 인증서에 다른 이름 추가**를 선택하고 텍스트 상자에 이름을 입력합니다. 이렇게 하면 베어 또는 apex 도메인(예: **example.com**)과 하위 도메인(예: **\$1.example.com**)을 보호하는 데 유용합니다. 1. ACM 익스포터블 퍼블릭 인증서를 생성하려면 **내보내기 활성화** 옵션을 선택합니다. 인증서의 프라이빗 키에 액세스하여 AWS 클라우드외부에서 사용할 수 있습니다. 자세한 내용은 [AWS Certificate Manager 내보내기 가능한 퍼블릭 인증서](acm-exportable-certificates.md) 단원을 참조하십시오. 1. **검증 방법(Validation method)** 섹션에서 필요에 따라 **DNS 검증 - 권장(DNS validation - recommended)** 또는 **이메일 검증(Email validation)**을 선택합니다. **참고** 사용자 DNS 환경 설정을 편집할 수 있다면, 이메일 검증보다는 DNS 검증을 사용하는 것을 권장합니다. DNS 검증은 이메일 검증에 비해 다양한 이점이 있습니다. [AWS Certificate Manager DNS 검증DNS 검증](dns-validation.md)을(를) 참조하세요. ACM은 인증서 요청 시 인증서를 발급하기 전에 귀사가 도메인 이름을 소유하거나 관리 권한을 보유하고 있는지 검증합니다. 이메일 검증 혹은 DNS 검증을 사용할 수 있습니다. 1. 이메일 검증을 선택하면 ACM은 도메인 이름 필드에 지정한 도메인으로 검증 이메일을 전송합니다. 검증 도메인을 지정하면 ACM이 대신 해당 검증 도메인으로 이메일을 전송합니다. 이메일 검증에 대한 자세한 내용은 [AWS Certificate Manager 이메일 검증](email-validation.md)를 참조하세요. 1. DNS 검증을 선택하면 사용자는 사용자 DNS 환경 설정을 위해 ACM이 제공한 CNAME 기록을 추가하기만 하면 됩니다. DNS 검증에 대한 자세한 내용은 [AWS Certificate Manager DNS 검증DNS 검증](dns-validation.md) 단원을 참조하세요. 1. **키 알고리즘** 섹션에서 알고리즘을 선택합니다. 1. **태그** 페이지에서 선택 사항으로 인증서에 태그를 지정할 수 있습니다. 태그는 AWS 리소스를 식별하고 구성하기 위한 메타데이터 역할을 하는 키-값 페어입니다. ACM 태그 파라미터 목록과 생성 후 인증서에 태그를 추가하는 방법에 대한 지침은 [AWS Certificate Manager 리소스 태그 지정](tags.md) 섹션을 참조하세요. 태그 추가를 마치면 **요청(Request)**을 선택합니다. 1. 요청이 처리되면 콘솔에서 인증서 목록으로 돌아가고, 여기에 새 인증서의 정보가 표시됩니다. [인증서 요청 실패](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-cert-requests.html#troubleshooting-failed) 문제 해결 주제에 나와 있는 이유 중의 하나에 의해 실패하지 않는 한, 인증서는 요청을 받으면 **검증 보류(Pending validation)** 상태에 들어갑니다. ACM이 72시간 동안 인증서의 유효성 검증을 반복적으로 시도한 다음 시간이 초과됩니다. 인증서에 **실패** 또는 **검증 시간 초과** 상태가 표시되는 경우 요청을 삭제하고 [DNS 검증](https://docs.aws.amazon.com/acm/latest/userguide/dns-validation.html) 또는 [이메일 검증](https://docs.aws.amazon.com/acm/latest/userguide/email-validation.html)으로 문제를 수정한 다음 다시 시도하세요. 검증에 성공한 경우에는 인증서가 **발급 완료** 상태에 들어갑니다. **참고** 목록을 정렬한 방법에 따라 찾고 있는 인증서가 즉시 표시되지 않을 수 있습니다. 오른쪽의 검은색 삼각형을 클릭하여 순서를 변경할 수 있습니다. 오른쪽 상단의 페이지 번호를 사용하여 여러 페이지의 인증서를 탐색할 수도 있습니다. ## CLI를 사용하여 퍼블릭 인증서 요청 [request-certificate](https://docs.aws.amazon.com/cli/latest/reference/acm/request-certificate.html) 명령을 사용하여 명령줄에서 새 퍼블릭 ACM 인증서를 요청합니다. 검증 방법에 대해 선택 가능한 값은 DNS와 이메일입니다. 키 알고리즘에 대해 선택 가능한 값은 RSA\$12048(파라미터가 명시적으로 제공되지 않은 경우 기본값), EC\$1prime256v1 및 EC\$1secp384r1입니다. ``` aws acm request-certificate \ --domain-name www.example.com \ --key-algorithm EC_Prime256v1 \ --validation-method DNS \ --idempotency-token 1234 \ --options CertificateTransparencyLoggingPreference=DISABLED,Export=ENABLED ``` 이 명령은 새 공용 인증서의 Amazon 리소스 이름(ARN)을 출력합니다. ``` { "CertificateArn": "arn:aws:acm:Region:444455556666:certificate/certificate_ID" } ``` # AWS Certificate Manager 내보내기 가능한 퍼블릭 인증서 AWS Certificate Manager 내보내기 가능한 퍼블릭 인증서를 사용하면 Amazon EC2 인스턴스, 컨테이너 및 온프레미스 호스트를 포함하여 어디서나 [SSL/TLS 인증서를](acm-concepts.md#concept-sslcert) 프로비저닝, 관리 및 배포할 수 있습니다. 이 기능은 ACM에서 발급한 퍼블릭 인증서를 통합 이상으로 확장 AWS 서비스하여 전체 인프라에서 인증서를 중앙 집중식으로 제어할 수 있습니다. ## 이점 다음은 ACM 익스포터블 퍼블릭 인증서의 이점을 간략하게 설명합니다. + *간소화된 인증서 관리*: ACM을 사용하여 모든 리소스의 인증서를 중앙에서 관리합니다. + *더 빠른 인증서 발급*: 더 짧은 시간 내에 인증서를 액세스하고 사용합니다. + *자동 갱신*: ACM은 인증서 갱신을 자동으로 처리하고 새 인증서를 배포할 준비가 되면 알려줍니다. 자세한 내용은 [ACM에 대한 Amazon EventBridge 지원](supported-events.md) 단원을 참조하십시오. + *비용 효율성*: 생성한 익스포터블 퍼블릭 인증서에 대해서만 비용을 지불합니다. + *유연한 배포*: 표준 [SSL/TLS 인증서](acm-concepts.md#concept-sslcert)를 지원하는 모든 서버 또는 애플리케이션에 인증서를 사용합니다. ## ACM 익스포터블 퍼블릭 인증서의 작동 방식 다음은 ACM 익스포터블 퍼블릭 인증서의 작동 방식을 간략하게 설명합니다. 1. ACM을 통해 도메인에 대한 익스포터블 인증서를 요청합니다. 1. DNS 또는 이메일 검증을 사용하여 도메인 소유권을 검증합니다. 1. 인증서, 프라이빗 키 및 인증서 체인을 내보냅니다. 1. 서버 또는 애플리케이션에 인증서를 배포합니다. 1. ACM은 갱신을 관리하고 새 인증서를 사용할 수 있을 때 알림을 보냅니다. ## 보안 고려 사항 다음은 ACM 익스포터블 퍼블릭 인증서를 사용할 때의 보안 고려 사항입니다. 자세한 내용은 [의 데이터 보호 AWS Certificate Manager](data-protection.md) 단원을 참조하십시오. + 내보낸 프라이빗 키를 보안 스토리지 및 액세스 제어를 사용하여 보호합니다. + 키 손상이 의심되는 경우 ACM의 취소 기능을 사용합니다. + 갱신된 인증서를 배포할 때 적절한 키 교체 절차를 구현합니다. ## 제한 사항 다음은 몇 가지 ACM 인증서 제한 사항입니다. + 인증서의 유효 기간은 198일입니다. + ACM은 만료 날짜 45일 전에 만료되도록 설정된 인증서를 갱신합니다. + 내보낸 인증서의 배포 프로세스를 관리해야 합니다. ## 가격 책정 생성한 내보내기 가능한 퍼블릭 SSL/TLS 인증서에는 추가 요금이 부과됩니다 AWS Certificate Manager. 최신 ACM 요금 정보는 AWS 웹 사이트의 [AWS Certificate Manager 서비스 요금](https://aws.amazon.com//certificate-manager/pricing/) 페이지를 참조하세요. ## 모범 사례 다음은 ACM 인증서를 사용할 때의 몇 가지 모범 사례입니다. + 인증서가 갱신되면 즉시 사용을 시작해야 합니다. + 갱신된 인증서에 대한 자동 배포 프로세스를 테스트하고 구현합니다. + [Amazon EventBridge 지표 및 경보](supported-events.md)를 사용하여 인증서 배포를 모니터링합니다. # AWS Certificate Manager 퍼블릭 인증서 내보내기 다음 절차에서는 ACM 콘솔에서 ACM 퍼블릭 인증서를 내보내는 방법을 안내합니다. 또는 [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm/export-certificate.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm/export-certificate.html) AWS CLI [ExportCertificate](https://docs.aws.amazon.com//acm/latest/APIReference/API_ExportCertificate.html) API 작업을 사용할 수도 있습니다. **참고** 2025년 6월 17일 이전에 생성된 ACM 퍼블릭 인증서는 내보낼 수 없습니다. ## 퍼블릭 인증서 내보내기(콘솔) 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/acm/](https://console.aws.amazon.com/acm/) ACM 콘솔을 엽니다. 1. **인증서 나열**을 선택하고 내보낼 인증서의 확인란을 선택합니다. 1. 또는 인증서를 선택할 수 있습니다. 인증서 세부 정보 페이지에서 **내보내기**를 선택합니다. 1. **추가 작업**을 선택한 다음 **내보내기**를 선택합니다. 1. 프라이빗 키의 암호를 입력하고 확인합니다. 1. 인증서 파일을 다운로드하거나 복사할 수 있습니다. **참고** ACM 콘솔에서 .pem 인증서 파일을 내보낼 수 있습니다. .pem 파일을 .ppk와 같은 다른 파일 형식으로 변환할 수 있습니다. 자세한 내용은 이 [re:Post 문서](https://repost.aws/knowledge-center/ec2-ppk-pem-conversion)를 참조하세요. ## 퍼블릭 인증서 내보내기(AWS CLI) [https://docs.aws.amazon.com/cli/latest/reference/acm/export-certificate.html](https://docs.aws.amazon.com/cli/latest/reference/acm/export-certificate.html) AWS CLI 명령 또는 [ExportCertificate](https://docs.aws.amazon.com//acm/latest/APIReference/API_ExportCertificate.html) API 작업을 사용하여 퍼블릭 인증서와 프라이빗 키를 내보냅니다. 명령을 실행할 때 암호를 할당해야 합니다. 보안을 강화하려면 파일 편집기를 사용하여 파일에 암호를 저장한 다음 파일을 제공하여 암호를 제공합니다. 이렇게 하면 암호가 명령 레코드에 저장되지 않으며 암호를 입력할 때 다른 사람이 암호를 볼 수 없습니다. **참고** 암호가 포함된 파일은 행 종결자로 끝나지 않아야 합니다. 다음과 같은 암호 파일을 확인할 수 있습니다. ``` $ file -k passphrase.txt passphrase.txt: ASCII text, with no line terminators ``` 다음 예제는 명령 출력을 `jq`로 파이핑하여 PEM 형식 지정을 적용합니다. ``` [Windows/Linux]$ aws acm export-certificate \ --certificate-arn arn:aws:acm:us-east-1:111122223333:certificate/certificate_ID \ --passphrase fileb://path-to-passphrase-file \ | jq -r '"\(.Certificate)\(.CertificateChain)\(.PrivateKey)"' ``` 이것은 base64로 인코딩된, PEM 형식 인증서를 출력하며, 다음 축약된 예에서와 같이 인증서 체인과 프라이빗 키도 포함합니다. ``` -----BEGIN CERTIFICATE----- MIIDTDCCAjSgAwIBAgIRANWuFpqA16g3IwStE3vVpTwwDQYJKoZIhvcNAQELBQAw EzERMA8GA1UECgwIdHJvbG9sb2wwHhcNMTkwNzE5MTYxNTU1WhcNMjAwODE5MTcx NTU1WjAXMRUwEwYDVQQDDAx3d3cuc3B1ZHMuaW8wggEiMA0GCSqGSIb3DQEBAQUA ... 8UNFQvNoo1VtICL4cwWOdLOkxpwkkKWtcEkQuHE1v5Vn6HpbfFmxkdPEasoDhthH FFWIf4/+VOlbDLgjU4HgtmV4IJDtqM9rGOZ42eFYmmc3eQO0GmigBBwwXp3j6hoi 74YM+igvtILnbYkPYhY9qz8h7lHUmannS8j6YxmtpPY= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIC8zCCAdugAwIBAgIRAM/jQ/6h2/MI1NYWX3dDaZswDQYJKoZIhvcNAQELBQAw EzERMA8GA1UECgwIdHJvbG9sb2wwHhcNMTkwNjE5MTk0NTE2WhcNMjkwNjE5MjA0 NTE2WjATMREwDwYDVQQKDAh0cm9sb2xvbDCCASIwDQYJKoZIhvcNAQEBBQADggEP ... j2PAOviqIXjwr08Zo/rTy/8m6LAsmm3LVVYKLyPdl+KB6M/+H93Z1/Bs8ERqqga/ 6lfM6iw2JHtkW+q4WexvQSoqRXFhCZWbWPZTUpBS0d4/Y5q92S3iJLRa/JQ0d4U1 tWZyqJ2rj2RL+h7CE71XIAM//oHGcDDPaQBFD2DTisB/+ppGeDuB -----END CERTIFICATE----- -----BEGIN ENCRYPTED PRIVATE KEY----- MIIFKzBVBgkqhkiG9w0BBQ0wSDAnBgkqhkiG9w0BBQwwGgQUMrZb7kZJ8nTZg7aB 1zmaQh4vwloCAggAMB0GCWCGSAFlAwQBKgQQDViroIHStQgNOjR6nTUnuwSCBNAN JM4SG202YPUiddWeWmX/RKGg3lIdE+A0WLTPskNCdCAHqdhOSqBwt65qUTZe3gBt ... ZGipF/DobHDMkpwiaRR5sz6nG4wcki0ryYjAQrdGsR6EVvUUXADkrnrrxuHTWjFl wEuqyd8X/ApkQsYFX/nhepOEIGWf8Xu0nrjQo77/evhG0sHXborGzgCJwKuimPVy Fs5kw5mvEoe5DAe3rSKsSUJ1tM4RagJj2WH+BC04SZWNH8kxfOC1E/GSLBCixv3v +Lwq38CEJRQJLdpta8NcLKnFBwmmVs9OV/VXzNuHYg== -----END ENCRYPTED PRIVATE KEY----- ``` 모든 요소를 파일로 출력하려면 이전 예제에 `>` 리디렉션을 추가하여 다음 명령을 출력합니다. ``` $ aws acm export-certificate \ --certificate-arn arn:aws:acm:us-east-1:111122223333:certificate/certificate_ID \ --passphrase fileb://path-to-passphrase-file \ | jq -r '"\(.Certificate)\(.CertificateChain)\(.PrivateKey)"' \ > /tmp/export.txt ``` # ACM 인증서를 사용하여 Kubernetes 워크로드 보호 Kubernetes용 AWS 컨트롤러(ACK)와 함께 AWS Certificate Manager 내보내기 가능한 퍼블릭 인증서를 사용하여 ACM에서 Kubernetes 워크로드로 퍼블릭 TLS 인증서를 발급하고 내보낼 수 있습니다. 이 통합을 통해 Amazon Elastic Kubernetes Service(Amazon EKS) 포드를 보호하고 Kubernetes 수신 시 TLS를 종료할 수 있습니다. 시작하려면 GitHub의 [Kubernetes용 ACM 컨트롤러](https://github.com/aws-controllers-k8s/acm-controller)를 참조하세요. AWS Kubernetes용 컨트롤러(ACK)는 Kubernetes API를 확장하여 네이티브 Kubernetes 매니페스트를 사용하여 AWS 리소스를 관리합니다. ACM용 ACK 서비스 컨트롤러는 Kubernetes 워크플로 내에서 자동화된 인증서 수명 주기 관리를 제공합니다. Kubernetes에서 ACM 인증서 리소스를 생성하면 ACK 컨트롤러는 다음 작업을 수행합니다. 1. 인증서 서명 요청(CSR)을 생성하는 ACM에서 인증서를 요청합니다. 1. 도메인 검증이 완료되고 ACM이 인증서를 발급할 때까지 기다립니다. 1. `exportTo` 필드가 지정된 경우는 발급된 인증서와 프라이빗 키를 내보내고 지정된 Kubernetes 보안 암호에 저장합니다. 1. `exportTo` 필드를 지정하고 인증서를 갱신할 수 있는 경우는 만료 전에 Kubernetes 보안 암호를 갱신된 인증서로 업데이트합니다. 공개적으로 발급된 인증서는 ACM이 발급하기 전에 [도메인 검증](https://docs.aws.amazon.com//acm/latest/userguide/dns-validation.html)이 필요합니다. [Amazon Route 53용 ACK 서비스 컨트롤러](https://github.com/aws-controllers-k8s/route53-controller)를 사용하여 호스팅 영역에 필요한 DNS 검증 CNAME 레코드를 자동으로 생성할 수 있습니다. ## 인증서 사용 옵션 다음과 같은 몇 가지 방법으로 Kubernetes에서 ACM 인증서를 사용할 수 있습니다. ![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/acm/latest/userguide/images/kubernetes-acm.png) 1. *로드 밸런서 종료(내보내기 제외)*: ACK를 통해 인증서를 발급하고 이를 사용하여 AWS 로드 밸런서에서 TLS를 종료합니다. 인증서는 ACM에 남아 있으며 [AWS Load Balancer 컨트롤러](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.1/guide/ingress/cert_discovery/)에서 자동으로 검색됩니다. 이 접근 방식은 인증서를 내보낼 필요가 없습니다. 1. *수신 종료(내보내기 포함)*: ACM에서 인증서를 내보내고 수신 수준에서 TLS 종료를 위해 Kubernetes 보안 암호에 저장합니다. 이렇게 하면 Kubernetes 워크로드 내에서 직접 인증서를 사용할 수 있습니다. **참고** 프라이빗 인증서가 필요한 사용 사례는 cert-manager 플러그인인 [AWS Kubernetes용 프라이빗 CA 커넥터를](https://docs.aws.amazon.com//privateca/latest/userguide/PcaKubernetes-concepts.html) 참조하세요. ## 사전 조건 ACM용 ACK 서비스 컨트롤러를 설치하기 전에 다음이 있는지 확인합니다. + Kubernetes 클러스터. + Helm이 설치되었습니다. + 클러스터와 통신하도록 구성된 `kubectl`. + `eksctl` EKS에서 포드 자격 증명 연결을 구성하기 위해 설치됩니다. ## ACM용 ACK 서비스 컨트롤러 설치 Helm을 사용하여 Amazon EKS 클러스터에 ACM용 ACK 서비스 컨트롤러를 설치합니다. 1. ACK 컨트롤러의 네임스페이스를 생성합니다. ``` $ kubectl create namespace ack-system --dry-run=client -o yaml | kubectl apply -f - ``` 1. ACK 컨트롤러에 대한 포드 자격 증명 연결을 생성합니다. *CLUSTER\$1NAME*을 클러스터 이름으로 바꾸고 *REGION*을 AWS 리전으로 바꿉니다. ``` $ eksctl create podidentityassociation --cluster CLUSTER_NAME --region REGION \ --namespace ack-system \ --create-service-account \ --service-account-name ack-acm-controller \ --permission-policy-arns arn:aws:iam::aws:policy/AWSCertificateManagerFullAccess ``` 1. Amazon ECR 퍼블릭 레지스트리에 로그인합니다. ``` $ aws ecr-public get-login-password --region us-east-1 | helm registry login --username AWS --password-stdin public.ecr.aws ``` 1. ACM용 ACK 서비스 컨트롤러를 설치합니다. *REGION*을 해당 AWS 리전으로 바꿉니다. ``` $ helm install -n ack-system ack-acm-controller oci://public.ecr.aws/aws-controllers-k8s/acm-chart --set serviceAccount.create=false --set serviceAccount.name=ack-acm-controller --set aws.region=REGION ``` 1. 컨트롤러가 실행 중인지 확인합니다. ``` $ kubectl get pods -n ack-system ``` 포드 자격 증명 연결에 대한 자세한 내용은 *Amazon* [EKS 사용 설명서의 EKS 포드 자격 증명을](https://docs.aws.amazon.com//eks/latest/userguide/pod-identities.html) 참조하세요. ## 예: 수신 시 TLS 종료 다음 예제에서는 ACM 인증서를 내보내고 이를 사용하여 Kubernetes 수신 수준에서 TLS를 종료하는 방법을 보여줍니다. 이 구성은 ACM 인증서를 생성하여 Kubernetes 보안 암호로 내보내고 TLS 종료에 인증서를 사용하도록 수신 리소스를 구성합니다. 이 예시는 다음과 같이 설정되어 있습니다. + 내보낸 인증서를 저장하기 위해 보안 암호가 생성됩니다(`exported-cert-secret`). + ACK 인증서 리소스는 도메인에 대해 ACM에서 인증서를 요청하고 `exported-cert-secret` 보안 암호로 내보냅니다. + 수신 리소스는 `exported-cert-secret`를 참조하여 수신 트래픽에 대한 TLS를 종료합니다. `${HOSTNAME}`을 사용자 이름으로 바꿉니다. ``` apiVersion: v1 kind: Secret type: kubernetes.io/tls metadata: name: exported-cert-secret namespace: demo-app data: tls.crt: "" tls.key: "" --- apiVersion: acm.services.k8s.aws/v1alpha1 kind: Certificate metadata: name: exportable-public-cert namespace: demo-app spec: domainName: ${HOSTNAME} options: certificateTransparencyLoggingPreference: ENABLED exportTo: namespace: demo-app name: exported-cert-secret key: tls.crt --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress-traefik namespace: demo-app spec: tls: - hosts: - ${HOSTNAME} secretName: exported-cert-secret ingressClassName: traefik rules: - host: ${HOSTNAME} http: paths: - path: / pathType: Prefix backend: service: name: whoami port: number: 80 ``` 배포되면 ACM용 ACK 서비스 컨트롤러는 갱신을 포함하여 인증서 수명 주기를 자동으로 관리합니다. ACM이 인증서를 갱신하면 컨트롤러는 `exported-cert-secret` 보안 암호를 새 인증서로 업데이트하여 수신이 수동 개입 없이 유효한 인증서를 계속 사용하도록 합니다. # AWS Certificate Manager 퍼블릭 인증서 취소 ACM 콘솔 AWS CLI또는 API 작업을 사용하여 AWS Certificate Manager 내보낼 수 있는 퍼블릭 인증서를 취소할 수 있습니다. **주의** 인증서가 취소된 후에는 인증서를 재사용할 수 없습니다. 인증서 취소는 영구적입니다. 조직의 정책을 준수하거나 키 손상을 완화하기 위해 인증서를 취소해야 할 수 있습니다. 인증서를 취소하려면 사유가 필요합니다. 다음과 같은 사유를 사용할 수 있습니다. + 지정 안 함 + 소속 변경 + 대체됨 + 작업 중단 자세한 내용은 [Amazon Trust Services Certificate Subscriber Agreement](https://www.amazontrust.com/repository/sa-1.3.pdf) 및 [Amazon Trust Service](https://www.amazontrust.com/repository/)를 참조하세요. AWS 는 인증서 취소를 확인하기 위한 두 가지 서비스인 온라인 인증서 상태 프로토콜(OCSP)과 인증서 취소 목록을 제공합니다. OCSP를 사용하면 클라이언트가 상태를 실시간으로 반환하는 신뢰할 수 있는 해지 데이터베이스를 쿼리합니다. OCSP는 모두 인증서에 포함된 검증 정보를 기반으로 합니다. ## 고려 사항 다음은 인증서를 취소하기 전에 고려해야 할 사항입니다. + 이전에 내보낸 인증서만 취소할 수 있습니다. + [내보낼 수 없는 퍼블릭 인증서는](acm-exportable-certificates.md) 취소할 수 없습니다. 이러한 인증서가 더 이상 필요하지 않은 경우, 대신 [삭제](gs-acm-delete.md)해야 합니다. + 더 이상 인증서가 필요하지 않은 경우 인증서를 취소하는 대신 인증서를 [삭제](gs-acm-delete.md)해야 합니다. + 인증서 취소 프로세스는 전역적입니다. 취소하기로 선택한 모든 유효한 인증서는 연결된 ARN과 함께 취소됩니다. + 인증서 취소는 영구적입니다. 취소된 인증서는 재사용할 수 없습니다. + 인증서 취소가 적용되려면 최대 24시간이 걸릴 수 있습니다. ## 인증서 취소(콘솔) 다음 절차에서는 ACM 퍼블릭 또는 프라이빗 인증서를 취소하는 방법을 안내합니다. 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/acm/](https://console.aws.amazon.com/acm/) ACM 콘솔을 엽니다. 1. **인증서 나열**을 선택하고 취소할 인증서의 확인란을 선택합니다. 1. 또는 인증서를 선택할 수 있습니다. 인증서 세부 정보 페이지에서 **취소**를 선택합니다. 1. **추가 작업**을 선택한 다음 **취소**를 선택합니다. 1. 대화 상자가 나타나면 취소 사유를 제공하고 **revoke**를 입력한 다음 **취소**를 선택해야 합니다. ## 인증서 취소(AWS CLI) [https://docs.aws.amazon.com//cli/latest/reference/acm-pca/revoke-certificate.html](https://docs.aws.amazon.com//cli/latest/reference/acm-pca/revoke-certificate.html) AWS CLI 명령 또는 [https://docs.aws.amazon.com/acm/latest/APIReference/API_RevokeCertificate.html](https://docs.aws.amazon.com/acm/latest/APIReference/API_RevokeCertificate.html) API 작업을 사용하여 ACM 퍼블릭 또는 프라이빗 인증서를 취소합니다. [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm/list-certificates.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm/list-certificates.html) 명령을 호출하여 인증서의 ARN을 검색할 수 있습니다. ``` $ aws acm revoke-certificate \ --certificate-arn arn:aws:acm:us-east-1:111122223333:certificate/12345678-1234-1234-1234 \ --revocation-reason "UNSPECIFIED" ``` **주의** 인증서가 취소된 후에는 인증서를 재사용할 수 없습니다. 인증서 취소는 영구적입니다. 다음은 `revoke-certificate` 명령의 출력을 보여줍니다. ``` arn:aws:acm:us-east-1:111122223333:certificate/12345678-1234-1234-1234 ``` # 자동 갱신 이벤트 구성 AWS Certificate Manager 내보내기 가능한 퍼블릭 인증서와 Amazon EventBridge를 사용하여 자동 인증서 갱신 이벤트를 구성할 수 있습니다. 1. 인증서 갱신을 모니터링하도록 Amazon EventBridge 이벤트를 설정합니다. 자세한 내용은 [ACM에 대한 Amazon EventBridge 지원](https://docs.aws.amazon.com//acm/latest/userguide/cloudwatch-events.html)을 참조하세요. 1. 갱신 시 인증서 배포를 처리하는 자동화를 생성합니다. 자세한 내용은 [ACM에서 Amazon EventBridge를 사용하여 작업 시작](example-actions.md) 단원을 참조하십시오. 1. 갱신 또는 배포 실패를 알리도록 EventBridge 이벤트를 구성합니다. # 인증서 강제 갱신 ACM 콘솔, 갱신 인증서 또는 [https://docs.aws.amazon.com/acm/latest/APIReference/API_RenewCertificate.html](https://docs.aws.amazon.com/acm/latest/APIReference/API_RenewCertificate.html) API 작업을 사용하여 ACM 퍼블릭 및 프라이빗 인증서를 [갱신](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm/renew-certificate.html) AWS CLI할 수 있습니다. 이전에 내보낸 인증서만 갱신할 수 있습니다. **중요** ACM 익스포터블 퍼블릭 인증서를 갱신하면 추가 요금이 부과됩니다. 최신 ACM 요금 정보는 AWS 웹 사이트의 [AWS Certificate Manager 서비스 요금](https://aws.amazon.com//certificate-manager/pricing/) 페이지를 참조하세요. ## 인증서 갱신(콘솔) 다음 절차에서는 ACM 퍼블릭 또는 프라이빗 인증서를 강제로 갱신하는 방법을 안내합니다. 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/acm/](https://console.aws.amazon.com/acm/) ACM 콘솔을 엽니다. 1. **인증서 나열**을 선택하고 갱신할 인증서의 확인란을 선택합니다. 1. 또는 인증서를 선택할 수 있습니다. 인증서 세부 정보 페이지에서 **갱신**을 선택합니다. 1. **추가 작업**을 선택한 다음 **갱신**을 선택합니다. 1. 대화 상자가 나타나면 **renew**를 입력한 다음 **갱신**을 선택해야 합니다. ## 인증서를 갱신하려면(AWS CLI) [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm/renew-certificate.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm/renew-certificate.html) AWS CLI 명령 또는 [https://docs.aws.amazon.com/acm/latest/APIReference/API_RenewCertificate.html](https://docs.aws.amazon.com/acm/latest/APIReference/API_RenewCertificate.html) API 작업을 사용하여 ACM 퍼블릭 또는 프라이빗 인증서를 갱신합니다. [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm/list-certificates.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm/list-certificates.html) 명령을 호출하여 인증서의 ARN을 검색할 수 있습니다. `renew-certificate` 명령은 응답을 반환하지 않습니다. ``` $ aws acm renew-certificate \ --certificate-arn arn:aws:acm:us-east-1:111122223333:certificate/12345678-1234-1234-1234-123456789012 ``` # 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) 섹션을 참조하세요.