GCP Certificate-Manager global Certificate-Map global certificate : "invalid scope"

Google Cloud Compute Infrastructure
, ,
1

I have a GCP project with :

  • a global (“scope: ALL_REGIONS”) active existing Google-managed certificate (listed as “Certificate” not “classicCertificate”)
  • an existing global certificate map

when adding the cert into the certificate map, I receive error :

ERROR: (gcloud.certificate-manager.maps.entries.create) INVALID_ARGUMENT: certificate “projects/200020001113/locations/global/certificates/cert-dev-global” has invalid scope

I don’t understand as it should match (both are “global”). Any help ?

1 Like
2

Hi @nalb ,

Welcome to Google Cloud Community!

While both are labeled as “global,” Google-managed certificates (listed as “Certificate” rather than “classicCertificate”) are currently region-specific, even when set to ALL_REGIONS. If the certificate is Google-managed, it may not be compatible with a global certificate map.

Alternative Solution:

  • Create a Regional Certificate Map:
    If the certificate is Google-managed, it must be mapped to a regional certificate map instead of a global one. Try creating a regional certificate map and adding the certificate there:
    gcloud certificate-manager maps create my-regional-map --location=<REGION

Then, add the certificate to the newly created map.

  • Or Use Classic Certificates:
    If you require a truly global certificate, consider creating a classicCertificate instead.

Certificate maps are not supported by cross-region internal Application Load Balancers. After you create the Google-managed certificate, attach the certificate directly to the target proxy.

Other References: Certificate Manager Limitations, GCP Public Tracker: Certificate Manager does not support --scope=“all-regions”

Was this helpful? If so, please accept this answer as “Solution”. If you need additional assistance, reply here within 2 business days and I’ll be happy to help.

3

Just use the Default scope when creating the certificate

4

ou’re running into a real (and annoyingly confusing) Certificate Manager constraint: the words “global” and “ALL_REGIONS” in the resource path/fields do not guarantee that the certificate is eligible to be referenced from a global certificate map.

What’s happening under the hood:

  • A certificate map is a routing object that sits in front of a load balancer target proxy and decides which cert(s) to present based on hostname.

  • A global certificate map expects certificates that are valid for that global attachment model.

  • Google-managed certificates in Certificate Manager can appear as locations/global and show scope: ALL_REGIONS, but they’re still handled with constraints that make them ineligible for global certificate-map entries in some scenarios.

  • Result: when you try to attach it, the API rejects it with:
    INVALID_ARGUMENT: … has invalid scope

So it’s not that your config is “wrong,” it’s that the API is telling you: this certificate type + scope combination cannot be used inside that map type.

How to fix it (pick the path that matches your goal)

Fix 1: Use a regional certificate map (best if you want Google-managed certs)

If you want Google to manage issuance/renewal and you don’t strictly need a global map, use a regional map and keep everything consistent in the same region.

Steps

  1. Create a regional map:
gcloud certificate-manager maps create my-regional-map \
  --location=us-central1
  1. Create the map entry pointing to your cert:
gcloud certificate-manager maps entries create my-entry \
  --location=us-central1 \
  --map=my-regional-map \
  --hostname="example.com" \
  --certificates="projects/PROJECT_ID/locations/global/certificates/cert-dev-global"

If the cert still refuses because of scope/type, then the cleanest way is to recreate the cert in the same region model you’re using for the map (below).

Fix 2: Recreate the certificate using the default scope (often resolves “invalid scope”)

A bunch of people hit this when they explicitly set ALL_REGIONS. In practice, using the default scope avoids this “looks global but isn’t mappable globally” edge case.

Approach

  • Create a new Google-managed certificate without forcing ALL_REGIONS (use defaults).

  • Add that certificate to the map.

(Exact flags depend on how you created the cert: DNS authorization vs load balancer authorization. The key point is: don’t force the all-regions scope if you plan to map it.)

Fix 3: If you truly need a global certificate map, use a classic certificate

If your architecture requires a global map specifically (for example, you’re standardizing on global external HTTPS LB + global mapping), the pragmatic fix is to use a classic certificate that’s compatible with global maps.

This trades off some of the newer Certificate Manager “Google-managed certificate” behavior for compatibility.

Fix 4: Skip certificate maps and attach the cert directly to the target proxy (when applicable)

If your goal is just “make HTTPS work” and you don’t actually need hostname-based mapping (or you only have a small number of hostnames), the simplest operational fix can be:

  • Don’t use certificate maps

  • Attach the certificate directly to the Target HTTPS Proxy / LB config

This avoids the map eligibility rules entirely.

Quick sanity checks (to confirm what you’re dealing with)

Run these and look specifically for type, scope, and location expectations:

gcloud certificate-manager certificates describe cert-dev-global --location=global
gcloud certificate-manager maps describe YOUR_MAP --location=global

If the map is global and the cert is Google-managed (Certificate Manager “Certificate”, not “classicCertificate”), this mismatch is exactly where the error comes from.

Two official docs to reference in your forum reply

If you want, paste (redact project/hostnames) the output of gcloud certificate-manager certificates describe ... and ... maps describe ... and I’ll tell you which of the 4 fixes is the cleanest for your exact LB setup.