Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
El Administrador de certificados usa un mecanismo de asignación flexible que te proporciona un control detallado sobre los certificados que puedes asignar y cómo entregarlos para cada nombre de dominio de tu entorno.
En el siguiente diagrama, se muestran las relaciones entre los componentes del Administrador de certificados para un proxy de destino típico especificado en una regla de reenvío del balanceador de cargas:
Entidades del Administrador de certificados (haz clic para ampliar).
Para obtener más información sobre los componentes del Administrador de certificados, consulta Componentes principales.
Lógica de selección de certificados
En un nivel alto, el balanceador de cargas selecciona un certificado de la siguiente manera:
Un cliente inicia un protocolo de enlace, que es una solicitud de conexión al servicio detrás del balanceador de cargas.
Durante el protocolo de enlace, el cliente proporciona al balanceador de cargas una lista de algoritmos de criptografía que usa para completar el protocolo de enlace y, de manera opcional, el nombre de host al que intenta conectarse. Este nombre de host también se denomina indicación de nombre de servidor (SNI).
Cuando recibe la solicitud, el balanceador de cargas selecciona un certificado para completar el protocolo de enlace seguro.
Coincidencia exacta de nombre de host: Si el nombre de host proporcionado por el cliente coincide exactamente con una entrada de nombre de host en el mapa de certificados aprovisionado, el balanceador de cargas selecciona el certificado correspondiente.
Coincidencia de nombre de host con comodines: Si el nombre de host del cliente no coincide con ninguna de las entradas de nombre de host del mapa de certificados aprovisionado, pero sí coincide con un nombre de host con comodines en una entrada de mapa de certificados, el balanceador de cargas selecciona el certificado correspondiente.
Por ejemplo, una entrada de comodín configurada como *.myorg.example.com abarca los subdominios de primer nivel en el dominio myorg.example.com. La entrada de comodín no abarca subdominios de nivel más bajo, como sub.subdomain.myorg.example.com.
No hay coincidencia exacta ni de comodín con el nombre de host: Si el nombre de host del cliente no coincide con ninguna de las entradas de nombre de host en el mapa de certificados aprovisionado, el balanceador de cargas selecciona la entrada de mapa de certificados principal.
Falla de protocolo de enlace: Si el cliente no proporcionó un nombre de host y la entrada del mapa de certificados principal no está configurada, el protocolo de enlace falla.
Prioridad del certificado
Cuando seleccionas un certificado, el balanceador de cargas lo prioriza en función de los siguientes factores:
Tipo de certificado. Si el cliente admite los certificados ECDSA, el balanceador de cargas los prioriza sobre los certificados RSA. Si el cliente no admite certificados ECDSA, el balanceador de cargas entrega un certificado RSA.
Tamaño del certificado. Dado que los certificados más pequeños ocupan menos ancho de banda, el balanceador de cargas prioriza los certificados más pequeños sobre los más grandes.
Nombres de dominio con comodines
Las siguientes reglas se aplican a los nombres de dominio con comodines:
Solo los certificados administrados por Google con autorización de DNS y los certificados administrados por Google con el servicio de AC admiten nombres de dominio con comodines.
Los certificados administrados por Google con autorización de balanceador de cargas no admiten nombres de dominio comodín.
Una concordancia exacta tiene prioridad sobre un comodín cuando ambos se definen en la entrada. Por ejemplo, si configuraste entradas de mapa de certificados para www.myorg.example.com y *.myorg.example.com, una solicitud de conexión con www.myorg.example.com siempre selecciona la entrada para www.myorg.example.com, incluso si también existe una entrada para *.myorg.example.com.
Los nombres de dominio con comodines solo coinciden con el primer nivel de subdominios. Por ejemplo, una solicitud de conexión para host1.myorg.example.com selecciona una entrada de mapa de certificados para *.myorg.example.com, pero no para host1.hosts.myorg.example.com.
Renovación de certificados
Los certificados administrados por Google se renuevan automáticamente. Debes renovar los certificados administrados de forma manual. Si es necesario, puedes configurar
alertas de Cloud Logging para los certificados antes de que venzan. Para obtener más información, consulta Configura alertas de registro.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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)"]]
