Cara kerja Certificate Manager

Certificate Manager menggunakan mekanisme pemetaan fleksibel yang memberi Anda kontrol terperinci atas sertifikat yang dapat ditetapkan dan cara menayangkannya untuk setiap nama domain di lingkungan Anda. Mekanismenya mencakup entity berikut:

• Sertifikat
• Peta sertifikat
• Entri peta sertifikat
• Otorisasi domain

Diagram berikut mengilustrasikan hubungan antara entity ini untuk proxy target standar yang ditentukan dalam aturan penerusan load balancer:

Entitas Certificate Manager (klik untuk memperbesar).

Pengelola Sertifikat mendukung proxy HTTPS target dan proxy SSL target. Untuk mengetahui informasi selengkapnya tentang perbedaan antara jenis proxy ini, lihat Menggunakan proxy target.

Dengan menggunakan Pengelola Sertifikat, Anda dapat melampirkan sertifikat dengan cara berikut:

• Jika Anda men-deploy sertifikat ke Load Balancer Aplikasi eksternal global, gunakan peta sertifikat yang dilampirkan ke proxy target dan entri peta sertifikat. Untuk informasi selengkapnya, lihat Men-deploy sertifikat global yang dikelola sendiri.
• Jika Anda men-deploy sertifikat ke Load Balancer Aplikasi eksternal regional, Load Balancer Aplikasi internal regional, atau gateway Proxy Web Aman, lampirkan sertifikat secara langsung ke proxy target atau gateway Proxy Web Aman. Untuk informasi selengkapnya, lihat Men-deploy sertifikat regional yang dikelola sendiri.
• Jika Anda men-deploy sertifikat ke Load Balancer Aplikasi internal lintas region, lampirkan sertifikat dengan cakupan ALL_REGIONS langsung ke proxy target. Load Balancer Aplikasi internal lintas region tidak mendukung sertifikat yang dikelola Google dengan otorisasi load balancer. Namun, layanan tersebut mendukung otorisasi DNS dan otorisasi Certificate Authority Service.

Sertifikat

Secara default, sertifikat mewakili satu sertifikat Transport Layer Security (TLS) (SSL) X.509 yang diterbitkan 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 Cloud untuk Anda.
• Sertifikat yang dikelola sendiri adalah sertifikat yang Anda peroleh, sediakan, dan perpanjang sendiri.

Jika Anda menerbitkan sertifikat menggunakan CA yang dipercaya secara 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 digunakan oleh semua CA yang dipercaya secara 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, Certificate Manager tidak akan memublikasikan informasi apa pun ke log Transparansi Sertifikat.

Untuk informasi selengkapnya, lihat Transparansi Sertifikat.

Untuk mempelajari cara men-deploy sertifikat dengan Certificate Manager, 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 dapat meluangkan waktu untuk berfokus pada tugas penting lainnya.

Anda dapat memverifikasi kepemilikan domain yang relevan menggunakan otorisasi berbasis load balancer atau DNS. {i>Certificate Manager<i} mendukung sertifikat RSA yang dikelola Google.

Secara default, CA Google menerbitkan sertifikat yang dikelola Google. Ketika sertifikat yang Dikelola Google baru diterbitkan atau diperpanjang, sertifikat tersebut akan menggunakan kunci pribadi yang baru dibuat. Jika Anda tidak bisa mendapatkan sertifikat dari CA Google untuk domain tertentu, Certificate Manager akan kembali ke CA Let's Encrypt. Misalnya, CA Google mungkin menolak menerbitkan sertifikat untuk domain, atau data Otorisasi CA Anda secara eksplisit melarang CA Google menerbitkan sertifikat untuk domain tersebut.

Autentikasi hanya untuk 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 regional yang dikelola Google (Pratinjau) hanya mendukung otorisasi berbasis DNS dan mendapatkan sertifikat dari CA Google.

Sertifikat yang dikelola Google yang diterbitkan oleh Certificate Authority Service

Jika ingin menggunakan rantai kepercayaan Anda sendiri, bukan mengandalkan CA publik yang disetujui Google untuk menerbitkan sertifikat, Anda dapat mengonfigurasi Certificate Manager 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 tidak mengizinkan Anda menggunakan sertifikat yang dikelola Google, Anda dapat mengupload sertifikat yang diterbitkan oleh CA eksternal beserta kuncinya yang terkait. Anda bertanggung jawab untuk menerbitkan dan memperpanjang sertifikat yang dikelola sendiri secara manual.

Dengan Pengelola Sertifikat, Anda dapat men-deploy sertifikat regional yang dikelola sendiri di proxy Secure Web Proxy dan load balancer regional.

Peta sertifikat

Peta sertifikat merujuk pada 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 ECDSA dan sertifikat RSA, lalu memetakannya ke nama domain yang sama. Saat klien terhubung ke nama domain tersebut, load balancer menegosiasikan jenis sertifikat yang akan ditayangkan ke klien selama handshake.

Otorisasi domain

Pengelola Sertifikat memungkinkan Anda membuktikan kepemilikan domain tempat Anda ingin menerbitkan sertifikat yang dikelola Google seperti dijelaskan dalam tabel berikut.

	Otorisasi load balancer	Otorisasi DNS
Kompleksitas penyiapan	Tidak memerlukan langkah konfigurasi tambahan atau perubahan pada konfigurasi DNS Anda.	Mengharuskan Anda untuk membuat otorisasi DNS dan menambahkan data CNAME yang sesuai ke konfigurasi DNS Anda.
Keamanan jaringan	Load balancer harus dapat diakses sepenuhnya dari internet di port 443, termasuk konfigurasi DNS untuk semua domain yang disalurkan oleh sertifikat. Tidak berfungsi dengan konfigurasi lain.	Berfungsi dengan konfigurasi kompleksitas tinggi, seperti port selain 443 dan lapisan CDN di depan proxy target.
Kecepatan penyediaan	Anda hanya dapat menyediakan sertifikat setelah load balancer disiapkan sepenuhnya dan menyalurkan traffic jaringan.	Anda dapat menyediakan sertifikat di muka, sebelum proxy target siap menyalurkan traffic jaringan.

Untuk memahami cara Pengelola Sertifikat memverifikasi kepemilikan domain 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 Let's Encrypt. Hal ini memungkinkan Anda menentukan sejumlah parameter yang mengatur penerbitan dan masa berlaku sertifikat serta memilih algoritma kunci untuk sertifikat yang diterbitkan dengan cara ini.

Konfigurasi kepercayaan

Konfigurasi kepercayaan adalah resource yang mewakili konfigurasi Infrastruktur Kunci Publik (PKI) Anda di Pengelola Sertifikat untuk digunakan dalam skenario autentikasi TLS bersama. Layanan ini mengenkapsulasi satu trust store, yang kemudian mengenkapsulasi trust anchor dan, secara opsional, satu atau beberapa sertifikat perantara.

Untuk mempelajari lebih lanjut autentikasi TLS bersama, lihat Autentikasi TLS bersama dalam dokumentasi Cloud Load Balancing.

Resource konfigurasi kepercayaan mengenkapsulasi penyimpanan trust, trust anchor, dan entity sertifikat intermediate.

Trust store

Trust store mewakili konfigurasi rahasia kepercayaan di Pengelola Sertifikat untuk digunakan dalam skenario autentikasi TLS bersama. Alat ini mengenkapsulasi satu trust anchor dan, secara opsional, satu atau beberapa sertifikat perantara.

Anchor kepercayaan

Trust anchor mewakili satu root certificate untuk digunakan dalam skenario autentikasi TLS bersama. Dienkapsulasi di dalam trust store.

Intermediate certificate

Sertifikat perantara mewakili satu sertifikat perantara yang ditandatangani oleh root certificate atau sertifikat perantara yang dirujuk dalam penyimpanan trust yang dienkapsulasi untuk digunakan dalam skenario autentikasi TLS bersama.

Satu atau beberapa sertifikat perantara dapat dienkapsulasi dalam trust store, bergantung pada konfigurasi IKP 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 diizinkan

Sertifikat yang diizinkan mewakili semua sertifikat yang dapat dienkapsulasi dalam konfigurasi kepercayaan sehingga selalu dianggap valid. Sertifikat yang diizinkan selalu dianggap valid selama sertifikat dapat diuraikan, bukti kepemilikan kunci pribadi dibuat, dan batasan pada kolom SAN sertifikat terpenuhi. Sertifikat yang habis masa berlakunya juga dianggap valid jika diizinkan. Anda tidak memerlukan trust store saat menggunakan sertifikat yang diizinkan.

Logika pemilihan sertifikat

Pada level yang tinggi, load balancer memilih sertifikat sebagai berikut:

1. Klien memulai handshake. Selama langkah ini, load balancer akan memberikan daftar algoritma kriptografis yang dapat digunakan untuk menyelesaikan handshake, dan, secara opsional, nama host.

2. Load balancer memilih sertifikat untuk menyelesaikan handshake aman berdasarkan nama host yang diberikan klien dan entri peta sertifikat yang dikonfigurasi. Faktor-faktor yang menentukan sertifikat yang dipilih load balancer adalah sebagai berikut:

   • Pencocokan nama host yang 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 di entri peta sertifikat, load balancer akan memilih sertifikat yang sesuai dari entri tersebut. Misalnya, entri karakter pengganti yang dikonfigurasi sebagai *.myorg.example.com mencakup subdomain level pertama di domain myorg.example.com.

   • Tidak ada kecocokan nama host dan entri peta sertifikat utama yang telah dikonfigurasi sebelumnya: Load balancer memilih entri peta sertifikat utama yang telah dikonfigurasi sebelumnya jika nama host tidak cocok atau entri peta sertifikat yang disediakan yang cocok.

   • Kegagalan guncangan tangan: 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 dalam 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.

Catatan: Sertifikat yang dikelola Google harus menyelesaikan penyediaan sebelum load balancer dapat menayangkannya.

Prioritas sertifikat

Load balancer akan 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 menayangkan sertifikat RSA.
• Ukuran sertifikat. Load balancer memprioritaskan sertifikat dari yang terkecil hingga 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.com dan *.myorg.example.com, permintaan koneksi terhadap www.myorg.example.com akan selalu memilih entri untuk www.myorg.example.com meskipun entri untuk *.myorg.example.com juga ada.
• Nama domain karakter pengganti hanya cocok hingga ke satu tingkat subdomain. Misalnya, permintaan koneksi untuk host1.myorg.example.com akan memilih entri peta sertifikat untuk *.myorg.example.com, tetapi tidak akan memilih entri untuk host1.hosts.myorg.example.com.

CA Publik

Untuk menggunakan fitur CA publik pada Certificate Manager, 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 binding akun eksternal (EAB) agar dapat berfungsi dengan CA Publik.

• Binding akun eksternal (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 terkait. Untuk mengetahui informasi selengkapnya, lihat Binding akun eksternal.

Tantangan CA publik

Saat Anda menggunakan CA Publik untuk meminta sertifikat, Certificate Manager akan meminta Anda membuktikan kontrol Anda atas domain yang tercantum dalam sertifikat tersebut. Anda dapat membuktikan kontrol domain dengan menyelesaikan tantangan. CA publik mengotorisasi nama domain setelah Anda membuktikan kontrol Anda atas domain target.

Setelah mendapatkan otorisasi yang diperlukan, Anda dapat meminta sertifikat yang hanya valid untuk durasi waktu tertentu. Setelah durasi ini, Anda harus memvalidasi ulang nama domain dengan menyelesaikan salah satu dari tiga jenis verifikasi login untuk terus meminta sertifikat.

Jenis verifikasi login

CA publik mendukung jenis tantangan berikut:

• Tantangan HTTP. Tantangan ini melibatkan pembuatan file di lokasi yang terkenal pada server HTTP (port 80) agar diambil dan diverifikasi oleh CA Publik. Untuk informasi selengkapnya, lihat verifikasi HTTP.

• Tantangan TLS-Application Layer Protocol (ALPN). Mewajibkan server memberikan sertifikat khusus selama negosiasi TLS di port 443 untuk membuktikan kontrol atas domain. Untuk mengetahui informasi selengkapnya, lihat ekstensi verifikasi login ACME TLS-ALPN.

• Tantangan DNS. Memerlukan penambahan data DNS tertentu di lokasi yang ditentukan untuk membuktikan kontrol atas domain. Untuk informasi selengkapnya, lihat Tantangan DNS.

Jika Anda menggunakan verifikasi login HTTP atau verifikasi TLS-ALPN untuk memvalidasi nama domain, klien hanya dapat meminta nama domain yang divalidasi untuk disertakan dalam sertifikat. Jika Anda menggunakan verifikasi login DNS, klien juga dapat meminta subdomain dari nama domain tersebut agar disertakan dalam sertifikat.

Misalnya, jika Anda memvalidasi *.myorg.example.com menggunakan verifikasi DNS, subdomain1.myorg.example.com dan subdomain2.myorg.example.com akan otomatis dicakup oleh sertifikat karakter pengganti. Namun, jika Anda memvalidasi myorg.example.com menggunakan verifikasi login HTTP atau TLS, klien hanya dapat meminta untuk menyertakan myorg.example.com dalam sertifikat dan Anda tidak dapat memvalidasi *.myorg.example.com menggunakan verifikasi non-DNS.

Logika solusi tantangan

Logika tantangan CA publik adalah sebagai berikut:

1. CA publik memberikan token acak.
2. Klien membuat token tersedia di lokasi yang didefinisikan dengan baik. Lokasi bergantung pada tantangan.
3. Klien menunjukkan kepada Public CA bahwa ia telah menyiapkan tantangan.
4. CA Publik memeriksa apakah token yang ada di lokasi yang diharapkan cocok dengan nilai yang diharapkan.

Nama domain akan diotorisasi setelah proses ini selesai. Klien dapat meminta sertifikat yang berisi nama domain tersebut. Anda hanya perlu menyelesaikan satu tantangan per nama domain.