Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Apa itu AWS Private CA?
AWS Private CA memungkinkan pembuatan hierarki otoritas sertifikat swasta (CA), termasuk root dan bawahan CAs, tanpa biaya investasi dan pemeliharaan pengoperasian CA lokal. Pribadi Anda CAs dapat menerbitkan sertifikat X.509 entitas akhir yang berguna dalam skenario termasuk:
+ Membuat saluran komunikasi TLS terenkripsi
+ Mengautentikasi pengguna, komputer, titik akhir API, dan perangkat IoT
+ Kode penandatanganan kriptografi
+ Menerapkan Protokol Status Sertifikat Online (OCSP) untuk mendapatkan status pencabutan sertifikat
AWS Private CA operasi dapat diakses dari Konsol Manajemen AWS, menggunakan AWS Private CA API, atau menggunakan AWS CLI.
**Topics**
+ [Ketersediaan regional untuk AWS Private Certificate Authority](#PcaRegions)
+ [Layanan terintegrasi dengan AWS Private Certificate Authority](#PcaIntegratedServices)
+ [Algoritma kriptografi yang didukung di AWS Private Certificate Authority](#supported-algorithms)
+ [Kepatuhan RFC 5280 di AWS Private Certificate Authority](#RFC-compliance)
+ [Harga untuk AWS Private Certificate Authority](#PcaPricing)
+ [Syarat dan konsep untuk AWS Private CA](PcaTerms.md)
## Ketersediaan regional untuk AWS Private Certificate Authority
Seperti kebanyakan AWS sumber daya, otoritas sertifikat swasta (CAs) adalah sumber daya Regional. Untuk menggunakan privat CAs di lebih dari satu Wilayah, Anda harus membuat CAs di Wilayah tersebut. Anda tidak dapat menyalin pribadi CAs antar Wilayah. Kunjungi [AWS Wilayah dan Titik Akhir](https://docs.aws.amazon.com/general/latest/gr/rande.html#pca_region) di *Referensi Umum AWS*atau [Tabel AWS Wilayah](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) untuk melihat ketersediaan Regional. AWS Private CA
**catatan**
ACM saat ini tersedia di beberapa wilayah yang AWS Private CA tidak.
## Layanan terintegrasi dengan AWS Private Certificate Authority
Jika Anda menggunakan AWS Certificate Manager untuk meminta sertifikat pribadi, Anda dapat mengaitkan sertifikat itu dengan layanan apa pun yang terintegrasi dengan ACM. Ini berlaku baik untuk sertifikat yang dirantai ke AWS Private CA root dan sertifikat yang dirantai ke root eksternal. Untuk informasi selengkapnya, lihat [Layanan Terpadu](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) di Panduan AWS Certificate Manager Pengguna.
Anda juga dapat mengintegrasikan private CAs ke Amazon Elastic Kubernetes Service untuk memberikan penerbitan sertifikat di dalam klaster Kubernetes. Untuk informasi selengkapnya, lihat [Amankan Kubernetes dengan AWS Private Certificate Authority](PcaKubernetes.md).
**catatan**
Amazon Elastic Kubernetes Service bukan layanan terintegrasi ACM.
Jika Anda menggunakan AWS Private CA API atau AWS CLI menerbitkan sertifikat atau mengekspor sertifikat pribadi dari ACM, Anda dapat menginstal sertifikat di mana pun Anda inginkan.
## Algoritma kriptografi yang didukung di AWS Private Certificate Authority
AWS Private CA mendukung algoritma kriptografi berikut untuk pembuatan kunci pribadi dan penandatanganan sertifikat.
**Algoritme yang didukung**
| Algoritme kunci privat | Algoritme penandatanganan |
| --- | --- |
| ML\$1DSA\$144 ML\$1DSA\$165 ML\$1DSA\$187 RSA\$12048 RSA\$13072 RSA\$14096 EC\$1prime256v1 EC\$1secp384r1 EC\$1secp521r1 SM2 (Hanya Wilayah Tiongkok) | ML\$1DSA\$144ML\$1DSA\$165ML\$1DSA\$187 SHA256WITHRSASHA384WITHRSASHA512WITHRSASHA256DENGANECDSA SHA384DENGANECDSASHA512DENGANECDSASM3WITHSM2 |
Daftar ini hanya berlaku untuk sertifikat yang dikeluarkan langsung AWS Private CA melalui konsol, API, atau baris perintahnya. Saat AWS Certificate Manager mengeluarkan sertifikat menggunakan CA dari AWS Private CA, ini mendukung beberapa tetapi tidak semua algoritme ini. Untuk informasi selengkapnya, lihat [Meminta Sertifikat Pribadi](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-private.html) di Panduan AWS Certificate Manager Pengguna.
**catatan**
Untuk RSA atau ECDSA, keluarga algoritma penandatanganan yang ditentukan harus cocok dengan keluarga algoritma kunci kunci privat CA.
Untuk ML-DSA, fungsi hash didefinisikan sebagai bagian dari algoritma itu sendiri. Tidak ada pilihan untuk memilih fungsi hash yang berbeda dengan ML-DSA. Untuk mempertahankan kompatibilitas mundur dengan APIs, nilai yang sama digunakan untuk algoritma kunci dan algoritma penandatanganan.
## Kepatuhan RFC 5280 di AWS Private Certificate Authority
AWS Private CA [tidak memberlakukan batasan tertentu yang ditentukan dalam RFC 5280.](https://datatracker.ietf.org/doc/html/rfc5280) Situasi sebaliknya juga benar: kendala tambahan tertentu yang sesuai untuk CA privat diberlakukan.
**Ditegakkan**
+ [Tidak Setelah tanggal](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.5). Sesuai dengan [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280), AWS Private CA mencegah penerbitan sertifikat yang bertuliskan `Not After` tanggal lebih lambat dari tanggal penerbitan sertifikat CA. `Not After`
+ [Kendala dasar](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9). AWS Private CA memberlakukan batasan dasar dan panjang jalur dalam sertifikat CA yang diimpor.
Kendala dasar menunjukkan apakah sumber daya yang diidentifikasi oleh sertifikat adalah CA dan dapat mengeluarkan sertifikat. Sertifikat CA yang diimpor AWS Private CA harus menyertakan ekstensi kendala dasar, dan ekstensi harus ditandai. `critical` Selain `critical` bendera, `CA=true` harus diatur. AWS Private CA memberlakukan kendala dasar dengan gagal dengan pengecualian validasi karena alasan berikut:
+ Ekstensi tidak termasuk dalam sertifikat CA.
+ Ekstensi tidak ditandai `critical`.
Panjang jalur ([pathLenConstraint](PcaTerms.md#terms-pathlength)) menentukan berapa banyak bawahan yang CAs mungkin ada di hilir dari sertifikat CA yang diimpor. AWS Private CA memberlakukan panjang jalur dengan gagal dengan pengecualian validasi karena alasan berikut:
+ Mengimpor sertifikat CA akan melanggar kendala panjang jalur dalam sertifikat CA atau sertifikat CA apa pun dalam rantai.
+ Menerbitkan sertifikat akan melanggar kendala panjang jalur.
+ [Batasan nama](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.10) menunjukkan ruang nama di mana semua nama subjek dalam sertifikat berikutnya di jalur sertifikasi harus ditempatkan. Pembatasan berlaku untuk nama subjek yang dibedakan dan nama alternatif subjek.
**Tidak ditegakkan**
+ [Kebijakan sertifikat](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.4). Kebijakan sertifikat mengatur kondisi di mana CA mengeluarkan sertifikat.
+ [Menghambat AnyPolicy](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.14). Digunakan dalam sertifikat yang dikeluarkan untukCAs.
+ [Nama Alternatif Penerbit](https://datatracker.ietf.org/doc/html/rfc5280#section-section-4.2.1.7). Memungkinkan identitas tambahan dikaitkan dengan penerbit sertifikat CA.
+ [Kendala kebijakan](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.11). Kendala ini membatasi kapasitas CA untuk menerbitkan sertifikat CA bawahan.
+ [Pemetaan Kebijakan](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.5). Digunakan dalam sertifikat CA. Daftar satu atau lebih pasangan OIDs; setiap pasangan termasuk issuerDomainPolicy dan asubjectDomainPolicy.
+ [Atribut Direktori Subjek](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.8). Digunakan untuk menyampaikan atribut identifikasi subjek.
+ [Akses Informasi Subjek](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.2.2). Cara mengakses informasi dan layanan untuk subjek sertifikat di mana ekstensi muncul.
+ [Subject Key Identifier (SKI)](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.2) dan [Authority Key Identifier (AKI)](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.1). RFC memerlukan sertifikat CA yang berisi ekstensi SKI. Sertifikat yang dikeluarkan oleh CA harus berisi ekstensi AKI yang cocok dengan SKI sertifikat CA. AWS tidak menegakkan persyaratan ini. Jika Sertifikat CA Anda tidak berisi SKI, entitas akhir yang diterbitkan atau sertifikat CA bawahan AKI akan menjadi hash SHA-1 dari kunci publik penerbit.
+ [SubjectPublicKeyInfo](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1)dan [Nama Alternatif Subjek (SAN)](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.6). Saat menerbitkan sertifikat, salin ekstensi AWS Private CA SubjectPublicKeyInfo dan SAN dari CSR yang disediakan tanpa melakukan validasi.
## Harga untuk AWS Private Certificate Authority
Akun Anda dikenai harga bulanan untuk setiap CA privat mulai dari saat Anda membuatnya. Anda juga dikenakan biaya untuk setiap sertifikat yang Anda keluarkan. Biaya ini mencakup sertifikat yang Anda ekspor dari ACM dan sertifikat yang Anda buat dari AWS Private CA API atau AWS Private CA CLI. Anda tidak dikenakan biaya untuk CA privat setelah dihapus. Namun, jika Anda memulihkan CA privat, Anda akan dikenakan biaya untuk waktu antara penghapusan dan pemulihan. Sertifikat privat yang kunci privatnya tidak dapat Anda akses gratis. Ini termasuk sertifikat yang digunakan dengan [Layanan Terpadu](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) seperti Elastic Load Balancing, CloudFront, dan API Gateway.
Untuk informasi AWS Private CA harga terbaru, lihat [AWS Private Certificate Authority Harga](https://aws.amazon.com/private-ca/pricing/). Anda juga dapat menggunakan [kalkulator AWS harga](https://calculator.aws/#/createCalculator/certificateManager) untuk memperkirakan biaya.
# Syarat dan konsep untuk AWS Private CA
Istilah dan konsep berikut dapat membantu Anda saat Anda bekerja dengannya AWS Private Certificate Authority.
**Topics**
+ [Percaya](#terms-trust)
+ [Sertifikat server TLS](#terms-tlscert)
+ [Tanda tangan sertifikat](#terms-signing)
+ [Otoritas sertifikat](#terms-ca)
+ [CA akar](#terms-rootca)
+ [Sertifikat CA](#terms-ca-cert)
+ [Sertifikat Root CA](#terms-root)
+ [Sertifikat entitas akhir](#terms-endentity)
+ [Sertifikat yang ditandatangani sendiri](#terms-selfsignedcert)
+ [Sertifikat pribadi](#terms-pca-cert)
+ [Jalur sertifikat](#terms-certpath)
+ [Kendala panjang jalur](#terms-pathlength)
## Percaya
Agar peramban web mempercayai identitas situs web, peramban harus dapat memverifikasi sertifikat situs web. Namun, peramban hanya mempercayai sejumlah kecil sertifikat yang dikenal sebagai sertifikat akar CA. Pihak ketiga tepercaya, yang dikenal sebagai otoritas sertifikasi (CA), memvalidasi identitas situs web dan menerbitkan sertifikat digital yang ditandatangani ke operator situs web. Peramban kemudian dapat memeriksa tanda tangan digital untuk memvalidasi identitas situs web. Jika validasi berhasil, peramban menampilkan ikon kunci di bilah alamat.
## Sertifikat server TLS
Transaksi HTTPS memerlukan sertifikat server untuk mengautentikasi server. Sertifikat server adalah struktur data X.509 v3 yang mengikat kunci publik dalam sertifikat ke subjek sertifikat. Sertifikat TLS ditandatangani oleh otoritas sertifikat (CA). Ini berisi nama server, masa berlaku, kunci publik, algoritme tanda tangan, dan banyak lagi.
## Tanda tangan sertifikat
Tanda tangan digital adalah hash yang dienkripsi melalui sertifikat. Tanda tangan digunakan untuk menegaskan integritas data sertifikat. CA pribadi Anda membuat tanda tangan dengan menggunakan fungsi hash kriptografi seperti SHA256 di atas konten sertifikat berukuran variabel. Fungsi hash ini menghasilkan string data ukuran tetap yang efektif tidak dapat ditempa. String ini disebut hash. CA kemudian mengenkripsi nilai hash dengan kunci privat dan menggabungkan hash yang dienkripsi dengan sertifikat.
## Otoritas sertifikat
Otoritas sertifikasi (CA) menerbitkan dan jika perlu mencabut sertifikat digital. Jenis sertifikat yang paling umum didasarkan pada standar ISO X.509. Sertifikat X.509 menegaskan identitas subjek sertifikat dan mengikat identitas tersebut ke kunci publik. Subjek dapat berupa pengguna, aplikasi, komputer, atau perangkat lain. CA menandatangani sertifikat dengan melakukan hash pada konten dan kemudian mengenkripsi hash dengan kunci privat yang terkait dengan kunci publik dalam sertifikat. Aplikasi klien seperti peramban web yang perlu menegaskan identitas subjek menggunakan kunci publik untuk mendekripsi tanda tangan sertifikat. Ini kemudian melakukan hash pada isi sertifikat dan membandingkan nilai hash dengan tanda tangan yang didekripsi untuk menentukan apakah cocok. Untuk informasi selengkapnya tentang penandatanganan sertifikat, lihat [Tanda tangan sertifikat](#terms-signing).
Anda dapat menggunakan AWS Private CA untuk membuat CA pribadi dan menggunakan CA pribadi untuk menerbitkan sertifikat. CA pribadi Anda hanya mengeluarkan SSL/TLS sertifikat pribadi untuk digunakan dalam organisasi Anda. Untuk informasi selengkapnya, lihat [Sertifikat pribadi](#terms-pca-cert). CA privat Anda juga memerlukan sertifikat sebelum dapat menggunakannya. Untuk informasi selengkapnya, lihat [Sertifikat CA](#terms-ca-cert).
## CA akar
Blok bangunan kriptografi dan akar kepercayaan tempat sertifikat dapat diterbitkan. Ini terdiri dari kunci privat untuk menandatangani (menerbitkan) sertifikat dan sertifikat akar yang mengidentifikasi CA akar dan mengikat kunci privat ke nama CA. Sertifikat akar didistribusikan ke penyimpanan kepercayaan setiap entitas di lingkungan. Administrator membangun toko kepercayaan untuk memasukkan hanya CAs yang mereka percayai. Administrator memperbarui atau membangun penyimpanan kepercayaan ke dalam sistem operasi, instans, dan citra mesin host entitas di lingkungannya. Ketika sumber daya mencoba untuk terhubung satu sama lain, mereka memeriksa sertifikat yang disajikan setiap entitas. Klien memeriksa sertifikat untuk validitas dan apakah ada rantai dari sertifikat ke sertifikat root yang diinstal di penyimpanan kepercayaan. Jika kondisi tersebut terpenuhi, "jabat tangan" dilakukan antara sumber daya. Jabat tangan ini secara kriptografis membuktikan identitas masing-masing entitas dengan yang lain dan menciptakan saluran komunikasi terenkripsi (TLS/SSL) di antaranya.
## Sertifikat CA
Sertifikat otoritas sertifikasi (CA) menegaskan identitas CA dan mengikatnya ke kunci publik yang ada dalam sertifikat.
Anda dapat menggunakan AWS Private CA untuk membuat CA root pribadi atau CA bawahan pribadi, masing-masing didukung oleh sertifikat CA. Sertifikat CA bawahan ditandatangani oleh sertifikat CA lain yang lebih tinggi dalam rantai kepercayaan. Tetapi dalam kasus CA akar, sertifikat ditandatangani sendiri. Anda juga dapat membuat otoritas akar eksternal (dihosting on premise, misalnya). Anda kemudian dapat menggunakan otoritas root Anda untuk menandatangani sertifikat CA root bawahan yang dihosting oleh AWS Private CA.
Contoh berikut menunjukkan bidang tipikal yang terkandung dalam sertifikat CA AWS Private CA X.509. Perhatikan bahwa untuk sertifikat CA, nilai `CA:` dalam bidang `Basic Constraints` diatur ke `TRUE`.
```
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4121 (0x1019)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Washington, L=Seattle, O=Example Company Root CA, OU=Corp, CN=www.example.com/emailAddress=corp@www.example.com
Validity
Not Before: Feb 26 20:27:56 2018 GMT
Not After : Feb 24 20:27:56 2028 GMT
Subject: C=US, ST=WA, L=Seattle, O=Examples Company Subordinate CA, OU=Corporate Office, CN=www.example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c0: ... a3:4a:51
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
F8:84:EE:37:21:F2:5E:0B:6C:40:C2:9D:C6:FE:7E:49:53:67:34:D9
X509v3 Authority Key Identifier:
keyid:0D:CE:76:F2:E3:3B:93:2D:36:05:41:41:16:36:C8:82:BC:CB:F8:A0
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Digital Signature, CRL Sign
Signature Algorithm: sha256WithRSAEncryption
6:bb:94: ... 80:d8
```
## Sertifikat Root CA
Otoritas sertifikat (CA) biasanya ada dalam struktur hierarkis yang berisi beberapa lainnya CAs dengan hubungan orangtua-anak yang jelas di antara mereka. Anak atau bawahan CAs disertifikasi oleh orang tua mereka CAs, membuat rantai sertifikat. CA di bagian atas hierarki disebut sebagai CA akar, dan sertifikatnya disebut sertifikat akar. Sertifikat ini biasanya ditandatangani sendiri.
## Sertifikat entitas akhir
Sertifikat entitas akhir mengidentifikasi sumber daya, seperti server, instans, kontainer, atau perangkat. Tidak seperti sertifikat CA, sertifikat entitas akhir tidak dapat digunakan untuk menerbitkan sertifikat. Istilah umum lainnya untuk sertifikat entitas akhir adalah sertifikat “klien” atau “daun”.
## Sertifikat yang ditandatangani sendiri
Sertifikat yang ditandatangani oleh penerbit, bukan CA yang lebih tinggi. Tidak seperti sertifikat yang dikeluarkan dari akar aman yang dikelola oleh CA, sertifikat yang ditandatangani sendiri bertindak sebagai akar mereka sendiri, dan akibatnya sertifikat tersebut memiliki batasan yang signifikan: Sertifikat tersebut dapat digunakan untuk menyediakan enkripsi kabel tetapi tidak untuk memverifikasi identitas, dan sertifikat tersebut tidak dapat dicabut. Mereka tidak dapat diterima dari perspektif keamanan. Tetapi organisasi tetap menggunakannya karena mudah dibuat, tidak memerlukan keahlian atau infrastruktur, dan banyak aplikasi menerimanya. Tidak ada kontrol untuk menerbitkan sertifikat yang ditandatangani sendiri. Organisasi yang menggunakannya mengalami risiko pemadaman yang lebih besar yang disebabkan oleh masa berlaku sertifikat karena tidak memiliki cara untuk melacak tanggal kedaluwarsa.
## Sertifikat pribadi
AWS Private CA sertifikat adalah SSL/TLS sertifikat pribadi yang dapat Anda gunakan dalam organisasi Anda, tetapi tidak dipercaya di internet publik. Gunakan mereka untuk mengidentifikasi sumber daya seperti klien, server, aplikasi, layanan, perangkat, dan pengguna. Saat membuat saluran komunikasi terenkripsi yang aman, setiap sumber daya menggunakan sertifikat seperti berikut ini serta teknik kriptografi untuk membuktikan identitasnya ke sumber daya lain. Titik akhir API internal, server web, pengguna VPN, perangkat IoT, dan banyak aplikasi lainnya menggunakan sertifikat privat untuk membuat saluran komunikasi terenkripsi yang diperlukan untuk operasi aman mereka. Secara default, sertifikat privat tidak dipercaya secara publik. Administrator internal harus secara eksplisit mengonfigurasi aplikasi untuk memercayai sertifikat privat dan mendistribusikan sertifikat.
```
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
e8:cb:d2:be:db:12:23:29:f9:77:06:bc:fe:c9:90:f8
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=WA, L=Seattle, O=Example Company CA, OU=Corporate, CN=www.example.com
Validity
Not Before: Feb 26 18:39:57 2018 GMT
Not After : Feb 26 19:39:57 2019 GMT
Subject: C=US, ST=Washington, L=Seattle, O=Example Company, OU=Sales, CN=www.example.com/emailAddress=sales@example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00...c7
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
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 Subject Key Identifier:
C6:6B:3C:6F:0A:49:9E:CC:4B:80:B2:8A:AB:81:22:AB:89:A8:DA:19
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://NA/crl/12345678-1234-1234-1234-123456789012.crl
Signature Algorithm: sha256WithRSAEncryption
58:32:...:53
```
## Jalur sertifikat
Klien yang mengandalkan sertifikat memvalidasi bahwa jalur ada dari sertifikat entitas akhir, mungkin melalui rantai sertifikat perantara, ke root tepercaya. Klien memeriksa bahwa setiap sertifikat sepanjang jalur sudah valid (tidak dicabut). Ini juga memeriksa bahwa sertifikat entitas akhir belum kedaluwarsa, memiliki integritas (belum dirusak atau dimodifikasi), dan bahwa kendala dalam sertifikat diberlakukan.
## Kendala panjang jalur
Kendala dasar *pathLenConstraint*untuk sertifikat CA menetapkan jumlah sertifikat CA bawahan yang mungkin ada dalam rantai di bawahnya. Misalnya, sertifikat CA dengan batasan panjang jalur nol tidak dapat memiliki bawahan. CAs CA dengan batasan panjang jalur satu mungkin memiliki hingga satu tingkat bawahan di bawahnya. CAs [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9) mendefinisikan ini sebagai, “jumlah maksimum sertifikat non-self-issued menengah yang dapat mengikuti sertifikat ini di jalur sertifikasi yang valid.” Nilai panjang jalur tidak termasuk sertifikat entitas akhir, meskipun bahasa informal tentang “panjang” atau “kedalaman” rantai validasi dapat menyertakannya... yang menyebabkan kebingungan.