Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
O Gerenciador de certificados usa um mecanismo de mapeamento flexível que oferece
controle granular sobre quais certificados você pode atribuir e como fornecê-los
para cada nome de domínio no seu ambiente.
O diagrama a seguir mostra as relações entre
os componentes do Gerenciador de certificados para um proxy de destino típico especificado em
uma regra de encaminhamento do balanceador de carga:
Entidades do Gerenciador de certificados (clique para ampliar).
Para saber mais sobre os componentes do Gerenciador de certificados, consulte Componentes
essenciais.
Lógica de seleção de certificado
De modo geral, o balanceador de carga seleciona um certificado da seguinte maneira:
Um cliente inicia um handshake, que é uma solicitação de conexão ao
serviço por trás do balanceador de carga.
Durante o handshake, o cliente fornece ao balanceador de carga uma lista de
algoritmos criptográficos que ele usa para concluir o
handshake e, opcionalmente, o nome do host que ele está tentando alcançar. Esse
nome de host também é chamado de indicação de nome do servidor (SNI).
Ao receber a solicitação, o balanceador de carga seleciona um certificado para
concluir o handshake seguro.
Correspondência exata de nome do host: se o nome do host fornecido pelo cliente corresponder exatamente
a uma entrada de nome do host no mapa de certificado provisionado, o balanceador
de carga vai selecionar o certificado correspondente.
Correspondência de nome de host com caractere curinga: se o nome de host do cliente não corresponder a nenhuma
das entradas de nome de host no mapa de certificado provisionado, mas
corresponder a um nome de host com caractere curinga em uma entrada de mapa de certificado, o balanceador
de carga vai selecionar o certificado correspondente.
Por exemplo, uma entrada curinga configurada como *.myorg.example.com abrange
subdomínios de primeiro nível no domínio myorg.example.com. A entrada curinga
não abrange subdomínios de nível mais profundo, como
sub.subdomain.myorg.example.com.
Nenhuma correspondência exata ou curinga de nome de host: se o nome de host do cliente
não corresponder a nenhuma das entradas de nome de host no mapa de certificado provisionado, o balanceador de carga selecionará a entrada de mapa de certificado
principal.
Falha de handshake: se o cliente não fornecer um nome de host e a
entrada do mapa de certificado principal não estiver configurada, o handshake vai falhar.
Prioridade do certificado
Ao selecionar um certificado, o balanceador de carga os prioriza com base nos
seguintes fatores:
Tipo de certificado. Se o cliente for compatível com os certificados ECDSA, o
balanceador de carga vai priorizar esses certificados em vez dos certificados RSA. Se o cliente não
oferecer suporte a certificados ECDSA, o balanceador de carga vai oferecer um certificado
RSA.
Tamanho do certificado. Como os certificados menores consomem menos largura de banda, o
balanceador de carga prioriza certificados menores em vez de maiores.
Nomes de domínio curinga
As regras a seguir se aplicam a nomes de domínio curinga:
Somente certificados gerenciados pelo Google com autorização de DNS e certificados gerenciados pelo Google com o serviço de AC são compatíveis com nomes de domínio curinga.
Certificados gerenciados pelo Google com autorização do balanceador de carga não são compatíveis com
nomes de domínio curinga.
Uma correspondência exata tem precedência sobre um caractere curinga quando ambos são definidos na
entrada. Por exemplo, se você configurou entradas de mapeamento de certificado para
www.myorg.example.com e *.myorg.example.com, uma solicitação de conexão
contra www.myorg.example.com sempre seleciona a entrada para
www.myorg.example.com, mesmo que uma entrada para *.myorg.example.com também
exista.
Os nomes de domínio curinga correspondem apenas ao primeiro nível de subdomínios. Por exemplo,
uma solicitação de conexão para host1.myorg.example.com seleciona uma entrada de mapa de certificado
para *.myorg.example.com, mas não para
host1.hosts.myorg.example.com.
Renovação de certificados
Os certificados gerenciados pelo Google são renovados automaticamente. É necessário renovar
certificados autogerenciados manualmente. Se necessário, configure
alertas do Cloud Logging para certificados antes do vencimento. Para mais
informações, consulte Configurar alertas de registro.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)"]]
