Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Certificate Manager verwendet einen flexiblen Zuordnungsmechanismus, mit dem Sie genau festlegen können, welche Zertifikate Sie für jeden Domainnamen in Ihrer Umgebung zuweisen und wie sie bereitgestellt werden sollen.
Das folgende Diagramm zeigt die Beziehungen zwischen den Certificate Manager-Komponenten für einen typischen Zielproxy, der in einer Load Balancer-Weiterleitungsregel angegeben ist:
Weitere Informationen zu den Komponenten von Certificate Manager finden Sie unter Kernkomponenten.
Logik für die Zertifikatsauswahl
Im Allgemeinen wählt der Load Balancer ein Zertifikat so aus:
Ein Client initiiert einen Handshake, eine Verbindungsanfrage an den Dienst hinter dem Load Balancer.
Während des Handshakes stellt der Client dem Load Balancer eine Liste der kryptografischen Algorithmen zur Verfügung, die er zum Abschluss des Handshakes verwendet, und optional den Hostnamen, den er erreichen möchte. Dieser Hostname wird auch als Server Name Indication (SNI) bezeichnet.
Nach Erhalt der Anfrage wählt der Load Balancer ein Zertifikat aus, um den sicheren Handshake abzuschließen.
Exakte Übereinstimmung des Hostnamens: Wenn der angegebene Hostname des Clients genau mit einem Hostnameneintrag in der bereitgestellten Zertifikatszuordnung übereinstimmt, wählt der Load Balancer das entsprechende Zertifikat aus.
Übereinstimmung mit Platzhalter-Hostnamen: Wenn der Hostname des Clients mit keinem der Hostnameneinträge in der bereitgestellten Zertifikatszuordnung übereinstimmt, aber mit einem Platzhalter-Hostnamen in einem Zertifikatszuordnungseintrag, wählt der Load Balancer das entsprechende Zertifikat aus.
Ein Wildcard-Eintrag, der als *.myorg.example.com konfiguriert ist, deckt beispielsweise Subdomains der ersten Ebene in der Domain myorg.example.com ab. Der Platzhaltereintrag deckt keine Subdomains auf niedrigerer Ebene wie sub.subdomain.myorg.example.com ab.
Kein exakter oder Wildcard-Hostnamen-Abgleich: Wenn der Hostname des Clients mit keinem der Hostnameneinträge in der bereitgestellten Zertifikatzuordnung übereinstimmt, wählt der Load Balancer den primären Zertifikatzuordnungseintrag aus.
Handshake-Fehler: Wenn der Client keinen Hostnamen angegeben hat und der primäre Eintrag in der Zertifikatzuordnung nicht konfiguriert ist, schlägt der Handshake fehl.
Zertifikatspriorität
Bei der Auswahl eines Zertifikats priorisiert der Load Balancer die Zertifikate anhand der folgenden Faktoren:
Zertifikatstyp Wenn der Client ECDSA-Zertifikate unterstützt, priorisiert der Load Balancer diese gegenüber RSA-Zertifikaten. Wenn der Client keine ECDSA-Zertifikate unterstützt, gibt der Load Balancer stattdessen ein RSA-Zertifikat aus.
Zertifikatsgröße Da kleinere Zertifikate weniger Bandbreite beanspruchen, priorisiert der Load Balancer kleinere Zertifikate vor größeren.
Platzhalter-Domainnamen
Für Platzhalter-Domainnamen gelten die folgenden Regeln:
Nur von Google verwaltete Zertifikate mit DNS-Autorisierung und von Google verwaltete Zertifikate mit CA-Dienst unterstützen Platzhalter-Domainnamen.
Von Google verwaltete Zertifikate mit Load Balancer-Autorisierung unterstützen keine Domains mit Platzhaltern.
Eine genaue Übereinstimmung hat Vorrang vor einem Platzhalter, wenn beide im Eintrag definiert sind. Wenn Sie beispielsweise Zertifikatzuordnungseinträge für www.myorg.example.com und *.myorg.example.com konfiguriert haben, wird bei einer Verbindungsanfrage an www.myorg.example.com immer der Eintrag für www.myorg.example.com ausgewählt, auch wenn ein Eintrag für *.myorg.example.com vorhanden ist.
Wildcard-Domainnamen stimmen nur mit der ersten Subdomainebene überein. Bei einer Verbindungsanfrage für host1.myorg.example.com wird beispielsweise ein Eintrag in der Zertifikatzuordnung für *.myorg.example.com ausgewählt, aber nicht für host1.hosts.myorg.example.com.
Zertifikatverlängerung
Von Google verwaltete Zertifikate werden automatisch verlängert. Sie müssen selbst verwaltete Zertifikate manuell verlängern. Bei Bedarf können Sie Cloud Logging-Benachrichtigungen für Zertifikate konfigurieren, bevor sie ablaufen. Weitere Informationen finden Sie unter Logbenachrichtigungen konfigurieren.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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)"]]
