How Certificate Manager works Stay organized with collections Save and categorize content based on your preferences.
Certificate Manager uses a flexible mapping mechanism that provides youwith granular control over which certificates you can assign and how to servethem for each domain name in your environment.
The following diagram shows the relationships betweenCertificate Manager components for a typical target proxy specified ina load balancer forwarding rule:
To learn more about the components of Certificate Manager, seeCorecomponents.
Certificate selection logic
At a high level, the load balancer selects a certificate as follows:
A client initiates a handshake, which is a connection request to theservice behind the load balancer.
During the handshake, the client provides the load balancer a list ofcryptographic algorithms that the client uses to complete thehandshake, and, optionally, the hostname it is trying to reach. Thishostname is also called Server Name Indication (SNI).
On receiving the request, the load balancer selects a certificate tocomplete the secure handshake.
Exact hostname match: if the client's provided hostname exactlymatches a hostname entry in the provisioned certificate map, the loadbalancer selects the corresponding certificate.
Wildcard hostname match: if the client's hostname doesn't match anyone of the hostname entries in the provisioned certificate map, butdoes match a wildcard hostname in a certificate map entry, the loadbalancer selects the corresponding certificate.
For example, a wildcard entry configured as
*.myorg.example.comcoversfirst-level subdomains in themyorg.example.comdomain. The wildcardentry doesn't cover deeper level subdomains, such assub.subdomain.myorg.example.com.No exact or wildcard hostname match: if the client's hostnamedoesn't match any one of the hostname entries in the provisionedcertificate map, the load balancer selects the primary certificate mapentry.
Handshake failure: if the client didn't provide a hostname and theprimary certificate map entry isn't configured, the handshake fails.
Certificate priority
When selecting a certificate, the load balancer prioritizes them based on thefollowing factors:
- Certificate type. If the client supports the ECDSA certificates, theload balancer prioritizes them over RSA certificates. If the client doesn'tsupport ECDSA certificates, the load balancer serves an RSAcertificate instead.
- Certificate size. Because smaller certificates take less bandwidth, theload balancer prioritizes smaller certificates over larger ones.
Wildcard domain names
The following rules apply to wildcard domain names:
- Only Google-managed certificates with DNS authorization and Google-managedcertificates with CA Service support wildcard domain names.Google-managed certificates with load balancer authorization don't supportwildcard domain names.
- An exact match takes precedence over a wildcard when both are defined in theentry. For example, if you configured certificate map entries for
www.myorg.example.comand*.myorg.example.com, a connection requestagainstwww.myorg.example.comalways selects the entry forwww.myorg.example.comeven if an entry for*.myorg.example.comalsoexists. - Wildcard domain names only match the first level of subdomains. For example,a connection request for
host1.myorg.example.comselects a certificate mapentry for*.myorg.example.combut not one forhost1.hosts.myorg.example.com.
Certificate renewal
Google-managed certificates are renewed automatically. You must renewself-managed certificates manually. If necessary, you can configureCloud Logging alerts for certificates before they expire. For moreinformation, seeConfigure logalerts.
What's next
Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-12-15 UTC.