Pengelola Sertifikat menggunakan mekanisme pemetaan fleksibel yang memberi Anda kontrol terperinci atas sertifikat yang dapat Anda tetapkan dan cara menayangkannya untuk setiap nama domain di lingkungan Anda. Mekanisme ini mencakup entitas berikut:
- Sertifikat
- Peta sertifikat
- Entri peta sertifikat
- Otorisasi domain
Diagram berikut menggambarkan hubungan antara entity ini untuk proxy target standar yang ditentukan dalam aturan penerusan load balancer:
Pengelola Sertifikat mendukung proxy HTTPS target dan proxy SSL target. Untuk informasi selengkapnya tentang perbedaan antara jenis proxy ini, lihat Menggunakan proxy target.
Untuk informasi tentang jenis sertifikat yang didukung Pengelola Sertifikat, lihat Ringkasan deployment.
Sertifikat
Secara default, sertifikat mewakili satu sertifikat Transport Layer Security (TLS) (SSL) X.509 yang dikeluarkan untuk nama domain atau karakter pengganti domain tertentu.
Pengelola Sertifikat mendukung jenis sertifikat berikut:
- Sertifikat yang dikelola Google adalah sertifikat yang diperoleh dan dikelola oleh Google Clouduntuk Anda.
- Sertifikat yang dikelola sendiri adalah sertifikat yang Anda peroleh, sediakan, dan perpanjang sendiri.
Saat Anda menerbitkan sertifikat menggunakan CA tepercaya publik, CA akan memublikasikan informasi tentang domain terkait ke log Transparansi Sertifikat, yang dapat diakses secara publik. Ini adalah bagian dari proses penerbitan sertifikat standar yang diadopsi oleh semua CA tepercaya publik, dan berlaku untuk sertifikat yang dikelola Google dan sertifikat yang dikelola sendiri. Namun, jika Anda menggunakan Certificate Authority Service untuk menerbitkan sertifikat yang dikelola Google, Pengelola Sertifikat tidak memublikasikan informasi apa pun ke log Transparansi Sertifikat.
Untuk mengetahui informasi selengkapnya, lihat Transparansi Sertifikat.
Untuk mempelajari cara men-deploy sertifikat dengan Pengelola Sertifikat, lihat Ringkasan deployment.
Sertifikat yang dikelola Google
Mengelola sertifikat TLS (SSL) yang dikelola Google untuk situs dan aplikasi Anda dapat menjadi tugas yang kompleks dan memakan waktu, yang sering kali melibatkan konfigurasi manual dan pemeliharaan rutin. Pengelola Sertifikat adalah layanan yang dirancang untuk membantu Anda menyederhanakan proses ini dengan menyediakan platform terpusat. Anda dapat mendelegasikan tanggung jawab penerbitan dan perpanjangan sertifikat ke Pengelola Sertifikat, sehingga Anda dapat menghemat waktu untuk berfokus pada tugas penting lainnya.
Anda dapat memverifikasi kepemilikan domain yang relevan menggunakan otorisasi berbasis load balancer atau DNS. Certificate Manager mendukung sertifikat RSA yang dikelola Google.
Secara default, CA Google menerbitkan sertifikat yang dikelola Google. Saat sertifikat baru yang dikelola Google dikeluarkan atau diperpanjang, sertifikat tersebut akan menggunakan kunci pribadi yang baru dibuat. Jika Anda tidak dapat memperoleh sertifikat dari CA Google untuk domain tertentu, Pengelola Sertifikat akan kembali ke CA Let's Encrypt. Misalnya, CA Google mungkin menolak untuk menerbitkan sertifikat untuk domain, atau data Otorisasi CA Anda secara eksplisit melarang CA Google menerbitkan sertifikat untuk domain tersebut.
Autentikasi khusus sisi klien tidak didukung.
Untuk petunjuk tentang cara membatasi CA yang dapat menerbitkan sertifikat untuk domain Anda, lihat Menentukan CA yang dapat menerbitkan sertifikat yang dikelola Google.
Perhatikan bahwa sertifikat yang dikelola Google secara regional hanya mendukung otorisasi berbasis DNS dan mendapatkan sertifikat dari CA Google.
Sertifikat yang dikelola Google dan dikeluarkan oleh Certificate Authority Service
Jika ingin menggunakan rantai kepercayaan Anda sendiri, bukan mengandalkan CA publik yang disetujui Google untuk menerbitkan sertifikat, Anda dapat mengonfigurasi Pengelola Sertifikat untuk menggunakan kumpulan CA dari Certificate Authority Service sebagai penerbit sertifikat. Untuk informasi selengkapnya tentang kumpulan CA, lihat Membuat Kumpulan CA.
Sertifikat yang dikelola sendiri
Jika persyaratan bisnis Anda tidak mengizinkan Anda menggunakan sertifikat yang dikelola Google, Anda dapat mengupload sertifikat yang dikeluarkan oleh CA eksternal beserta kunci terkaitnya. Anda bertanggung jawab untuk menerbitkan dan memperpanjang sertifikat yang dikelola sendiri secara manual.
Certificate Manager juga memungkinkan Anda men-deploy sertifikat yang dikelola sendiri secara regional di proxy Secure Web Proxy dan load balancer regional.
Peta sertifikat
Peta sertifikat mereferensikan satu atau beberapa entri peta sertifikat yang menetapkan sertifikat tertentu ke nama host tertentu. Entri peta sertifikat juga menentukan logika pemilihan yang diikuti load balancer saat membuat koneksi klien. Anda dapat mengaitkan peta sertifikat dengan beberapa proxy target untuk digunakan kembali di beberapa load balancer.
Jika klien meminta nama host yang ditentukan dalam peta sertifikat, load balancer akan menayangkan sertifikat yang dipetakan ke nama host tersebut. Jika tidak, load balancer akan menayangkan sertifikat utama. Untuk informasi selengkapnya, lihat Logika pemilihan sertifikat.
Entri peta sertifikat
Entri peta sertifikat adalah daftar sertifikat yang ditayangkan untuk nama domain tertentu. Anda dapat menentukan kumpulan sertifikat yang berbeda untuk nama domain yang berbeda, seperti domain atau subdomain. Misalnya, Anda dapat mengupload sertifikat ECDSA dan RSA, lalu memetakan keduanya ke nama domain yang sama. Saat klien terhubung ke nama domain tersebut, load balancer akan menegosiasikan jenis sertifikat yang akan ditayangkan kepada klien selama handshake.
Otorisasi domain
Pengelola Sertifikat memungkinkan Anda membuktikan kepemilikan domain yang sertifikatnya ingin Anda terbitkan dan dikelola Google seperti yang dijelaskan dalam tabel berikut.
| Otorisasi load balancer | Otorisasi DNS | |
|---|---|---|
| Kompleksitas penyiapan | Tidak memerlukan langkah konfigurasi tambahan atau perubahan pada konfigurasi DNS Anda. | Memerlukan Anda untuk membuat otorisasi DNS dan menambahkan data CNAME yang sesuai ke konfigurasi DNS. |
| Keamanan jaringan | Load balancer harus dapat diakses sepenuhnya dari internet di port 443, termasuk konfigurasi DNS untuk semua domain yang ditayangkan oleh sertifikat. Tidak berfungsi dengan konfigurasi lain. | Berfungsi dengan konfigurasi yang kompleks, seperti port selain 443 dan lapisan CDN di depan proxy target. |
| Kecepatan penyediaan | Anda hanya dapat menyediakan sertifikat setelah load balancer sepenuhnya disiapkan dan menyalurkan traffic jaringan. | Anda dapat menyediakan sertifikat terlebih dahulu, sebelum proxy target siap menyalurkan traffic jaringan. |
Untuk memahami cara Certificate Manager memverifikasi kepemilikan domain dengan menggunakan setiap metode, lihat Otorisasi domain untuk sertifikat yang dikelola Google.
Konfigurasi penerbitan sertifikat
Konfigurasi penerbitan sertifikat adalah resource yang memungkinkan Pengelola Sertifikat menggunakan kumpulan CA dari instance Certificate Authority Service Anda sendiri untuk menerbitkan sertifikat yang dikelola Google, bukan CA Google atau CA Let's Encrypt. Dengan cara ini, Anda dapat menentukan sejumlah parameter yang mengatur penerbitan dan masa berlaku sertifikat serta memilih algoritma kunci untuk sertifikat yang diterbitkan dengan cara ini.
Konfigurasi tepercaya
Konfigurasi kepercayaan adalah resource yang mewakili konfigurasi Infrastruktur Kunci Publik (PKI) Anda di Pengelola Sertifikat untuk digunakan dalam skenario autentikasi TLS bersama. File ini mengenkapsulasi satu penyimpanan kepercayaan, yang pada gilirannya mengenkapsulasi anchor kepercayaan dan, secara opsional, satu atau beberapa sertifikat perantara.
Untuk mempelajari autentikasi TLS bersama lebih lanjut, lihat Autentikasi TLS bersama dalam dokumentasi Cloud Load Balancing.
Resource konfigurasi kepercayaan mengenkapsulasi entitas penyimpanan kepercayaan, anchor kepercayaan, dan sertifikat antara.
Trust store
Trust store mewakili konfigurasi secret kepercayaan di Pengelola Sertifikat untuk digunakan dalam skenario autentikasi TLS timbal balik. File ini mengenkapsulasi satu anchor kepercayaan dan, secara opsional, satu atau beberapa sertifikat perantara.
Trust anchor
Anchor kepercayaan mewakili satu sertifikat root untuk digunakan dalam skenario autentikasi TLS bersama. Keystore dienkapsulasi dalam trust store.
Intermediate certificate
Sertifikat perantara mewakili satu sertifikat perantara yang ditandatangani oleh sertifikat root atau sertifikat perantara yang dirujuk dalam trust store enkapsulasi untuk digunakan dalam skenario autentikasi TLS bersama.
Satu atau beberapa intermediate certificate dapat dienkapsulasi dalam trust store, bergantung pada konfigurasi PKI Anda. Semua sertifikat perantara yang ditentukan dalam konfigurasi kepercayaan disertakan sebagai bagian dari evaluasi kepercayaan untuk setiap permintaan koneksi selain daftar sertifikat perantara yang ditentukan dalam permintaan itu sendiri.
Sertifikat yang memerlukan daftar yang disetujui
Secara opsional, jika Anda perlu menggunakan sertifikat yang telah ditandatangani sendiri, telah
berakhir masa berlakunya, atau tidak valid, atau jika Anda tidak memiliki akses ke root certificate dan
sertifikat perantara, Anda dapat menambahkan sertifikat tersebut ke konfigurasi kepercayaan di
kolom allowlistedCertificates. Anda tidak memerlukan trust store untuk menambahkan
sertifikat ke daftar yang diizinkan.
Menambahkan sertifikat ke daftar yang diizinkan berarti sertifikat tersebut selalu dianggap valid selama sertifikat dapat diuraikan, bukti kepemilikan kunci pribadi ditetapkan, dan batasan pada kolom SAN sertifikat terpenuhi.
Logika pemilihan sertifikat
Pada tingkat tinggi, load balancer memilih sertifikat sebagai berikut:
- Klien memulai handshake. Selama langkah ini, load balancer menyediakan daftar algoritma kriptografi yang dapat digunakan untuk menyelesaikan handshake, dan, secara opsional, nama host.
Load balancer memilih sertifikat untuk menyelesaikan handshake aman berdasarkan nama host yang diberikan klien dan entri peta sertifikat yang dikonfigurasi. Faktor yang menentukan sertifikat mana yang dipilih load balancer adalah sebagai berikut:
Kecocokan nama host persis: Jika klien memberikan nama host yang sama persis dengan entri dalam peta sertifikat yang disediakan, load balancer akan memilih sertifikat yang sesuai.
Kecocokan nama host karakter pengganti: Jika nama host klien tidak cocok dengan entri apa pun, tetapi cocok dengan nama host karakter pengganti dalam entri peta sertifikat, load balancer akan memilih sertifikat yang sesuai dari entri tersebut. Misalnya, entri karakter pengganti yang dikonfigurasi sebagai
*.myorg.example.commencakup subdomain tingkat pertama di bawah domainmyorg.example.com.Tidak ada pencocokan nama host dan entri peta sertifikat utama yang telah dikonfigurasi sebelumnya: Load balancer memilih entri peta sertifikat utama yang telah dikonfigurasi sebelumnya jika tidak ada pencocokan nama host atau entri peta sertifikat yang disediakan yang cocok.
Kegagalan handshake: Handshake gagal jika load balancer tidak dapat menemukan sertifikat yang cocok karena alasan berikut:
- Klien memberikan nama host yang tidak cocok dengan nama host persis atau karakter pengganti yang ditentukan di semua entri peta sertifikat yang disediakan, atau tidak memberikan nama host sama sekali.
- Entri peta sertifikat utama yang cocok tidak ditemukan, atau jika Anda belum mengonfigurasi entri peta sertifikat utama.
Prioritas sertifikat
Load balancer memilih sertifikat dalam entri peta sertifikat berdasarkan hal berikut:
- Jenis sertifikat. Jika klien yang terhubung mendukung sertifikat ECDSA yang lebih aman, load balancer akan memprioritaskannya daripada sertifikat RSA. Jika klien tidak menunjukkan dukungan untuk sertifikat ECDSA, load balancer akan menyalurkan sertifikat RSA.
- Ukuran sertifikat. Load balancer memprioritaskan sertifikat dari yang terkecil ke yang terbesar.
Nama domain karakter pengganti
Aturan berikut berlaku untuk nama domain karakter pengganti:
- Hanya sertifikat yang dikelola Google dengan otorisasi DNS dan sertifikat yang dikelola Google dengan Layanan CA yang mendukung nama domain karakter pengganti. Sertifikat yang dikelola Google dengan otorisasi load balancer tidak mendukung nama domain karakter pengganti.
- Pencocokan persis lebih diutamakan daripada karakter pengganti jika keduanya ditentukan dalam
entri. Misalnya, jika Anda mengonfigurasi entri peta sertifikat untuk
www.myorg.example.comdan*.myorg.example.com, permintaan koneksi terhadapwww.myorg.example.comselalu memilih entri untukwww.myorg.example.commeskipun entri untuk*.myorg.example.comjuga ada. - Nama domain karakter pengganti hanya cocok hingga satu tingkat subdomain. Misalnya,
permintaan koneksi untuk
host1.myorg.example.commemilih entri peta sertifikat untuk*.myorg.example.com, tetapi tidak untukhost1.hosts.myorg.example.com.
Public CA
Untuk menggunakan fitur CA publik Pengelola Sertifikat, Anda harus memahami konsep berikut:
Klien ACME. Klien Automatic Certificate Management Environment (ACME) adalah klien pengelolaan sertifikat yang menggunakan protokol ACME. Klien ACME Anda harus mendukung external account binding (EAB) agar dapat berfungsi dengan CA Publik.
External account binding (EAB). Anda harus mengikat setiap akun ACME yang Anda gunakan dengan CA publik Pengelola Sertifikat ke project Google Cloud target menggunakan binding akun eksternal. Untuk melakukannya, Anda harus mendaftarkan setiap akun ACME menggunakan secret yang ditautkan ke project Google Cloud yang sesuai. Untuk informasi selengkapnya, lihat Penautan akun eksternal.
Tantangan CA publik
Saat Anda menggunakan Public CA untuk meminta sertifikat, Pengelola Sertifikat akan meminta Anda untuk membuktikan kontrol Anda atas domain yang tercantum dalam sertifikat tersebut. Anda dapat membuktikan kontrol domain dengan menyelesaikan tantangan. CA publik memberikan otorisasi nama domain setelah Anda membuktikan kontrol atas domain target.
Setelah mendapatkan otorisasi yang diperlukan, Anda dapat meminta sertifikat yang hanya berlaku untuk durasi waktu tertentu. Setelah durasi ini, Anda harus memvalidasi ulang nama domain dengan menyelesaikan salah satu dari tiga jenis verifikasi untuk terus meminta sertifikat.
Jenis verifikasi login
CA publik mendukung jenis tantangan berikut:
Tantangan HTTP. Tantangan ini melibatkan pembuatan file di lokasi terkenal di server HTTP (port 80) agar CA Publik dapat mengambil dan memverifikasinya. Untuk mengetahui informasi selengkapnya, lihat Tantangan HTTP.
Tantangan TLS-Application Layer Protocol Negotiation (ALPN). Mewajibkan server untuk memberikan sertifikat tertentu selama negosiasi TLS di port 443 untuk membuktikan kontrol atas domain. Untuk mengetahui informasi selengkapnya, lihat Ekstensi tantangan TLS-ALPN ACME.
Tantangan DNS. Memerlukan penambahan data DNS tertentu di lokasi yang ditentukan untuk membuktikan kontrol atas domain. Untuk mengetahui informasi selengkapnya, lihat Tantangan DNS.
Jika Anda menggunakan tantangan HTTP atau tantangan TLS-ALPN untuk memvalidasi nama domain, klien hanya dapat meminta nama domain yang divalidasi untuk disertakan dalam sertifikat. Jika Anda menggunakan tantangan DNS, klien juga dapat meminta subdomain nama domain tersebut untuk disertakan dalam sertifikat.
Misalnya, jika Anda memvalidasi *.myorg.example.com menggunakan tantangan DNS, maka
subdomain1.myorg.example.com dan subdomain2.myorg.example.com akan otomatis tercakup
oleh sertifikat karakter pengganti. Namun, jika Anda memvalidasi myorg.example.com menggunakan tantangan HTTP atau TLS-ALPN, klien hanya dapat meminta untuk menyertakan myorg.example.com dalam sertifikat dan Anda tidak dapat memvalidasi *.myorg.example.com menggunakan tantangan non-DNS.
Logika solusi tantangan
Logika tantangan CA publik adalah sebagai berikut:
- CA publik memberikan token acak.
- Klien menyediakan token di lokasi yang ditentukan dengan baik. Lokasi bergantung pada tantangan.
- Klien menunjukkan kepada CA Publik bahwa klien telah menyiapkan tantangan.
- CA publik memeriksa apakah token yang ada di lokasi yang diharapkan cocok dengan nilai yang diharapkan.
Nama domain akan diberi otorisasi setelah proses ini selesai. Klien dapat meminta sertifikat dengan nama domain tersebut. Anda hanya perlu menyelesaikan satu tantangan per nama domain.