Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Rencanakan metode pencabutan AWS Private CA sertifikat Anda
Saat Anda merencanakan PKI pribadi Anda AWS Private CA, Anda harus mempertimbangkan cara menangani situasi di mana Anda tidak lagi ingin titik akhir mempercayai sertifikat yang dikeluarkan, seperti ketika kunci pribadi dari titik akhir diekspos. Pendekatan umum untuk masalah ini adalah dengan menggunakan sertifikat berumur pendek atau untuk mengkonfigurasi pencabutan sertifikat. Sertifikat berumur pendek kedaluwarsa dalam waktu yang singkat, dalam jam atau hari, pencabutan itu tidak masuk akal, dengan sertifikat menjadi tidak valid dalam waktu yang hampir bersamaan yang diperlukan untuk memberi tahu titik akhir pencabutan. Bagian ini menjelaskan opsi pencabutan untuk AWS Private CA pelanggan, termasuk konfigurasi dan praktik terbaik.
Pelanggan yang mencari metode pencabutan dapat memilih Online Certificate Status Protocol (OCSP), daftar pencabutan sertifikat (CRLs), atau keduanya.
**catatan**
Jika Anda membuat CA tanpa mengonfigurasi pencabutan, Anda selalu dapat mengonfigurasinya nanti. Untuk informasi selengkapnya, lihat [Perbarui CA pribadi di AWS Private Certificate Authority](PCAUpdateCA.md).
+ **Protokol Status Sertifikat Online (OCSP)**
AWS Private CA menyediakan solusi OCSP yang dikelola sepenuhnya untuk memberi tahu titik akhir bahwa sertifikat telah dicabut tanpa perlu pelanggan mengoperasikan infrastruktur sendiri. Pelanggan dapat mengaktifkan OCSP pada yang baru atau yang sudah ada CAs dengan satu operasi menggunakan AWS Private CA konsol, API, CLI, atau melalui. CloudFormation Sedangkan CRLs disimpan dan diproses pada titik akhir dan dapat menjadi basi, persyaratan penyimpanan dan pemrosesan OCSP ditangani secara serempak di backend responder.
Saat Anda mengaktifkan OCSP untuk CA, AWS Private CA sertakan URL responden OCSP dalam ekstensi *Authority Information Access* (AIA) dari setiap sertifikat baru yang dikeluarkan. Ekstensi ini memungkinkan klien seperti browser web untuk menanyakan responden dan menentukan apakah sertifikat CA entitas akhir atau bawahan dapat dipercaya. Responden mengembalikan pesan status yang ditandatangani secara kriptografi untuk memastikan keasliannya.
[Responden AWS Private CA OCSP sesuai dengan RFC 5019.](https://datatracker.ietf.org/doc/html/rfc5019)
**Pertimbangan OCSP**
+ Pesan status OCSP ditandatangani menggunakan algoritma penandatanganan yang sama dengan CA penerbit yang dikonfigurasi untuk digunakan. CAs dibuat di AWS Private CA konsol menggunakan algoritma tanda tangan SHA256 WITHRSA secara default. Algoritma lain yang didukung dapat ditemukan di dokumentasi [CertificateAuthorityConfiguration](https://docs.aws.amazon.com/privateca/latest/APIReference/API_CertificateAuthorityConfiguration.html)API.
+ [APIPassthrough dan](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html#template-varieties) templat CSRPassthrough sertifikat tidak akan berfungsi dengan ekstensi AIA jika responden OCSP diaktifkan.
+ Titik akhir dari layanan OCSP yang dikelola dapat diakses di internet publik. Pelanggan yang menginginkan OCSP tetapi memilih untuk tidak memiliki titik akhir publik perlu mengoperasikan infrastruktur OCSP mereka sendiri.
+ **Daftar Pencabutan Sertifikat () CRLs**
Daftar pencabutan sertifikasi (CRL) adalah file yang berisi daftar sertifikat yang dicabut sebelum tanggal kedaluwarsa yang dijadwalkan. CRL berisi daftar sertifikat yang seharusnya tidak lagi dipercaya, alasan pencabutan, dan informasi relevan lainnya.
Saat mengonfigurasi otoritas sertifikat (CA), Anda dapat memilih apakah AWS Private CA membuat CRL lengkap atau terpartisi. Pilihan Anda menentukan jumlah maksimum sertifikat yang dapat diterbitkan dan dicabut oleh otoritas sertifikat. Untuk informasi lebih lanjut, lihat [AWS Private CA kuota](https://docs.aws.amazon.com/general/latest/gr/pca.html#limits_pca).
**Pertimbangan CRL**
+ Pertimbangan memori dan bandwidth: CRLs membutuhkan lebih banyak memori daripada OCSP karena persyaratan unduhan dan pemrosesan lokal. Namun, CRLs mungkin mengurangi bandwidth jaringan dibandingkan dengan OCSP dengan caching daftar pencabutan alih-alih memeriksa status per koneksi. Untuk perangkat yang dibatasi memori, seperti perangkat IoT tertentu, pertimbangkan untuk menggunakan partisi. CRLs
+ Mengubah jenis CRL: Saat mengubah dari CRL lengkap ke partisi, AWS Private CA buat partisi baru sesuai kebutuhan dan tambahkan ekstensi IDP ke semua, termasuk yang asli. CRLs Mengubah dari dipartisi untuk menyelesaikan pembaruan hanya satu CRL dan mencegah pencabutan sertifikat di masa depan yang terkait dengan partisi sebelumnya.
**catatan**
Baik OCSP dan CRLs menunjukkan beberapa penundaan antara pencabutan dan ketersediaan perubahan status.
Tanggapan OCSP dapat memakan waktu hingga 60 menit untuk mencerminkan status baru saat Anda mencabut sertifikat. Secara umum, OCSP cenderung mendukung distribusi informasi pencabutan yang lebih cepat karena, tidak seperti CRLs yang dapat di-cache oleh klien selama berhari-hari, respons OCSP biasanya tidak di-cache oleh klien.
CRL biasanya diperbarui sekitar 30 menit setelah sertifikat dicabut. Jika karena alasan apa pun pembaruan CRL gagal, lakukan AWS Private CA upaya lebih lanjut setiap 15 menit.
## Persyaratan umum untuk konfigurasi pencabutan
Persyaratan berikut berlaku untuk semua konfigurasi pencabutan.
+ Konfigurasi menonaktifkan CRLs atau OCSP harus berisi hanya `Enabled=False` parameter, dan akan gagal jika parameter lain seperti `CustomCname` atau `ExpirationInDays` disertakan.
+ Dalam konfigurasi CRL, `S3BucketName` parameter harus sesuai dengan aturan [penamaan bucket Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html).
+ Konfigurasi yang berisi parameter Nama Canonical kustom (CNAME) untuk CRLs atau OCSP harus sesuai dengan [RFC7230](https://www.ietf.org/rfc/rfc7230.txt)pembatasan penggunaan karakter khusus dalam CNAME.
+ Dalam konfigurasi CRL atau OCSP, nilai parameter CNAME tidak boleh menyertakan awalan protokol seperti “http://” atau “https://”.
**Topics**
+ [Persyaratan umum untuk konfigurasi pencabutan](#revocation-requirements)
+ [Siapkan CRL untuk AWS Private CA](crl-planning.md)
+ [Kustomisasi URL OCSP untuk AWS Private CA](ocsp-customize.md)
# Siapkan CRL untuk AWS Private CA
Sebelum Anda dapat mengonfigurasi daftar pencabutan sertifikat (CRL) sebagai bagian dari [proses pembuatan CA](create-CA.md), beberapa pengaturan sebelumnya mungkin diperlukan. Bagian ini menjelaskan prasyarat dan opsi yang harus Anda pahami sebelum membuat CA dengan CRL terlampir.
Untuk informasi tentang menggunakan Online Certificate Status Protocol (OCSP) sebagai alternatif atau suplemen CRL, lihat [](create-CA.md#PcaCreateRevocation) dan. [Kustomisasi URL OCSP untuk AWS Private CA](ocsp-customize.md)
**Topics**
+ [Jenis CRL](#crl-type)
+ [Struktur CRL](#crl-structure)
+ [Kebijakan akses untuk CRLs di Amazon S3](#s3-policies)
+ [Aktifkan S3 Block Public Access (BPA) dengan CloudFront](#s3-bpa)
+ [Menentukan URI Titik Distribusi CRL (CDP)](#crl-url)
+ [](#crl-ipv6)
## Jenis CRL
+ **Selesai** - Pengaturan default. AWS Private CA memelihara file CRL tunggal yang tidak dipartisi untuk semua sertifikat yang belum kedaluwarsa yang dikeluarkan oleh CA yang telah dicabut. [Setiap sertifikat yang AWS Private CA diterbitkan terikat pada CRL tertentu melalui ekstensi CRL distribution point (CDP), sebagaimana didefinisikan dalam RFC 5280.](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9) Anda dapat memiliki hingga 1 juta sertifikat pribadi untuk setiap CA dengan CRL lengkap diaktifkan. Untuk informasi lebih lanjut, lihat [AWS Private CA kuota](https://docs.aws.amazon.com/general/latest/gr/pca.html#limits_pca).
+ **Dipartisi** - Dibandingkan dengan yang lengkap CRLs, dipartisi CRLs secara dramatis meningkatkan jumlah sertifikasi yang dapat dikeluarkan CA pribadi Anda, dan menyelamatkan Anda dari sering memutar. CAs
**penting**
Saat menggunakan partisi CRLs, Anda harus memvalidasi bahwa URI titik distribusi penerbitan terkait (IDP) CRL cocok dengan URI CDP sertifikasi untuk memastikan CRL yang tepat telah diambil. AWS Private CA menandai ekstensi IDP sebagai hal yang penting, yang harus dapat diproses oleh klien Anda.
## Struktur CRL
Setiap CRL adalah file DER yang dikodekan. Untuk mengunduh file dan menggunakan [OpenSSL](https://www.openssl.org/) untuk melihatnya, gunakan perintah yang mirip dengan berikut ini:
```
openssl crl -inform DER -in path-to-crl-file -text -noout
```
CRLs memiliki format berikut:
```
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
```
**catatan**
CRL hanya akan disimpan di Amazon S3 setelah sertifikat dikeluarkan yang merujuknya. Sebelum itu, hanya akan ada file `acm-pca-permission-test-key` yang terlihat di bucket Amazon S3.
## Kebijakan akses untuk CRLs di Amazon S3
Jika Anda berencana membuat CRL, Anda perlu menyiapkan ember Amazon S3 untuk menyimpannya. AWS Private CA secara otomatis menyetor CRL di bucket Amazon S3 yang Anda tunjuk dan memperbaruinya secara berkala. Untuk informasi selengkapnya, lihat [Membuat bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket.html).
Bucket S3 Anda harus diamankan dengan kebijakan izin IAM terlampir. Pengguna resmi dan kepala layanan memerlukan `Put` izin AWS Private CA untuk mengizinkan menempatkan objek di ember, dan `Get` izin untuk mengambilnya.
**catatan**
Konfigurasi kebijakan IAM tergantung pada yang Wilayah AWS terlibat. Wilayah terbagi dalam dua kategori:
**Default-enabled Regions — Wilayah** yang *diaktifkan* secara default untuk semua. Akun AWS
Wilayah yang **dinonaktifkan default — Wilayah** yang *dinonaktifkan* secara default, tetapi dapat diaktifkan secara manual oleh pelanggan.
[Untuk informasi selengkapnya dan daftar Wilayah yang dinonaktifkan default, lihat Mengelola. Wilayah AWS](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) Untuk diskusi tentang prinsip-prinsip layanan dalam konteks IAM, lihat [prinsip AWS layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-services-in-opt-in-regions) di Wilayah opt-in.
Saat Anda mengonfigurasi CRLs sebagai metode pencabutan sertifikat, AWS Private CA buat CRL dan terbitkan ke bucket S3. Bucket S3 memerlukan kebijakan IAM yang memungkinkan kepala AWS Private CA layanan untuk menulis ke bucket. Nama kepala layanan bervariasi sesuai dengan Wilayah yang digunakan, dan tidak semua kemungkinan didukung.
****
| PCA | S3 | Pemimpin layanan |
| --- | --- | --- |
| Keduanya di wilayah yang sama | `acm-pca.amazonaws.com` |
| Diaktifkan | Diaktifkan | `acm-pca.amazonaws.com` |
| Dinonaktifkan | Diaktifkan | `acm-pca.Region.amazonaws.com` |
| Diaktifkan | Dinonaktifkan | Tidak didukung |
Kebijakan default tidak berlaku `SourceArn` pembatasan pada CA. Kami menyarankan Anda menerapkan kebijakan yang kurang permisif seperti berikut ini, yang membatasi akses ke AWS akun tertentu dan CA pribadi tertentu. Atau, Anda dapat menggunakan kunci kondisi [aws: SourceOrg ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgid) untuk membatasi akses ke organisasi tertentu di AWS Organizations. Untuk informasi selengkapnya tentang kebijakan bucket, lihat [Kebijakan Bucket untuk Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html).
Jika Anda memilih untuk mengizinkan kebijakan default, Anda selalu dapat [memodifikasinya](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html) nanti.
## Aktifkan S3 Block Public Access (BPA) dengan CloudFront
Bucket Amazon S3 yang baru dikonfigurasi secara default dengan fitur Blokir Akses Publik (BPA) yang aktif. Termasuk dalam [praktik terbaik keamanan](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html) Amazon S3, BPA adalah seperangkat kontrol akses yang dapat digunakan pelanggan untuk menyempurnakan akses ke objek di bucket S3 mereka dan ke ember secara keseluruhan. Ketika BPA aktif dan dikonfigurasi dengan benar, hanya AWS pengguna yang berwenang dan diautentikasi yang memiliki akses ke ember dan isinya.
AWS merekomendasikan penggunaan BPA pada semua bucket S3 untuk menghindari paparan informasi sensitif terhadap musuh potensial. Namun, perencanaan tambahan diperlukan jika klien PKI Anda mengambil CRLs di internet publik (yaitu, saat tidak masuk ke AWS akun). Bagian ini menjelaskan cara mengonfigurasi solusi PKI pribadi menggunakan Amazon CloudFront, jaringan pengiriman konten (CDN), untuk melayani CRLs tanpa memerlukan akses klien yang diautentikasi ke bucket S3.
**catatan**
Menggunakan CloudFront menimbulkan biaya tambahan pada akun Anda AWS . Untuk informasi selengkapnya, lihat [ CloudFront Harga Amazon](https://aws.amazon.com/cloudfront/pricing/).
Jika Anda memilih untuk menyimpan CRL Anda di bucket S3 dengan BPA diaktifkan, dan Anda tidak menggunakannya CloudFront, Anda harus membangun solusi CDN lain untuk memastikan bahwa klien PKI Anda memiliki akses ke CRL Anda.
### Siapkan CloudFront untuk BPA
Buat CloudFront distribusi yang akan memiliki akses ke bucket S3 pribadi Anda, dan dapat melayani CRLs klien yang tidak diautentikasi.
**Untuk mengkonfigurasi CloudFront distribusi untuk CRL**
1. Buat CloudFront distribusi baru menggunakan prosedur dalam [Membuat Distribusi](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-creating-console.html) di *Panduan CloudFront Pengembang Amazon*.
Saat menyelesaikan prosedur, terapkan pengaturan berikut:
+ Di **Nama Domain Asal**, pilih bucket S3 Anda.
+ Pilih **Ya** untuk **Batasi Akses Bucket**.
+ Pilih **Buat Identitas Baru** untuk **Identitas Akses Asal**.
+ Pilih **Ya, Perbarui Kebijakan Bucket** di bawah **Berikan Izin Baca pada Bucket**.
**catatan**
Dalam prosedur ini, CloudFront ubah kebijakan bucket Anda agar dapat mengakses objek bucket. Pertimbangkan [mengedit](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html) kebijakan ini untuk hanya mengizinkan akses ke objek di bawah folder `crl`.
1. Setelah distribusi diinisialisasi, cari nama domainnya di CloudFront konsol dan simpan untuk prosedur selanjutnya.
**catatan**
Jika bucket S3 Anda baru dibuat di Wilayah selain us-east-1, Anda mungkin mendapatkan kesalahan pengalihan sementara HTTP 307 saat mengakses aplikasi yang dipublikasikan melalui. CloudFront Mungkin perlu beberapa jam agar alamat ember menyebar.
### Siapkan CA Anda untuk BPA
Saat mengonfigurasi CA baru Anda, sertakan alias ke distribusi Anda CloudFront.
**Untuk mengonfigurasi CA Anda dengan CNAME untuk CloudFront**
+ Buat CA Anda menggunakan [Buat CA pribadi di AWS Private CA](create-CA.md).
Saat Anda melakukan prosedur, file pencabutan `revoke_config.txt` harus menyertakan baris berikut untuk menentukan objek CRL non-publik dan untuk memberikan URL ke titik akhir distribusi di: CloudFront
```
"S3ObjectAcl":"BUCKET_OWNER_FULL_CONTROL",
"CustomCname":"abcdef012345.cloudfront.net"
```
Setelah itu, ketika Anda mengeluarkan sertifikat dengan CA ini, sertifikat tersebut akan berisi blok seperti berikut:
```
X509v3 CRL Distribution Points:
Full Name:
URI:http://abcdef012345.cloudfront.net/crl/01234567-89ab-cdef-0123-456789abcdef.crl
```
**catatan**
Jika Anda memiliki sertifikat yang lebih lama yang diterbitkan oleh CA ini, sertifikat tersebut akan dapat mengakses CRL.
## Menentukan URI Titik Distribusi CRL (CDP)
Jika Anda perlu menggunakan URI Titik Distribusi CRL (CDP) di alur kerja Anda, Anda dapat mengeluarkan sertifikat menggunakan URI CRL pada sertifikat tersebut atau menggunakan metode berikut. Ini hanya berfungsi untuk lengkap CRLs. Dipartisi CRLs memiliki GUID acak yang ditambahkan padanya.
Jika Anda menggunakan bucket S3 sebagai CRL Distribution Point (CDP) untuk CA Anda, URI CDP dapat berada dalam salah satu format berikut.
+ `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`
Jika Anda telah mengonfigurasi CA Anda dengan CNAME kustom, URI CDP akan menyertakan CNAME, misalnya, `http://alternative.example.com/crl/CA-ID.crl`
##
Secara default, AWS Private CA tulis ekstensi CDP menggunakan titik akhir regional, IPv4 -only`amazonaws.com`. Untuk menggunakan CRLs over IPv6, lakukan salah satu langkah berikut sehingga CDPs ditulis dengan titik URLs itu ke titik akhir [dualstack S3](https://docs.aws.amazon.com/AmazonS3/latest/API/dual-stack-endpoints.html):
+ Tetapkan [nama kustom CRL](create-CA.md#PcaCreateRevocation) Anda ke domain endpoint dualstack S3. Sebagai contoh, `bucketname.s3.dualstack.region-code.amazonaws.com`.
+ Siapkan catatan DNS CNAME Anda sendiri yang menunjuk ke titik akhir dualstack S3 yang relevan, lalu gunakan sebagai nama kustom CRL Anda
# Kustomisasi URL OCSP untuk AWS Private CA
**catatan**
Topik ini ditujukan untuk pelanggan yang ingin menyesuaikan URL publik dari titik akhir responder Online Certificate Status Protocol (OCSP) untuk branding atau tujuan lain. Jika Anda berencana untuk menggunakan konfigurasi default OCSP AWS Private CA terkelola, Anda dapat melewati topik ini dan mengikuti petunjuk [konfigurasi di Configure revocation](create-CA.md#PcaCreateRevocation).
Secara default, saat Anda mengaktifkan OCSP AWS Private CA, setiap sertifikat yang Anda terbitkan berisi URL untuk responden AWS OCSP. Hal ini memungkinkan klien meminta koneksi kriptografis aman untuk mengirim kueri validasi OCSP langsung ke. AWS Namun, dalam beberapa kasus, mungkin lebih baik untuk menyatakan URL yang berbeda di sertifikat Anda sambil tetap mengirimkan kueri OCSP ke. AWS
**catatan**
Untuk informasi tentang menggunakan daftar pencabutan sertifikat (CRL) sebagai alternatif atau tambahan untuk OCSP, lihat [Mengkonfigurasi pencabutan dan Merencanakan daftar pencabutan](create-CA.md#PcaCreateRevocation) [sertifikat](crl-planning.md) (CRL).
Tiga elemen yang terlibat dalam mengkonfigurasi URL kustom untuk OCSP.
+ **Konfigurasi CA** - Tentukan URL OCSP kustom di `RevocationConfiguration` CA Anda seperti yang dijelaskan [Contoh 2: Buat CA dengan OCSP dan CNAME kustom diaktifkan](create-CA.md#example_2) dalam[Buat CA pribadi di AWS Private CA](create-CA.md).
+ **DNS** — Tambahkan catatan CNAME ke konfigurasi domain Anda untuk memetakan URL yang muncul di sertifikat ke URL server proxy. Untuk informasi selengkapnya, lihat [Contoh 2: Buat CA dengan OCSP dan CNAME kustom diaktifkan](create-CA.md#example_2) di [Buat CA pribadi di AWS Private CA](create-CA.md).
+ **Forwarding proxy server** - Siapkan server proxy yang dapat secara transparan meneruskan lalu lintas OCSP yang diterimanya ke responder OCSP. AWS
Diagram berikut menggambarkan bagaimana elemen-elemen ini bekerja sama.
![\[Topologi OCSP kustom\]](http://docs.aws.amazon.com/id_id/privateca/latest/userguide/images/ocsp.png)
Seperti yang ditunjukkan pada diagram, proses validasi OCSP yang disesuaikan melibatkan langkah-langkah berikut:
1. Klien menanyakan DNS untuk domain target.
1. Klien menerima IP target.
1. Klien membuka koneksi TCP dengan target.
1. Klien menerima sertifikat TLS target.
1. Klien menanyakan DNS untuk domain OCSP yang tercantum dalam sertifikat.
1. Klien menerima IP proxy.
1. Klien mengirimkan kueri OCSP ke proxy.
1. Proxy meneruskan kueri ke responder OCSP.
1. Responder mengembalikan status sertifikat ke proxy.
1. Proxy meneruskan status sertifikat ke klien.
1. Jika sertifikat valid, klien memulai jabat tangan TLS.
**Tip**
Contoh ini dapat diimplementasikan menggunakan [Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/) dan [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/) setelah Anda mengonfigurasi CA seperti yang dijelaskan di atas.
Di CloudFront, buat distribusi dan konfigurasikan sebagai berikut:
Buat nama alternatif yang cocok dengan CNAME kustom Anda.
Ikat sertifikat Anda untuk itu.
Tetapkan `ocsp.acm-pca..amazonaws.com` sebagai asal.
Untuk menggunakan IPv6 koneksi, gunakan titik akhir dualstack `acm-pca-ocsp..api.aws`
Terapkan `Managed-CachingDisabled` kebijakan.
Tetapkan **kebijakan protokol Viewer** ke **HTTP dan HTTPS**.
Atur **metode HTTP yang Diizinkan** untuk **GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE**.
Di Route 53, buat catatan DNS yang memetakan CNAME kustom Anda ke URL distribusi. CloudFront
## Menggunakan OCSP di atas IPv6
URL responder AWS Private CA OCSP default adalah IPv4 -only. Untuk menggunakan OCSP over IPv6, konfigurasikan URL OCSP kustom untuk CA Anda. URL dapat berupa:
+ FQDN dari responder PCA OCSP dualstack, yang mengambil bentuk `acm-pca-ocsp.region-name.api.aws`
+ Catatan CNAME yang telah Anda konfigurasikan untuk menunjuk pada responder OCSP dualstack, seperti yang dijelaskan di atas.