How Certificate Manager works

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 domain name in your environment. The mechanism includes the following entities:

• Certificates
• 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 entities (click to enlarge).

Certificate Manager supports target HTTPS proxies and target SSL proxies. For more information about the differences between these proxy types, see Using target proxies.

By using Certificate Manager, you can attach your certificates in the following ways:

• If you're deploying certificates to global external Application Load Balancers, use certificate maps attached to target proxies and certificate map entries. For more information, see Deploy a global self-managed certificate.
• If you're deploying certificates to regional external Application Load Balancers, regional internal Application Load Balancers, or Secure Web Proxy gateways, attach certificates directly to target proxies or Secure Web Proxy gateways. For more information, see Deploy a regional self-managed certificate.
• If you're deploying certificates to cross-region internal Application Load Balancers, attach certificates with the ALL_REGIONS scope directly to target proxies. Cross-region internal Application Load Balancers don't support Google-managed certificates with load balancer authorization. However, they do support DNS authorization and Certificate Authority Service authorization.

Certificates

By default, a certificate represents a single X.509 Transport Layer Security (TLS) (SSL) certificate that is issued for specific domain names or domain wildcards.

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 by using a publicly trusted CA, 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. However, if you use the Certificate Authority Service to issue your Google-managed certificate, Certificate Manager does not publish any information to Certificate Transparency logs.

For more information, see Certificate Transparency.

To learn how to deploy a certificate with Certificate Manager, see Deployment overview.

Google-managed certificates

Managing Google-managed TLS (SSL) certificates for your websites and applications can be a complex and time-consuming task that often involves manual configuration and regular maintenance. Certificate Manager is a service designed to help you streamline this process by providing a centralized platform. You can delegate the responsibility of issuing and renewing certificates to Certificate Manager, freeing up your time to focus on other critical tasks.

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, the Google CA issues Google-managed certificates. When a new Google-Managed certificate is issued or renewed, it uses a freshly generated private key. 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.

Authentication for client-side only is not supported.

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.

Note that regional Google-managed certificates (Preview) only support DNS-based authorization and obtain certificates from the Google CA.

Google-managed certificates issued by the Certificate Authority Service

If you want to use your own trust chain rather than rely on Google-approved public CAs to issue your certificates, you can configure Certificate Manager to use a CA pool from the Certificate Authority Service as the certificate issuer instead. For more information about CA pools, see Creating CA Pools.

Self-managed certificates

If your business requirements don't 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.

Certificate Manager also allows you to deploy regional self-managed certificates on Secure Web Proxy proxies and regional load balancers.

Certificate maps

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 domain name. You can define different sets of certificates for different domain names, such as domains or subdomains. For example, you can upload an ECDSA and an RSA certificate and map them to the same domain name. When a client connects to that domain name, the load balancer negotiates the type of certificate to serve to the client during the handshake.

Domain authorizations

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.

To understand how Certificate Manager verifies domain ownership by using each method, see Domain authorizations for Google-managed certificates.

Certificate issuance configs

A certificate issuance config is a resource that allows Certificate Manager to use a CA pool from your own Certificate Authority Service instance to issue Google-managed certificates instead of the Google CA or the Let's Encrypt CA. It allows you to specify a number of parameters that govern certificate issuance and expiration as well as select the key algorithm for certificates issued this way.

Trust configs

A trust config is a resource that represents your Public Key Infrastructure (PKI) configuration in Certificate Manager for use in mutual TLS authentication scenarios. It encapsulates a single trust store, which in turn encapsulates a trust anchor and, optionally, one or more intermediate certificates.

To learn more about mutual TLS authentication, see Mutual TLS authentication in the Cloud Load Balancing documentation.

A trust config resource encapsulates trust store, trust anchor, and intermediate certificate entities.

Trust stores

A trust store represents the trust secret configuration in Certificate Manager for use in mutual TLS authentication scenarios. It encapsulates a single trust anchor and, optionally, one or more intermediate certificates.

Trust anchors

A trust anchor represents a single root certificate for use in mutual TLS authentication scenarios. It is encapsulated within a trust store.

Intermediate certificates

An intermediate certificate represents a single intermediate certificate signed by a root certificate or an intermediate certificate referenced in the encapsulating trust store for use in mutual TLS authentication scenarios.

One or more intermediate certificates can be encapsulated within a trust store, depending on your PKI configuration. All intermediate certificates specified within a trust config are included as part of the trust evaluation for every connection request in addition to the list of intermediate certificates specified in the request itself.

Allowlisted certificates

An allowlisted certificate represents any certificate that can be encapsulated within the trust config so that they are always considered as valid. An allowlisted certificate is always considered valid as long as the certificate is parseable, proof of private key possession is established, and constraints on the SAN field of the certificate are met. Expired certificates are also considered valid when they are allowlisted. You don't need a trust store while using allowlisted certificates.

Certificate selection logic

At a high level, the load balancer selects a certificate as follows:

1. 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.

2. The load balancer selects a certificate to complete the secure handshake based on the hostname that the client provides and the configured certificate map entries. The factors that determine which certificate the load balancer selects are as follows:

   • Exact hostname match: If the client provides a hostname that exactly matches an entry in the provisioned certificate map, the load balancer selects the corresponding certificate.

   • Wildcard hostname match: If the client's hostname doesn't match any entries but matches a wildcard hostname in a certificate map entry, the load balancer selects the corresponding certificate from that entry. For example, a wildcard entry configured as *.myorg.example.com covers first-level subdomains under the myorg.example.com domain.

   • No hostname match and a pre-configured primary certificate map entry: The load balancer selects a pre-configured primary certificate map entry in the absence of a hostname match or a matching provisioned certificate map entry.

   • Handshake failure: The handshake fails if the load balancer cannot find a matching certificate due to the following reasons:

     • 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.
     • A matching primary certificate map entry is not found, or if you have not configured a primary certificate map entry.

Note: A Google-managed certificate must complete provisioning before the load balancer can serve it.

Certificate priority

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.

Wildcard domain names

The following rules apply to wildcard domain names:

• 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 do not support wildcard domain names.
• 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.comalso exists.
• Wildcard domain names only match down to one subdomain level. 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.

Public CA

To use the public CA feature of Certificate Manager, you must be familiar with the following concepts:

• ACME client. An Automatic Certificate Management Environment (ACME) client is a certificate management client that uses the ACME protocol. Your ACME client must support external account binding (EAB) to work with Public CA.

• External account binding (EAB). You must bind each ACME account you are using with Certificate Manager public CA to the target Google Cloud project using external account binding. To do this, you must register each ACME account using a secret linked to its corresponding Google Cloud project. For more information, see External account binding.

Public CA challenges

When you use Public CA to request a certificate, Certificate Manager asks you to prove your control over the domains listed in that certificate. You can prove domain control by solving challenges. Public CA authorizes the domain names after you prove your control of the target domains.

After you obtain the required authorizations, you can request certificates that are valid only for a specific time duration. After this duration, you must revalidate the domain name by solving one of the three challenge types to continue requesting certificates.

Challenge types

Public CA supports the following types of challenges:

• HTTP challenge. This challenge involves creating a file at a well-known location on an HTTP server (port 80) for Public CA to retrieve and verify. For more information, see HTTP challenge.

• TLS-Application Layer Protocol Negotiation (ALPN) challenge. Requires a server to provide a specific certificate during a TLS negotiation on port 443 to prove control over a domain. For more information, see ACME TLS-ALPN challenge extension.

• DNS challenge. Requires adding a specific DNS record at a defined location to prove control over a domain. For more information, see DNS challenge.

If you use the HTTP challenge or the TLS-ALPN challenge to validate a domain name, the client can only request the validated domain names to be included in a certificate. If you use the DNS challenge, the client can also request subdomains of that domain name to be included in a certificate.

For example, if you validate *.myorg.example.com using the DNS challenge then subdomain1.myorg.example.com and subdomain2.myorg.example.com are automatically covered by the wildcard certificate. However, if you validate myorg.example.com using an HTTP or TLS-ALPN challenge the client can only request to include myorg.example.com in the certificate and you cannot validate *.myorg.example.com using the non-DNS challenges.

Challenge solution logic

The public CA challenge logic is as follows:

1. Public CA provides a random token.
2. The client makes the token available at a well-defined location. The location depends on the challenge.
3. The client indicates to Public CA that it has prepared the challenge.
4. Public CA checks if the token present at the expected location matches the expected value.

The domain name is authorized after this process is completed. The client can request a certificate with that domain name in it. You need to solve only one challenge per domain name.