기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
ACM이 제공하는 퍼블릭 인증서의 특성과 제한 사항은 이 페이지의 설명합니다. 이러한 특성은 ACM에서 제공하는 인증서에만 적용되고, 가져온 인증서에는 적용되지 않습니다.
- 브라우저 및 애플리케이션 신뢰
-
Google Chrome, Microsoft Internet Explorer, Microsoft Edge, Mozilla Firefox, Apple Safari 등 모든 주요 브라우저에서 ACM 인증서를 신뢰합니다. ACM 인증서를 신뢰하는 브라우저에서는 SSL/TLS를 통해 ACM 인증서를 사용하는 사이트에 연결하면 상태 표시줄 또는 주소 표시줄에 자물쇠 아이콘이 표시됩니다. Java에서도 ACM 인증서를 신뢰합니다.
-
ACM을 통해 요청하는 공인 인증서는 아마존 관리형 퍼블릭 인증 기관(CA)인 Amazon Trust Services
에서 받습니다. Amazon Root CA 1~4는 Starfield G2 Root Certificate Authority -G2라는 이전 루트에 의해 상호 서명됩니다. Starfield 루트는 최신 버전의 Gingerbread부터 시작하여 Android 기기에서 신뢰할 수 있으며 버전 4.1부터 iOS에서도 신뢰할 수 있습니다. 버전 11부터 iOS가 Amazon 루트를 신뢰합니다. Amazon 또는 Starfield 루트가 포함된 모든 브라우저, 애플리케이션 또는 OS는 ACM에서 얻은 퍼블릭 인증서를 신뢰합니다. ACM이 고객에게 발행하는 리프 또는 최종 엔티티 인증서는 여러 중간 CA 중 하나를 통해 Amazon Trust Services 루트 CA에서 권한을 도출합니다. ACM은 요청된 인증서 유형(RSA 또는 ECDSA)에 따라 중간 CA를 임의로 할당합니다. 요청이 생성된 후 중간 CA가 무작위로 선택되므로 ACM은 중간 CA 정보를 제공하지 않습니다.
- 도메인 검증(DV)
-
ACM 인증서의 도메인을 검증합니다. 즉, ACM 인증서의 제목 필드는 도메인 이름만 나타냅니다. ACM 인증서를 요청할 때 사용자는 요청을 통해 지정한 모든 도메인에 대해 사용자가 소유하거나 관리 권한을 보유하고 있는지 검증해야 합니다. 이메일 혹은 DNS를 통해 소유권을 검증할 수 있습니다. 자세한 내용은 AWS Certificate Manager 이메일 검증 및 AWS Certificate Manager DNS 검증 단원을 참조하세요.
- 중간 및 루트 CA 순환
-
Amazon은 복원력이 뛰어나고 민첩한 인증서 인프라를 유지하기 위해 언제든지 사전 통지 없이 중간 CA를 중단하도록 선택할 수 있습니다. 이러한 종류의 변경은 고객에게 영향을 미치지 않습니다. 자세한 내용은 블로그 게시물 "Amazon introduces dynamic intermediate certificate authorities
"(Amazon, 동적 중간 인증 기관 도입)를 참조하세요. 드문 경우이긴 하지만 Amazon에서 루트 CA를 중단하는 경우 상황에 따라 즉시 변경이 발생할 것입니다. 이러한 변경의 영향이 크므로 Amazon은 AWS Health Dashboard, 계정 소유자에게 보내는 이메일, 기술 계정 관리자에 대한 지원 등 사용 가능한 모든 메커니즘을 사용하여 AWS 고객에게 알립니다.
- 해지를 위한 방화벽 액세스
-
최종 엔티티 인증서를 더 이상 신뢰할 수 없는 경우 해당 인증서가 해지됩니다. OCSP 및 CRL은 인증서가 해지되었는지 여부를 확인하는 데 사용되는 표준 메커니즘입니다. OCSP 및 CRL은 해지 정보를 게시하는 데 사용되는 표준 메커니즘입니다. 이러한 메커니즘이 작동하도록 하기 위해 일부 고객 방화벽에는 추가 규칙이 필요할 수 있습니다.
다음 예제 URL 와일드카드 패턴을 사용하여 해지 트래픽을 식별할 수 있습니다. 별표(*) 와일드카드는 하나 이상의 영숫자 문자에 해당하고, 물음표(?)는 단일 영숫자를 나타내고, 해시 마크(#)는 숫자를 나타냅니다.
-
OCSP
http://ocsp.?????.amazontrust.com
http://ocsp.*.amazontrust.com
-
CRL
http://crl.?????.amazontrust.com/?????.crl
http://crl.*.amazontrust.com/*.crl
-
- 키 알고리즘
-
인증서는 반드시 알고리즘과 키 크기를 지정해야 합니다. 현재 다음 RSA 및 ECDSA(Elliptic Curve Digital Signature Algorithm) 퍼블릭 키 알고리즘이 ACM에서 지원됩니다. ACM에서는 별표(*)로 표시된 알고리즘을 사용하여 새 인증서 발급을 요청할 수 있습니다. 나머지 알고리즘은 가져온 인증서에 대해서만 지원됩니다.
참고
CA에서 서명한 프라이빗 PKI 인증서를 AWS Private CA에서 요청하는 경우 지정된 서명 알고리즘 계열(RSA 또는 ECDSA)은 CA의 보안 키의 알고리즘 계열과 일치해야 합니다.
-
RSA 1024비트(
RSA_1024
) -
RSA 2048비트(
RSA_2048
)* -
RSA 3072비트(
RSA_3072
) -
RSA 4096비트(
RSA_4096
) -
ECDSA 256비트(
EC_prime256v1
)* -
ECDSA 384비트(
EC_secp384r1
)* -
ECDSA 521비트(
EC_secp521r1
)
ECDSA 키는 크기가 더 작기 때문에 RSA 키와 유사한 수준의 보안을 제공하면서도 컴퓨팅 효율성은 더 뛰어납니다. 그러나 ECDSA가 일부 네트워크 클라이언트에서 지원되지 않습니다. NIST
에서 채택한 다음 표에서는 다양한 크기의 키를 사용하는 RSA 및 ECDSA의 대표적인 보안 강도를 확인할 수 있습니다. 모든 값에 대한 단위는 비트입니다. 알고리즘과 키의 보안 비교 보안 강도
RSA 키 크기
ECDSA 키 크기
128
3072 256 192
7680 384 256
15360 521 2의 거듭제곱으로 이해되는 보안 강도는 암호화를 해제하는 데 필요한 추측의 수와 연관되어 있습니다. 예를 들어 3072비트 RSA 키와 256비트 ECDSA 키는 모두 2128회 이하의 추측으로 검색이 가능합니다.
알고리즘을 선택하는 데 도움이 되는 정보는 AWS 블로그 게시물 AWS Certificate Manager에서 ECDSA 인증서를 평가하고 사용하는 방법
을 참조하세요. 중요
통합 서비스에서는 리소스와의 연결이 지원되는 알고리즘과 키 크기만 허용합니다. 뿐만 아니라, 이러한 지원은 인증서를 IAM으로 가져올지 ACM으로 가져올지 여부에 따라 달라집니다. 자세한 내용은 각 서비스에 대한 문서를 참조하십시오.
-
Elastic Load Balancing의 경우 Application Load Balancer를 위한 HTTPS 리스너를 참조하세요.
-
CloudFront의 경우 지원되는 SSL/TLS 프로토콜 및 암호를 참조하세요.
-
- 관리형 갱신 및 배포
-
ACM은 ACM 인증서 갱신 프로세스와 갱신 후 인증서 프로비저닝 프로세스를 관리합니다. 자동 갱신을 사용하면 잘못된 구성, 취소 또는 만료된 인증서로 인한 가동 중지를 방지할 수 있습니다. 자세한 내용은 AWS Certificate Manager에서 관리형 인증서 갱신 단원을 참조하십시오.
- 여러 도메인 이름
-
각 ACM 인증서에는 하나 이상의 Fully Qualified Domain Name(FQDN)이 포함되어 있으며 원한다면 이름을 추가할 수 있습니다. 예를 들어 고객이
www.example.net
이라는 이름으로도 사이트에 연결하는 경우,www.example.com
에 대한 ACM 인증서를 만들 때 그 이름도 추가할 수 있습니다. 이는 베어 도메인(zone apex 또는 naked 도메인이라고도 함)의 경우데 마찬가지입니다. 즉, www.example.com에 대한 ACM 인증서를 요청하고 example.com이라는 이름을 추가할 수 있습니다. 자세한 내용은 AWS Certificate Manager 퍼블릭 인증서 단원을 참조하십시오. - Punycode
-
다국어 도메인 이름
과 관련된 다음 Punycode 요구 사항을 충족해야 합니다. -
‘<character><character>--’ 패턴으로 시작하는 도메인 이름은 ‘xn--’과 일치해야 합니다.
-
‘xn--’으로 시작하는 도메인 이름도 유효한 다국어 도메인 이름이어야 합니다.
Punycode 예제 도메인 이름
#1 충족
#2 충족
허용
참고
example.com
해당 사항 없음
해당 사항 없음
✓
‘<character><character>--’로 시작하지 않음
a--example.com
해당 사항 없음
해당 사항 없음
✓
‘<character><character>--’로 시작하지 않음
abc--example.com
해당 사항 없음
해당 사항 없음
✓
‘<character><character>--’로 시작하지 않음
xn—xyz.com
예
예
✓
유효한 다국어 도메인 이름(简.com으로 확인)
xn--example.com
예
아니요
✗
유효한 다국어 도메인 이름이 아님
ab--example.com
아니요
아니요
✗
‘xn--’으로 시작해야 함
-
- 유효 기간
-
ACM 인증서의 유효 기간은 현재 13개월(395일)입니다.
- 와일드카드 이름
-
ACM을 사용하면 도메인 이름에 별표(*)를 사용하여 동일한 도메인에서 여러 사이트를 보호할 수 있는 와일드카드 이름을 포함하는 ACM 인증서를 생성할 수 있습니다. 예를 들어
*.example.com
은www.example.com
및images.example.com
을 보호합니다.참고
와일드카드 인증서를 요청할 때 별표(
*
)는 도메인 이름의 맨 왼쪽에 와야 하며 하나의 하위 도메인 수준만 보호할 수 있습니다. 예를 들어*.example.com
은login.example.com
및test.example.com
을 보호할 수 있지만test.login.example.com
은 보호할 수 없습니다. 또한*.example.com
은example.com
의 하위 도메인만 보호하고 베어 또는 apex 도메인(example.com
)은 보호하지 못합니다. 하지만 요청에서 여러 도메인 이름을 지정하여 베어 또는 apex 도메인과 하위 도메인을 보호하는 인증서를 요청할 수 있습니다. 예를 들어example.com
및*.example.com
을 보호하는 인증서를 요청할 수 있습니다.
제한 사항
퍼블릭 인증서에는 다음 제한 사항이 적용됩니다.
-
ACM은 확장 확인(EV) 인증서 또는 조직 확인(OV) 인증서를 제공하지 않습니다.
-
ACM은 SSL/TLS 이외의 프로토콜에 대한 인증서를 제공하지 않습니다.
-
이메일 암호화에 ACM 인증서를 사용할 수 없습니다.
-
ACM은 현재 ACM 인증서에 대한 관리형 인증서 갱신 옵트아웃을 허용하지 않습니다. 또한 ACM으로 가져오는 인증서에 대해서는 관리형 갱신을 사용할 수 없습니다.
-
amazonaws.com, cloudfront.net 또는 elasticbeanstalk.com으로 끝나는 이름과 같이 Amazon 소유 도메인 이름에 대한 인증서를 요청할 수 없습니다.
-
ACM 인증서에 대한 프라이빗 키를 다운로드할 수 없습니다.
-
Amazon Elastic Compute Cloud(Amazon EC2) 웹 사이트 또는 애플리케이션에는 ACM 인증서를 직접 설치할 수 없습니다. 그러나 통합서비스 중 어떠한 것을 사용하든지 인증서를 설치할 수 있습니다. 자세한 내용은 ACM에 통합된 서비스 단원을 참조하십시오.
옵트아웃을 선택하지 않는 한 공개적으로 신뢰할 수 있는 ACM 인증서는 최소 2개의 인증서 투명성 데이터베이스에 자동으로 기록됩니다. 현재는 콘솔을 사용하여 옵트아웃할 수 없습니다. AWS CLI 또는 ACM API를 사용해야 합니다. 자세한 내용은 인증서 투명성 로깅 옵트아웃 단원을 참조하십시오. 투명성 로그에 대한 일반적인 정보는 인증서 투명성 로깅 단원을 참조하세요.