Certificate Manager uses a flexible mapping mechanism that provides you with granular control over which certificates you can assign and how to serve them for each hostname in your environment. The mechanism comprises the following entities:
- Certificate maps
- Certificate map entries
- Domain authorizations
The following diagram illustrates the relationships between these entities for a typical target proxy specified in a load balancer forwarding rule:
Certificate Manager supports target HTTPS proxies and target SSL proxies. For more information on the differences between these proxy types, see Using target proxies.
By default, a certificate represents a single X.509 Transport Layer Security (TLS) (SSL) certificate that is issued for a specific hostname or as a domain wildcard.
Certificate Manager supports the following types of certificates:
- Google-managed certificates are certificates that Google Cloud obtains and manages for you.
- Self-managed certificates are certificates that you obtain, provision, and renew yourself.
When you issue a certificate, the CA publishes information about the associated domain to Certificate Transparency logs, which are publicly accessible. This is part of the standard certificate issuance process adopted by all publicly trusted CAs, and it applies to both Google-managed certificates and self-managed certificates. For more information, see Certificate Transparency.
To learn how to deploy a certificate with Certificate Manager, see Deployment overview.
Certificate Manager lets you manage the lifecycle of your Google-managed TLS (SSL) certificates from issuance to renewal. You can verify relevant domain ownership by using either load balancer-based or DNS-based authorization. Certificate Manager supports RSA Google-managed certificates.
By default, Google-managed certificates are issued by the Google CA. If you cannot obtain a certificate from the Google CA for a particular domain, Certificate Manager falls back to the Let's Encrypt CA. For example, the Google CA might refuse to issue a certificate for the domain, or your CA Authorization record explicitly prohibits the Google CA from issuing certificates for that domain.
For instructions about how to restrict the CAs that can issue certificates for your domains, see Specifying the CAs that can issue your Google-managed certificate.
If your business requirements do not allow you to use Google-managed certificates, you can upload certificates issued by external CAs along with their associated keys. You are responsible for manually issuing and renewing self-managed certificates.
A certificate map references one or more certificate map entries that assign specific certificates to specific hostnames. Certificate map entries also define the selection logic that the load balancer follows when establishing client connections. You can associate a certificate map with multiple target proxies for reuse across multiple load balancers.
If a client requests a hostname specified in a certificate map, the load balancer serves the certificates mapped to that hostname. Otherwise, the load balancer serves the primary certificate. For more information, see Certificate selection logic.
Certificate map entries
A certificate map entry is a list of certificates served for a specific hostname. You can define different sets of certificates for different hostnames, such as domains or subdomains. For example, you can upload an ECDSA and an RSA certificate and map them to the same hostname. When a client connects to that hostname, the load balancer negotiates the type of certificate to serve to the client during the handshake.
Certificate Manager lets you prove ownership of domains for which you want to issue Google-managed certificates as described in the following table:
|Load balancer authorization||DNS authorization|
|Setup complexity||Does not require additional configuration steps or changes to your DNS configuration.||Requires you to create a DNS authorization and add its corresponding CNAME record to your DNS configuration.|
|Network security||The load balancer must be fully accessible from the Internet on port 443, including the DNS configuration for all domains served by the certificate. Does not work with other configurations.||Works with high-complexity configurations, such as ports other than 443 and CDN layers in front of the target proxy.|
|Provisioning speed||You can provision certificates only after the load balancer has been fully set up and is serving network traffic.||You can provision certificates in advance, before the target proxy is ready to serve network traffic.|
See Domain authorizations for Google-managed certificates to understand how Certificate Manager verifies domain ownership using each method.
Certificate selection logic
At a high level, the load balancer selects a certificate as follows:
- A client initiates a handshake. During this step, it provides the load balancer with a list of cryptographic algorithms it can use to complete the handshake, and, optionally, a hostname.
- Depending on whether the client supplies a hostname and how closely it
matches the hostnames configured in the provisioned certificate map entries,
the load balancer completes one or more of the following steps:
- If the client supplies a hostname, the load balancer searches for a certificate map entry which matches it exactly. If one exists, the load balancer searches within that certificate map entry for a certificate compatible with one of the cryptographic algorithms specified by the client. If it finds one, it uses that certificate to complete the handshake.
- If the client-supplied hostname does not exactly match any hostnames
specified in the provisioned certificate map entries, the load balancer then
searches for a certificate map entry containing a wildcard. For example,
a wild card entry configured as
*.example.comcovers first-level subdomains under the
example.comdomain. If one exists, the load balancer searches within that certificate map entry for a certificate compatible with one of the cryptographic algorithms specified by the client. If it finds one, it uses that certificate to complete the handshake.
- If the client supplies a hostname that does not match any exact or wildcard hostnames specified in all provisioned certificate map entries, or does not supply a hostname at all, and you have configured a primary certificate map entry, the load balancer searches within its primary certificate map entry for a certificate compatible with the cryptographic algorithms specified by the client. If it finds one, it uses that certificate to complete the handshake. If it does not find one, or if you have not configured a primary certificate map entry, the handshake fails and the load balancer rejects the connection.
The load balancer selects a certificate within a certificate map entry based on the following:
- Certificate type. If the connecting client supports the more secure ECDSA certificates, the load balancer prioritizes them over RSA certificates. If the client does not indicate support for ECDSA certificates, the load balancer serves an RSA certificate instead.
- Certificate size. The load balancer prioritizes certificates from smallest to largest.
The following rules apply to wildcard hostnames:
- An exact match takes precedence over a wildcard when both are defined in the
entry. For example, if you configured certificate map entries for
*.example.com, a connection request against
www.example.comalways selects the entry for
www.example.comeven if an entry for
- Wildcard hostnames only match down to one subdomain level. For
example, a connection request for
host1.example.comselects a certificate map entry for
*.example.combut not one for