Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Le Gestionnaire de certificats utilise un mécanisme de mappage flexible qui vous permet de contrôler précisément les certificats que vous pouvez attribuer et la manière de les diffuser pour chaque nom de domaine de votre environnement.
Le schéma suivant illustre les relations entre les composants du Gestionnaire de certificats pour un proxy cible typique spécifié dans une règle de transfert d'équilibreur de charge:
Entités du gestionnaire de certificats (cliquez pour agrandir).
Pour en savoir plus sur les composants du Gestionnaire de certificats, consultez la section Composants principaux.
Logique de sélection du certificat
De manière générale, l'équilibreur de charge sélectionne un certificat comme suit:
Un client lance un handshake, qui est une requête de connexion au service derrière l'équilibreur de charge.
Lors du handshake, le client fournit à l'équilibreur de charge une liste des algorithmes cryptographiques qu'il utilise pour effectuer le handshake, et éventuellement le nom d'hôte qu'il tente d'atteindre. Ce nom d'hôte est également appelé "indication du nom du serveur" (SNI).
À la réception de la requête, l'équilibreur de charge sélectionne un certificat pour effectuer le handshake sécurisé.
Correspondance exacte du nom d'hôte: si le nom d'hôte fourni par le client correspond exactement à une entrée de nom d'hôte dans le mappage de certificat provisionné, l'équilibreur de charge sélectionne le certificat correspondant.
Correspondance de nom d'hôte générique: si le nom d'hôte du client ne correspond à aucune des entrées de nom d'hôte du mappage de certificat provisionné, mais qu'il correspond à un nom d'hôte générique dans une entrée de mappage de certificat, l'équilibreur de charge sélectionne le certificat correspondant.
Par exemple, une entrée générique configurée en tant que *.myorg.example.com couvre les sous-domaines de premier niveau du domaine myorg.example.com. L'entrée générique ne couvre pas les sous-domaines de niveau supérieur, tels que sub.subdomain.myorg.example.com.
Aucun nom d'hôte exact ou générique ne correspond: si le nom d'hôte du client ne correspond à aucune des entrées de nom d'hôte dans le mappage de certificat provisionné, l'équilibreur de charge sélectionne l'entrée de mappage de certificat principal.
Échec du handshake: si le client n'a pas fourni de nom d'hôte et que l'entrée de mappage de certificat principal n'est pas configurée, le handshake échoue.
Priorité du certificat
Lorsqu'il sélectionne un certificat, l'équilibreur de charge les hiérarchise en fonction des facteurs suivants:
Type de certificat Si le client est compatible avec les certificats ECDSA, l'équilibreur de charge les priorise par rapport aux certificats RSA. Si le client n'est pas compatible avec les certificats ECDSA, l'équilibreur de charge fournit un certificat RSA à la place.
Taille du certificat. Étant donné que les certificats plus petits occupent moins de bande passante, l'équilibreur de charge les priorise par rapport aux plus volumineux.
Noms de domaine avec caractères génériques
Les règles suivantes s'appliquent aux noms de domaine avec caractères génériques:
Seuls les certificats gérés par Google avec autorisation DNS et les certificats gérés par Google avec CA Service sont compatibles avec les noms de domaine génériques.
Les certificats gérés par Google avec une autorisation d'équilibreur de charge ne sont pas compatibles avec les noms de domaine avec des caractères génériques.
Une correspondance exacte est prioritaire sur un caractère générique lorsque les deux sont définis dans l'entrée. Par exemple, si vous avez configuré des entrées de mappage de certificats pour www.myorg.example.com et *.myorg.example.com, une requête de connexion à www.myorg.example.com sélectionne toujours l'entrée pour www.myorg.example.com, même si une entrée pour *.myorg.example.com existe également.
Les noms de domaine génériques ne correspondent qu'au premier niveau de sous-domaines. Par exemple, une requête de connexion pour host1.myorg.example.com sélectionne une entrée de mappage de certificats pour *.myorg.example.com, mais pas pour host1.hosts.myorg.example.com.
Renouvellement de certificat
Les certificats gérés par Google sont renouvelés automatiquement. Vous devez renouveler manuellement les certificats autogérés. Si nécessaire, vous pouvez configurer des alertes Cloud Logging pour les certificats avant leur expiration. Pour en savoir plus, consultez la page Configurer les alertes de journal.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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)"]]
