Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
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.
Diagram berikut menunjukkan hubungan antara
komponen Pengelola Sertifikat untuk proxy target standar yang ditentukan dalam
aturan penerusan load balancer:
Entitas Certificate Manager (klik untuk memperbesar).
Untuk mempelajari komponen Pengelola Sertifikat lebih lanjut, lihat Komponen
inti.
Logika pemilihan sertifikat
Pada tingkat tinggi, load balancer memilih sertifikat sebagai berikut:
Klien memulai handshake, yang merupakan permintaan koneksi ke
layanan di balik load balancer.
Selama handshake, klien memberikan daftar algoritma kriptografis yang digunakan klien untuk menyelesaikan handshake, dan, secara opsional, nama host yang coba dijangkau. Nama host ini juga disebut Server Name Indication (SNI).
Saat menerima permintaan, load balancer akan memilih sertifikat untuk menyelesaikan handshake aman.
Kecocokan nama host persis: jika nama host yang diberikan klien sama persis dengan entri nama host dalam peta sertifikat yang disediakan, load balancer akan memilih sertifikat yang sesuai.
Kecocokan nama host karakter pengganti: jika nama host klien tidak cocok dengan salah satu entri nama host dalam peta sertifikat yang disediakan, tetapi cocok dengan nama host karakter pengganti dalam entri peta sertifikat, load balancer akan memilih sertifikat yang sesuai.
Misalnya, entri karakter pengganti yang dikonfigurasi sebagai *.myorg.example.com mencakup subdomain level pertama di domain myorg.example.com. Entri karakter pengganti tidak mencakup subdomain tingkat yang lebih dalam, seperti sub.subdomain.myorg.example.com.
Tidak ada kecocokan nama host yang sama persis atau yang menggunakan karakter pengganti: jika nama host klien tidak cocok dengan salah satu entri nama host dalam peta sertifikat yang disediakan, load balancer akan memilih entri peta sertifikat utama.
Kegagalan handshake: jika klien tidak memberikan nama host dan
entri peta sertifikat utama tidak dikonfigurasi, handshake akan gagal.
Prioritas sertifikat
Saat memilih sertifikat, load balancer akan memprioritaskannya berdasarkan
faktor berikut:
Jenis sertifikat. Jika klien mendukung sertifikat ECDSA, load balancer akan memprioritaskannya daripada sertifikat RSA. Jika klien tidak
mendukung sertifikat ECDSA, load balancer akan menyalurkan sertifikat
RSA.
Ukuran sertifikat. Karena sertifikat yang lebih kecil memerlukan lebih sedikit bandwidth, load balancer akan memprioritaskan sertifikat yang lebih kecil daripada yang lebih besar.
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 selalu memilih entri untuk
www.myorg.example.com meskipun entri untuk *.myorg.example.com juga
ada.
Nama domain karakter pengganti hanya cocok dengan subdomain tingkat pertama. Misalnya,
permintaan koneksi untuk host1.myorg.example.com memilih entri peta
sertifikat untuk *.myorg.example.com, tetapi tidak untuk
host1.hosts.myorg.example.com.
Perpanjangan sertifikat
Sertifikat yang dikelola Google diperpanjang secara otomatis. Anda harus memperpanjang
sertifikat yang dikelola sendiri secara manual. Jika perlu, Anda dapat mengonfigurasi pemberitahuan Cloud Logging untuk sertifikat sebelum masa berlakunya berakhir. Untuk informasi
selengkapnya, lihat Mengonfigurasi pemberitahuan log.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-08-19 UTC."],[[["\u003cp\u003eCertificate Manager provides granular control over certificate assignment and serving for each domain name.\u003c/p\u003e\n"],["\u003cp\u003eThe load balancer selects certificates based on exact hostname match, wildcard hostname match, or the primary certificate map entry if no matches are found.\u003c/p\u003e\n"],["\u003cp\u003eThe load balancer prioritizes certificates based on type (ECDSA over RSA) and size (smaller certificates are preferred).\u003c/p\u003e\n"],["\u003cp\u003eWildcard domain names in Google-managed certificates with DNS or CA Service authorization only match the first level of subdomains, and exact matches take precedence over wildcards.\u003c/p\u003e\n"],["\u003cp\u003eGoogle-managed certificates are renewed automatically, while self-managed certificates require manual renewal.\u003c/p\u003e\n"]]],[],null,["# How Certificate Manager works\n\nCertificate Manager uses a flexible mapping mechanism that provides you\nwith granular control over which certificates you can assign and how to serve\nthem for each domain name in your environment.\n\nThe following diagram shows the relationships between\nCertificate Manager components for a typical target proxy specified in\na load balancer forwarding rule:\n[](/static/certificate-manager/images/cm-entities.svg) Certificate Manager entities (click to enlarge).\n\nTo learn more about the components of Certificate Manager, see [Core\ncomponents](/certificate-manager/docs/how-it-works).\n\nCertificate selection logic\n---------------------------\n\nAt a high level, the load balancer selects a certificate as follows:\n\n1. A client initiates a handshake, which is a connection request to the\n service behind the load balancer.\n\n During the handshake, the client provides the load balancer a list of\n cryptographic algorithms that the client uses to complete the\n handshake, and, optionally, the hostname it is trying to reach. This\n hostname is also called Server Name Indication (SNI).\n2. On receiving the request, the load balancer selects a certificate to\n complete the secure handshake.\n\n - **Exact hostname match**: if the client's provided hostname exactly\n matches a hostname entry in the provisioned certificate map, the load\n balancer selects the corresponding certificate.\n\n - **Wildcard hostname match**: if the client's hostname doesn't match any\n one of the hostname entries in the provisioned certificate map, but\n does match a wildcard hostname in a certificate map entry, the load\n balancer selects the corresponding certificate.\n\n For example, a wildcard entry configured as `*.myorg.example.com` covers\n first-level subdomains in the `myorg.example.com` domain. The wildcard\n entry doesn't cover deeper level subdomains, such as\n `sub.subdomain.myorg.example.com`.\n - **No exact or wildcard hostname match**: if the client's hostname\n doesn't match any one of the hostname entries in the provisioned\n certificate map, the load balancer selects the primary certificate map\n entry.\n\n - **Handshake failure**: if the client didn't provide a hostname and the\n primary certificate map entry isn't configured, the handshake fails.\n\n| **Note:** A Google-managed certificate must complete provisioning before the load balancer can serve the certificate.\n\n### Certificate priority\n\nWhen selecting a certificate, the load balancer prioritizes them based on the\nfollowing factors:\n\n- **Certificate type**. If the client supports the ECDSA certificates, the load balancer prioritizes them over RSA certificates. If the client doesn't support ECDSA certificates, the load balancer serves an RSA certificate instead.\n- **Certificate size**. Because smaller certificates take less bandwidth, the load balancer prioritizes smaller certificates over larger ones.\n\n### Wildcard domain names\n\nThe following rules apply to wildcard domain names:\n\n- Only Google-managed certificates with DNS authorization and Google-managed certificates with CA Service support wildcard domain names. Google-managed certificates with load balancer authorization don't support wildcard domain names.\n- An exact match takes precedence over a wildcard when both are defined in the entry. For example, if you configured certificate map entries for `www.myorg.example.com` and `*.myorg.example.com`, a connection request against `www.myorg.example.com` always selects the entry for `www.myorg.example.com` even if an entry for `*.myorg.example.com`also exists.\n- Wildcard domain names only match the first level of subdomains. For example, a connection request for `host1.myorg.example.com` selects a certificate map entry for `*.myorg.example.com` but not one for `host1.hosts.myorg.example.com`.\n\nCertificate renewal\n-------------------\n\nGoogle-managed certificates are renewed automatically. You must renew\nself-managed certificates manually. If necessary, you can configure\nCloud Logging alerts for certificates before they expire. For more\ninformation, see [Configure log\nalerts](/certificate-manager/docs/logs-metrics#configure_log_alerts).\n\nWhat's next\n-----------\n\n- [Domain authorization types for Google-managed certificates](/certificate-manager/docs/domain-authorization)"]]
