

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# AWS Private CA 인증서 해지 방법 계획
<a name="revocation-setup"></a>

를 사용하여 프라이빗 PKI를 계획 AWS Private CA할 때는 엔드포인트의 프라이빗 키가 노출되는 경우와 같이 엔드포인트가 더 이상 발급된 인증서를 신뢰하지 않도록 하는 상황을 처리하는 방법을 고려해야 합니다. 이 문제에 대한 일반적인 접근 방식은 단기 인증서를 사용하거나 인증서 취소를 구성하는 것입니다. 단기 인증서는 몇 시간 또는 며칠 단위로 만료되므로 해지하는 것은 의미가 없으며, 엔드포인트에 해지를 알리는 데 걸리는 시간과 거의 같은 시간이 지나면 인증서가 유효하지 않게 됩니다. 이 섹션에서는 구성 및 모범 사례를 포함하여 AWS Private CA 고객을 위한 해지 옵션에 대해 설명합니다.

해지 방법을 찾는 고객은 온라인 인증서 상태 프로토콜(OCSP), 인증서 취소 목록(CRL) 또는 둘 다를 선택할 수 있습니다.

**참고**  
해지를 구성하지 않고 CA를 생성하는 경우 언제든지 나중에 구성할 수 있습니다. 자세한 내용은 [에서 프라이빗 CA 업데이트 AWS Private Certificate Authority](PCAUpdateCA.md) 단원을 참조하십시오.
+ **온라인 인증서 상태 프로토콜(OCSP)**

  AWS Private CA 는 고객이 인프라를 직접 운영할 필요 없이 인증서가 취소되었음을 엔드포인트에 알리는 완전 관리형 OCSP 솔루션을 제공합니다. 고객은 AWS Private CA 콘솔, API, CLI 또는를 통해 단일 작업으로 신규 또는 기존 CAs에서 OCSP를 활성화할 수 있습니다 CloudFormation. CRL은 엔드포인트에서 저장 및 처리되며 무효화될 수 있지만 OCSP 스토리지 및 처리 요구 사항은 응답자 백엔드에서 동기적으로 처리됩니다.

  CA에 대해 OCSP를 활성화하면는 발급된 각 새 인증서의 *권한 정보 액세스*(AIA) 확장에 OCSP 응답기의 URL을 AWS Private CA 포함합니다. 확장을 사용하면 웹 브라우저와 같은 클라이언트가 응답자를 쿼리하고 최종 엔터티 또는 하위 CA 인증서를 신뢰할 수 있는지 여부를 확인할 수 있습니다. 응답자는 신뢰성을 보장하기 위해 암호로 서명된 상태 메시지를 반환합니다.

   AWS Private CA OCSP 응답기는 [RFC 5019](https://datatracker.ietf.org/doc/html/rfc5019)를 준수합니다.

  **OCSP 고려 사항**
  + OCSP 상태 메시지는 발급 CA가 사용하도록 구성된 것과 동일한 서명 알고리즘을 사용하여 서명됩니다. AWS Private CA 콘솔에서 만든 CA는 기본적으로 SHA256WITHRSA 서명 알고리즘을 사용합니다. 지원되는 다른 알고리즘은 [인증 기관](https://docs.aws.amazon.com/privateca/latest/APIReference/API_CertificateAuthorityConfiguration.html) 구성 API 설명서에서 찾을 수 있습니다.
  + OCSP 응답자가 활성화된 경우 [APIPassthrough 및 CSRPassthrough](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html#template-varieties) 인증서 템플릿은 AIA 확장과 함께 작동하지 않습니다.
  + 관리형 OCSP 서비스의 엔드포인트는 공용 인터넷에서 액세스할 수 있습니다. OCSP를 원하지만 퍼블릭 엔드포인트는 원하지 않는 고객은 자체 OCSP 인프라를 운영해야 합니다.
+ **인증서 해지 목록(CRL)**

  인증서 해지 목록(CRL)은 예정된 만료 날짜 이전에 취소된 인증서 목록이 포함된 파일입니다. CRL에는 더 이상 신뢰할 수 없어야 하는 인증서 목록, 해지 이유 및 기타 관련 정보가 포함되어 있습니다.

  인증 기관(CA)을 구성할 때가 전체 또는 분할된 CRL을 AWS Private CA 생성할지 여부를 선택할 수 있습니다. 선택한 항목에 따라 인증 기관에서 발급하고 취소할 수 있는 최대 인증서 수가 결정됩니다. 자세한 내용은 [AWS Private CA 할당량](https://docs.aws.amazon.com/general/latest/gr/pca.html#limits_pca)을 참조하세요.

   **CRL 고려 사항** 
  + 메모리 및 대역폭 고려 사항: 로컬 다운로드 및 처리 요구 사항으로 인해 CRLs OCSP보다 더 많은 메모리가 필요합니다. 그러나 CRLs 연결당 상태를 확인하는 대신 취소 목록을 캐싱하여 OCSP에 비해 네트워크 대역폭을 줄일 수 있습니다. 특정 IoT 디바이스와 같이 메모리가 제한된 디바이스의 경우 분할된 CRLs을 사용하는 것이 좋습니다.
  + CRL 유형 변경: 완료에서 분할된 CRL로 변경할 때 필요에 따라 새 파티션을 AWS Private CA 생성하고 원본을 포함한 모든 CRLs에 IDP 확장을 추가합니다. 파티셔닝됨에서 완료로 변경하면 단일 CRL만 업데이트되고 향후 이전 파티션과 연결된 인증서가 취소되는 것을 방지할 수 있습니다.

**참고**  
OCSP와 CRL 모두 취소와 상태 변경 가능 시점 사이에 약간의 지연이 있습니다.  
인증서를 해지할 때 OCSP 응답에 새 상태가 반영되기까지 최대 60분이 걸릴 수 있습니다. 일반적으로 OCSP는 해지 정보의 빠른 배포를 지원하는 경향이 있는데, 이는 클라이언트가 며칠 동안 캐시할 수 있는 CRL과 달리 OCSP 응답은 일반적으로 클라이언트에 의해 캐시되지 않기 때문입니다.
CRL은 일반적으로 인증서가 해지된 후 약 30분 후에 업데이트됩니다. 어떤 이유로든 CRL 업데이트가 실패하면 AWS Private CA 는 15분마다 추가로 시도합니다.

## 해지 구성에 대한 일반 요구 사항
<a name="revocation-requirements"></a>

모든 해지 구성에는 다음 요구 사항이 적용됩니다.
+ CRL 또는 OCSP를 비활성화하는 구성은 `Enabled=False` 파라미터만 포함해야 하며 `CustomCname` 또는 `ExpirationInDays` 등의 다른 파라미터가 포함된 경우 실패합니다.
+ CRL 구성에서 `S3BucketName` 파라미터는 [Amazon Simple Storage Service 버킷 명명 규칙](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html)을 준수해야 합니다.
+ CRL 또는 OCSP에 대한 사용자 지정 표준 이름(CNAME) 파라미터가 포함된 구성은 CNAME에 특수 문자 사용에 대한 [RFC7230](https://www.ietf.org/rfc/rfc7230.txt) 제한을 준수해야 합니다.
+ CRL 또는 OCSP 구성에서 CNAME 파라미터 값에 'http://' 또는 'https://' 등의 프로토콜 접두사가 포함되지 않아야 합니다.

**Topics**
+ [해지 구성에 대한 일반 요구 사항](#revocation-requirements)
+ [에 대한 CRL 설정 AWS Private CA](crl-planning.md)
+ [에 대한 OCSP URL 사용자 지정 AWS Private CA](ocsp-customize.md)

# 에 대한 CRL 설정 AWS Private CA
<a name="crl-planning"></a>

[CA 생성 프로세스의](create-CA.md) 일부로 인증서 해지 목록(CRL)을 구성하려면 먼저 몇 가지 사전 설정이 필요할 수 있습니다. 이 섹션에서는 CRL이 연결된 CA를 만들기 전에 이해해야 하는 사전 요구 사항 및 옵션에 대해 설명합니다.

온라인 인증서 상태 프로토콜(OCSP)을 CRL의 대안 또는 보완으로 사용하는 방법에 대한 자세한 내용은 [](create-CA.md#PcaCreateRevocation) 및 [에 대한 OCSP URL 사용자 지정 AWS Private CA](ocsp-customize.md)을 참조하세요.

**Topics**
+ [CRL 유형](#crl-type)
+ [CRL 구조](#crl-structure)
+ [Amazon S3의 CRL에 대한 액세스 정책](#s3-policies)
+ [CloudFront를 사용하여 S3 퍼블릭 액세스 차단(BPA) 활성화](#s3-bpa)
+ [CRL 배포 지점(CDP) URI 확인](#crl-url)
+ [](#crl-ipv6)

## CRL 유형
<a name="crl-type"></a>
+  **완료** - 기본 설정입니다.는 CA에서 발급하고 취소된 만료되지 않은 모든 인증서에 대해 분할되지 않은 단일 CRL 파일을 AWS Private CA 유지합니다. AWS Private CA 발급하는 각 인증서는 [ RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9)에 정의된 대로 CRL 배포 지점(CDP) 확장을 통해 특정 CRL에 바인딩됩니다. 전체 CRL이 활성화된 각 CA에 대해 최대 1백만 개의 프라이빗 인증서를 보유할 수 있습니다. 자세한 내용은 [AWS Private CA 할당량을 참조하세요](https://docs.aws.amazon.com/general/latest/gr/pca.html#limits_pca).
+  **파티셔닝됨** - 전체 CRLs에 비해 파티셔닝된 CRLs 프라이빗 CA가 발급할 수 있는 인증서 수를 크게 늘리고 CAs를 자주 교체하지 않아도 됩니다.
**중요**  
분할된 CRLs 사용하는 경우 CRL의 관련 발급 배포 지점(IDP) URI가 인증서의 CDP URI와 일치하는지 확인하여 올바른 CRL을 가져왔는지 확인해야 합니다.는 IDP 확장을 중요한 것으로 AWS Private CA 표시하며, 클라이언트가 이를 처리할 수 있어야 합니다.

## CRL 구조
<a name="crl-structure"></a>

각 CRL은 DER로 인코딩된 파일입니다. 파일을 다운로드하고 [OpenSSL](https://www.openssl.org/)을 사용해 파일을 보려면 다음과 같은 명령을 사용하십시오.

```
openssl crl -inform DER -in path-to-crl-file -text -noout
```

CRL은 다음 형식을 사용합니다.

```
Certificate Revocation List (CRL):
		        Version 2 (0x1)
		    Signature Algorithm: sha256WithRSAEncryption
		        Issuer: /C=US/ST=WA/L=Seattle/O=Example Company CA/OU=Corporate/CN=www.example.com
		        Last Update: Feb 26 19:28:25 2018 GMT
		        Next Update: Feb 26 20:28:25 2019 GMT
		        CRL extensions:
		            X509v3 Authority Key Identifier:
		                keyid:AA:6E:C1:8A:EC:2F:8F:21:BC:BE:80:3D:C5:65:93:79:99:E7:71:65
		
		            X509v3 CRL Number:
		                1519676905984
		Revoked Certificates:
		    Serial Number: E8CBD2BEDB122329F97706BCFEC990F8
		        Revocation Date: Feb 26 20:00:36 2018 GMT
		        CRL entry extensions:
		            X509v3 CRL Reason Code:
		                Key Compromise
		    Serial Number: F7D7A3FD88B82C6776483467BBF0B38C
		        Revocation Date: Jan 30 21:21:31 2018 GMT
		        CRL entry extensions:
		            X509v3 CRL Reason Code:
		                Key Compromise
		    Signature Algorithm: sha256WithRSAEncryption
		         82:9a:40:76:86:a5:f5:4e:1e:43:e2:ea:83:ac:89:07:49:bf:
		         c2:fd:45:7d:15:d0:76:fe:64:ce:7b:3d:bb:4c:a0:6c:4b:4f:
		         9e:1d:27:f8:69:5e:d1:93:5b:95:da:78:50:6d:a8:59:bb:6f:
		         49:9b:04:fa:38:f2:fc:4c:0d:97:ac:02:51:26:7d:3e:fe:a6:
		         c6:83:34:b4:84:0b:5d:b1:c4:25:2f:66:0a:2e:30:f6:52:88:
		         e8:d2:05:78:84:09:01:e8:9d:c2:9e:b5:83:bd:8a:3a:e4:94:
		         62:ed:92:e0:be:ea:d2:59:5b:c7:c3:61:35:dc:a9:98:9d:80:
		         1c:2a:f7:23:9b:fe:ad:6f:16:7e:22:09:9a:79:8f:44:69:89:
		         2a:78:ae:92:a4:32:46:8d:76:ee:68:25:63:5c:bd:41:a5:5a:
		         57:18:d7:71:35:85:5c:cd:20:28:c6:d5:59:88:47:c9:36:44:
		         53:55:28:4d:6b:f8:6a:00:eb:b4:62:de:15:56:c8:9c:45:d7:
		         83:83:07:21:84:b4:eb:0b:23:f2:61:dd:95:03:02:df:0d:0f:
		         97:32:e0:9d:38:de:7c:15:e4:36:66:7a:18:da:ce:a3:34:94:
		         58:a6:5d:5c:04:90:35:f1:8b:55:a9:3c:dd:72:a2:d7:5f:73:
		         5a:2c:88:85
```

**참고**  
CRL은 해당 인증서를 참조하는 인증서가 발급된 후 Amazon S3에 배치됩니다. 그 전에는 Amazon S3 버킷에 `acm-pca-permission-test-key` 파일만 표시됩니다.

## Amazon S3의 CRL에 대한 액세스 정책
<a name="s3-policies"></a>

CRL을 생성하려는 경우에 저장할 Amazon S3 버킷을 준비해야 합니다.는 지정한 Amazon S3 버킷에 CRL을 AWS Private CA 자동으로 저장하고 주기적으로 업데이트합니다. 자세한 내용은 [버킷 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket.html) 섹션을 참조하세요.

S3 버킷은 첨부된 IAM 권한 정책으로 보호되어야 합니다. 권한 있는 사용자 및 서비스 보안 주체는가 버킷에 객체를 배치할 수 AWS Private CA 있는 `Put` 권한과 객체를 검색할 수 있는 `Get` 권한이 필요합니다.

**참고**  
IAM 정책 구성은 AWS 리전 관련에 따라 달라집니다. 리전은 다음 두 가지 범주로 나뉩니다.  
**기본 지원 리전 -** 모든에 대해 기본적으로 *활성화된* 리전입니다 AWS 계정.
**기본 비활성화 리전** - 기본적으로 *비활성화*되지만 고객이 수동으로 활성화할 수 있는 리전입니다.
자세한 내용과 기본 비활성화 리전 목록은 [AWS 리전관리](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html)를 참조하세요. IAM과 관련된 서비스 보안 주체에 대한 설명은 [옵트인 리전의AWS 서비스 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-services-in-opt-in-regions)를 참조하세요.  
CRL을 인증서 취소 방법으로 구성하면 AWS Private CA 는 CRL을 생성하여 S3 버킷에 게시합니다. S3 버킷에는 AWS Private CA 서비스 보안 주체가 버킷에 쓸 수 있도록 허용하는 IAM 정책이 필요합니다. 서비스 보안 주체의 이름은 사용하는 리전에 따라 다르며 모든 가능성이 지원되는 것은 아닙니다.  


****  

| PCA | S3 | 서비스 보안 주체 | 
| --- | --- | --- | 
|  둘 다 같은 리전에 있습니다.  |  `acm-pca.amazonaws.com`  | 
|  활성화됨  |  활성화됨  |  `acm-pca.amazonaws.com`  | 
| 비활성 | 활성화됨 |  `acm-pca.Region.amazonaws.com`  | 
| 활성화됨 | 비활성화됨 |  지원되지 않음  | 

기본 정책은 CA에 `SourceArn` 제한을 적용하지 않습니다. 특정 AWS 계정과 특정 프라이빗 CA 모두에 대한 액세스를 제한하는 다음과 같은 덜 허용적인 정책을 적용하는 것이 좋습니다. 또는 [aws:SourceOrgID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgid) 조건 키를 사용하여의 특정 조직에 대한 액세스를 제한할 수 있습니다 AWS Organizations. 버킷 정책에 대한 자세한 내용은 [Amazon Simple Storage Service의 버킷 정책을](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) 참조하세요.

기본 정책을 허용하도록 선택한 경우 나중에 언제든지 [수정](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html)할 수 있습니다.

## CloudFront를 사용하여 S3 퍼블릭 액세스 차단(BPA) 활성화
<a name="s3-bpa"></a>

새 Amazon S3 버킷은 기본적으로 퍼블릭 액세스 차단(BPA) 기능이 활성화된 상태로 구성됩니다. Amazon S3 [보안 모범 사례](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html)에 포함된 BPA는 고객이 S3 버킷의 객체 및 전체 버킷에 대한 액세스를 세밀하게 조정하는 데 사용할 수 있는 액세스 제어 세트입니다. BPA가 활성 상태이고 올바르게 구성된 경우 승인되고 인증된 AWS 사용자만 버킷과 해당 콘텐츠에 액세스할 수 있습니다.

AWS 에서는 잠재적 공격자에게 민감한 정보가 노출되지 않도록 모든 S3 버킷에서 BPA를 사용할 것을 권장합니다. 그러나 PKI 클라이언트가 퍼블릭 인터넷을 통해(즉, AWS 계정에 로그인하지 않은 상태에서) CRLs을 검색하는 경우 추가 계획이 필요합니다. 이 섹션에서는 콘텐츠 전송 네트워크(CDN)인 Amazon CloudFront를 사용하여 S3 버킷에 대한 인증된 클라이언트 액세스를 요구하지 않고 CRL을 제공하도록 프라이빗 PKI 솔루션을 구성하는 방법을 설명합니다.

**참고**  
CloudFront를 사용하면 AWS 계정에 추가 비용이 발생합니다. 자세한 내용은 [Amazon CloudFront 요금](https://aws.amazon.com/cloudfront/pricing/)을 참조하세요.  
BPA가 활성화된 S3 버킷에 CRL을 저장하기로 선택하고 CloudFront를 사용하지 않는 경우, PKI 클라이언트가 CRL에 액세스할 수 있도록 다른 CDN 솔루션을 구축해야 합니다.

### BPA에 대한 CloudFront 설정
<a name="set-up-cloudfront"></a>

프라이빗 S3 버킷에 액세스할 수 있고 인증되지 않은 클라이언트에게 CRL을 제공할 수 있는 CloudFront 배포를 생성합니다.

**CRL에 대한 CloudFront 배포를 구성하는 방법**

1. *Amazon CloudFront 개발자 안내서*의 [배포 생성](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-creating-console.html)에 나와 있는 절차를 사용하여 새 CloudFront 배포를 생성합니다.

   절차를 완료하는 동안 다음 설정을 적용합니다.
   + **원본 도메인 이름**에서 S3 버킷을 선택합니다.
   + **버킷 액세스 제한**에서 **예**를 선택합니다.
   + **원본 액세스 ID**에 대한 **새 ID 생성**을 선택합니다.
   + **버킷에 대한 읽기 권한 부여**에서 **예, 버킷 정책 업데이트**를 선택합니다.
**참고**  
이 절차에서 CloudFront는 버킷 객체에 액세스할 수 있도록 버킷 정책을 수정합니다. `crl` 폴더 아래의 객체에만 액세스할 수 있도록 이 정책을 [편집](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html)해 보세요.

1. 배포가 초기화되면 CloudFront 콘솔에서 해당 도메인 이름을 찾아 다음 절차를 위해 저장합니다.
**참고**  
us-east-1이 아닌 리전에서 S3 버킷을 새로 생성한 경우 CloudFront를 통해 게시된 애플리케이션에 액세스할 때 HTTP 307 임시 리디렉션 오류가 발생할 수 있습니다. 버킷 주소가 전파되는 데 몇 시간이 걸릴 수 있습니다.

### CA에서 BPA을 설정합니다.
<a name="set-up-CA"></a>

새 CA를 구성하는 동안 CloudFront 배포에 별칭을 포함합니다.

**CloudFront용 CNAME을 사용하여 CA를 구성하는 방법**
+ [에서 프라이빗 CA 생성 AWS Private CA](create-CA.md)를 사용하여 CA를 생성합니다.

  절차를 수행할 때 해지 파일 `revoke_config.txt`에는 비공개 CRL 객체를 지정하고 CloudFront의 배포 엔드포인트에 URL을 제공하는 다음 행이 포함되어야 합니다.

  ```
  "S3ObjectAcl":"BUCKET_OWNER_FULL_CONTROL",
  	"CustomCname":"abcdef012345.cloudfront.net"
  ```

  이후에 이 CA로 인증서를 발급하면 인증서에 다음과 같은 블록이 포함됩니다.

  ```
  X509v3 CRL Distribution Points: 
  	Full Name:
  	URI:http://abcdef012345.cloudfront.net/crl/01234567-89ab-cdef-0123-456789abcdef.crl
  ```

**참고**  
이 CA에서 발급한 이전 인증서가 있는 경우 해당 CA는 CRL에 액세스할 수 없습니다.

## CRL 배포 지점(CDP) URI 확인
<a name="crl-url"></a>

워크플로에서 CRL 배포 지점(CDP) URI를 사용해야 하는 경우 해당 인증서에서 CRL URI를 사용하는 인증서를 발급하거나 다음 방법을 사용할 수 있습니다. 이는 전체 CRLs에서만 작동합니다. 분할된 CRLs 임의 GUID가 추가됩니다.

S3 버킷을 CA의 CRL 배포 지점(CDP)으로 사용하는 경우 CDP URI는 다음 형식 중 하나일 수 있습니다.
+ `http://amzn-s3-demo-bucket.s3.region-code.amazonaws.com/crl/CA-ID.crl`
+ `http://s3.region-code.amazonaws.com/amzn-s3-demo-bucket/crl/CA-ID.crl`

사용자 지정 CNAME으로 CA를 구성한 경우 CDP URI에는 예를 들어 CNAME이 포함됩니다. `http://alternative.example.com/crl/CA-ID.crl` 

## 
<a name="crl-ipv6"></a>

 기본적으로는 리전별 IPv4-only `amazonaws.com` 엔드포인트를 사용하여 CDP 확장을 AWS Private CA 작성합니다. IPv6를 통해 CRLs 사용하려면 다음 단계 중 하나를 수행하여 CDPs가 [S3의 듀얼 스택 엔드포인트](https://docs.aws.amazon.com/AmazonS3/latest/API/dual-stack-endpoints.html)를 가리키는 URLs로 작성되도록 합니다.
+ [CRL 사용자 지정 이름을 ](create-CA.md#PcaCreateRevocation) S3 듀얼 스택 엔드포인트 도메인으로 설정합니다. 예: `bucketname.s3.dualstack.region-code.amazonaws.com`
+ 관련 S3 듀얼 스택 엔드포인트를 가리키는 자체 CNAME DNS 레코드를 설정한 다음 CRL 사용자 지정 이름으로 사용합니다.

# 에 대한 OCSP URL 사용자 지정 AWS Private CA
<a name="ocsp-customize"></a>

**참고**  
이 주제는 브랜딩 또는 기타 목적으로 온라인 인증서 상태 프로토콜(OCSP) 응답자 엔드포인트의 퍼블릭 URL을 사용자 지정하려는 고객을 위한 것입니다. AWS Private CA 관리형 OCSP의 기본 구성을 사용하려는 경우이 주제를 건너뛰고 [취소 구성](create-CA.md#PcaCreateRevocation)의 구성 지침을 따를 수 있습니다.

기본적으로 OCSP를 활성화하면 발급하는 AWS Private CA각 인증서에는 AWS OCSP 응답기의 URL이 포함됩니다. 이렇게 하면 암호로 안전한 연결을 요청하는 클라이언트가 OCSP 유효성 검사 쿼리를 AWS에 직접 보낼 수 있습니다. 하지만 경우에 따라서는 AWS에 대한 OCSP 쿼리를 제출하면서 인증서에 다른 URL을 지정하는 것이 더 나을 수도 있습니다.

**참고**  
OCSP의 대안 또는 보완책으로 CRL (인증서 취소 목록) 을 사용하는 방법에 대한 자세한 내용은 [해지 구성](create-CA.md#PcaCreateRevocation) 및 [인증서 취소 목록(CRL) 계획](crl-planning.md)을 참조하세요.

OCSP의 사용자 지정 URL 구성에는 세 가지 요소가 포함됩니다.
+ **CA 구성** - [에서 프라이빗 CA 생성 AWS Private CA](create-CA.md)의 [예제 2: OCSP와 사용자 지정 CNAME이 활성화된 CA 생성](create-CA.md#example_2)에 설명된 대로 CA에 대한 `RevocationConfiguration`의 사용자 지정 OCSP URL을 지정합니다.
+ **DNS** - 도메인 구성에 CNAME 레코드를 추가하여 인증서에 나타나는 URL을 프록시 서버 URL에 매핑합니다. 자세한 설명은 [에서 프라이빗 CA 생성 AWS Private CA](create-CA.md)에서 [예제 2: OCSP와 사용자 지정 CNAME이 활성화된 CA 생성](create-CA.md#example_2) 섹션을 참조하세요.
+ **전달 프록시 서버** - 수신한 OCSP 트래픽을 AWS OCSP 응답자에게 투명하게 전달할 수 있는 프록시 서버를 설정합니다.

다음 다이어그램은 이러한 요소가 함께 작동하는 방식을 보여줍니다.

![\[사용자 지정 OCSP 토폴로지\]](http://docs.aws.amazon.com/ko_kr/privateca/latest/userguide/images/ocsp.png)


다이어그램에 표시된 대로 사용자 지정된 OCSP 검증 프로세스에는 다음 단계가 포함됩니다.

1. 클라이언트는 대상 도메인의 DNS를 쿼리합니다.

1. 클라이언트는 대상 IP를 수신합니다.

1. 클라이언트는 타겟과 TCP 연결을 엽니다.

1. 클라이언트는 대상 TLS 인증서를 받습니다.

1. 클라이언트는 인증서에 나열된 OCSP 도메인에 대해 DNS를 쿼리합니다.

1. 클라이언트는 프록시 IP를 받습니다.

1. 클라이언트가 OCSP 쿼리를 프록시로 보냅니다.

1. 프록시는 OCSP 응답자에게 쿼리를 전달합니다.

1. 응답자는 인증서 상태를 프록시에 반환합니다.

1. 프록시는 인증서 상태를 클라이언트에 전달합니다.

1. 인증서가 유효하면 클라이언트가 TLS 핸드셰이크를 시작합니다.

**작은 정보**  
이 예제는 위에서 설명한 대로 CA를 구성한 후 [Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/)와 [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/)을 사용하여 구현할 수 있습니다.  
CloudFront에서 배포를 생성하고 다음과 같이 구성합니다.  
사용자 지정 CNAME과 일치하는 대체 이름을 생성합니다.
인증서를 여기에 바인딩합니다.
를 오리진`ocsp.acm-pca.<region>.amazonaws.com`으로 설정합니다.  
IPv6 연결을 사용하려면 듀얼 스택 엔드포인트를 사용합니다. `acm-pca-ocsp.<region>.api.aws` 
`Managed-CachingDisabled` 정책을 배포합니다.
**뷰어 프로토콜 정책**을 **HTTP 및 HTTPS**로 설정합니다.
**허용된 HTTP 방법**을 **GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE**로 설정합니다.
Route 53에서 사용자 지정 CNAME을 CloudFront 배포의 URL에 매핑하는 DNS 레코드를 생성합니다.

## IPv6를 통한 OCSP 사용
<a name="ocsp-ipv6"></a>

 기본 AWS Private CA OCSP 응답기 URL은 IPv4-only입니다. IPv6를 통해 OCSP를 사용하려면 CA에 대한 사용자 지정 OCSP URL을 구성합니다. URL은 다음 중 하나일 수 있습니다.
+ 형식을 취하는 듀얼 스택 PCA OCSP 응답자의 FQDN `acm-pca-ocsp.region-name.api.aws`
+ 위에서 설명한 대로 듀얼 스택 OCSP 응답기를 가리키도록 구성한 CNAME 레코드입니다.