Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Certificate Manager utilizza un meccanismo di mappatura flessibile che ti offre un controllo granulare sui certificati che puoi assegnare e su come pubblicarli per ogni nome di dominio nel tuo ambiente.
Il seguente diagramma mostra le relazioni tra i componenti di Certificate Manager per un proxy target tipico specificato in una regola di inoltro del bilanciatore del carico:
Entità di Gestore certificati (fai clic per ingrandire).
Per scoprire di più sui componenti di Certificate Manager, consulta Componenti di base.
Logica di selezione dei certificati
A livello generale, il bilanciatore del carico seleziona un certificato come segue:
Un client avvia un handshake, ovvero una richiesta di connessione al servizio dietro il bilanciatore del carico.
Durante l'handshake, il client fornisce al bilanciatore del carico un elenco di algoritmi criptografici che utilizza per completare l'handshake e, facoltativamente, il nome host che sta tentando di raggiungere. Questo
nome host è chiamato anche indicazione del nome server (SNI).
Al ricevimento della richiesta, il bilanciatore del carico seleziona un certificato per completare l'handshake sicuro.
Corrispondenza esatta del nome host: se il nome host fornito dal client corrisponde esattamente a una voce del nome host nella mappa dei certificati di cui è stato eseguito il provisioning, il bilanciatore del carico seleziona il certificato corrispondente.
Corrispondenza del nome host con caratteri jolly: se il nome host del client non corrisponde a nessuna delle voci del nome host nella mappa dei certificati di cui è stato eseguito il provisioning, ma corrisponde a un nome host con caratteri jolly in una voce della mappa dei certificati, il bilanciatore del carico seleziona il certificato corrispondente.
Ad esempio, una voce jolly configurata come *.myorg.example.com copre
i sottodomini di primo livello nel dominio myorg.example.com. L'elemento wildcard
non copre i sottodomini di livello più elevato, come
sub.subdomain.myorg.example.com.
Nessuna corrispondenza esatta o con caratteri jolly del nome host: se il nome host del client non corrisponde a nessuna delle voci del nome host nella mappa di certificati di cui è stato eseguito il provisioning, il bilanciatore del carico seleziona la voce della mappa di certificati principale.
Errore di handshake: se il client non ha fornito un nome host e la voce della mappa dei certificati principali non è configurata, l'handshake non va a buon fine.
Priorità del certificato
Quando seleziona un certificato, il bilanciatore del carico li dà la priorità in base ai seguenti fattori:
Tipo di certificato. Se il client supporta i certificati ECDSA, il bilanciatore del carico li dà la priorità rispetto ai certificati RSA. Se il client non supporta i certificati ECDSA, il bilanciatore del carico fornisce un certificato RSA.
Dimensioni del certificato. Poiché i certificati più piccoli richiedono meno larghezza di banda, il bilanciatore del carico dà la priorità ai certificati più piccoli rispetto a quelli più grandi.
Nomi di dominio con caratteri jolly
Ai nomi di dominio jolly si applicano le seguenti regole:
Solo i certificati gestiti da Google con autorizzazione DNS e i certificati gestiti da Google con il servizio CA supportano i nomi di dominio con caratteri jolly.
I certificati gestiti da Google con autorizzazione del bilanciatore del carico non supportano i nomi di dominio con caratteri jolly.
Una corrispondenza esatta ha la precedenza su un carattere jolly quando entrambi sono definiti nella voce. Ad esempio, se hai configurato voci della mappa dei certificati per www.myorg.example.com e *.myorg.example.com, una richiesta di connessione a www.myorg.example.com seleziona sempre la voce per www.myorg.example.com anche se esiste anche una voce per *.myorg.example.com.
I nomi di dominio con caratteri jolly corrispondono solo al primo livello di sottodomini. Ad esempio,
una richiesta di connessione per host1.myorg.example.com seleziona una voce della mappa dei certificati per *.myorg.example.com, ma non per
host1.hosts.myorg.example.com.
Rinnovo del certificato
I certificati gestiti da Google vengono rinnovati automaticamente. Devi rinnovare manualmente i certificati gestiti autonomamente. Se necessario, puoi configurare gli avvisi di Cloud Logging per i certificati prima della loro scadenza. Per ulteriori informazioni, consulta Configurare gli avvisi dei log.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-04 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)"]]