The troubleshooting procedures depend on thetype of SSL certificates that areused.

Troubleshoot Google-managed certificates

For Google-managed certificates, there are two types of status:

• Managed status
• Domain status

Managed status

To check the certificate status, run the following command:

gcloud compute ssl-certificates describeCERTIFICATE_NAME \    --global \    --format="get(name,managed.status)"

Values formanaged status are as follows:

Domain status

To check the domain status, run the following command:

gcloud compute ssl-certificates describeCERTIFICATE_NAME \    --global \    --format="get(managed.domainStatus)"

Values fordomain status are described in this table.

To help ensure that your certificates don't fail the domain validation step ofthe renewal process, review therequirements for your DNS A and AAAArecords.

Multi-perspective domain validation

Google Cloud periodically renews your Google-managed certificates by requestingthem from certificate authorities (CAs). The CAs thatGoogle Cloud works with to renew your certificates use a multi-perspectivedomain validation method known asMulti-Perspective Issuance Corroboration(MPIC).As part of this process, the certificate authorities verify domain control bychecking the domain's DNS settings and attempting to contact the serverbehind the domain's IP address.These verifications are conducted from multiple vantage points across theinternet. If the validation process fails, Google-managed certificates fail torenew. As a result, your load balancer serves an expired certificate to clients,causing browser users to encounter certificate errors and API clients toexperience connection failures.

To prevent multi-perspective domain validation failures for misconfigured DNSrecords, note the following:

• Your DNS A records (IPv4) and DNS AAAA (IPv6) records for your domains and any subdomains pointonly to the IP address (or addresses) associated with the load balancer's forwarding rule (or rules). The existence of any other addresses in the record can cause validation to fail.
• The CA, which performs validation of DNS records, queries DNS records from multiple locations. Ensure that your DNS provider responds consistently to all the global domain validation requests.
• Using GeoDNS (returning different IP addresses based on the request location) or location-based DNS policies can lead to inconsistent responses and cause validation to fail. If your DNS provider uses GeoDNS, disable it, or ensure that all regions return the same load balancer's IP address.
• You must explicitly specify the IP addresses of your load balancer in your DNS configuration. Intermediate layers, such as a CDN, can cause unpredictable behavior. The IP address needs to be directly accessible without any redirects, firewalls, or CDNs in the request path. To learn more, see theLoad balancers behind a CDN section in this document.
• We recommended that you use a DNS global propagation checker of your choice to verify that all the relevant DNS records resolve correctly and consistently across the globe.

Verify configuration changes

After you have configured your DNS records, you can verify that they are correctby creating a new certificate and connecting it to your load balancer along withthe existing certificate. This step forces an immediate certificate provisioningcheck with the CA, letting you verify your configurationchanges within minutes. Without this, automatic renewals of the existingcertificate can take days or weeks, leaving uncertainty about your setup.

If thecertificate status becomesACTIVE, it indicates thatthe certificate has been issued, thereby confirming that your DNS configurationis correct. At this point, we recommend that you remove the earlier certificateto avoid having two separate certificates for the same domain. This processdoesn't interrupt traffic to your load balancer.

The new certificate serves as a validation tool—its creation confirms thatmulti-perspective domain validation using MPIC works correctly for your setup.

Load balancers behind a CDN

For load balancers that have CDN enabled, some third-party CDN providers in therequest path might prevent validation requests from succeeding. This can happenif the CDN provider is actively proxying HTTP(S) traffic.

In such cases, we recommendmigrating your certificates toCertificate Manager and using theDNS authorizationmethod to provision Google-managed certificates. The latter approach doesn'trequire the CA to contact your load balancer.

Troubleshoot self-managed SSL certificates

This guide describes how to troubleshoot configuration issues for self-managedSSL certificates.

Certificate cannot be parsed

Google Cloud requires certificates inPEMformat.If the certificate is PEM formatted, check the following:

You can validate your certificate using the following OpenSSL command, replacingCERTIFICATE_FILE with the path to your certificate file:

openssl x509 -inCERTIFICATE_FILE -text -noout

If OpenSSL is unable to parse your certificate:

• Contact your CA for help.
• Create a new private key andcertificate.

Missing common name or subject alternative name

Google Cloud requires that your certificate haveeither a common name(CN) or subject alternative name (SAN) attribute. SeeCreate aCSR foradditional information.

When both attributes are absent, Google Cloud displays an error messagelike the following when you try tocreate a self-managedcertificate:

ERROR: (gcloud.compute.ssl-certificates.create) Could not fetch resource: -   The SSL certificate is missing a Common Name(CN) or Subject Alternative   Name(SAN).

Private key cannot be parsed

Google Cloud requires PEM-formatted private keys that meet theprivatekeycriteria.

You can validate your private key using the following OpenSSL command, replacingPRIVATE_KEY_FILE with the path to your private key:

    openssl rsa -inPRIVATE_KEY_FILE -check

The following responses indicate a problem with your private key:

• unable to load Private Key
• Expecting: ANY PRIVATE KEY
• RSA key error: n does not equal p q
• RSA key error: d e not congruent to 1
• RSA key error: dmp1 not congruent to d
• RSA key error: dmq1 not congruent to d
• RSA key error: iqmp not inverse of q

To fix the problem, you mustcreate a new private key andcertificate.

Private keys with passphrases

If OpenSSL prompts for a passphrase, you'll need to remove the passphrase fromyour private key before you can use it with Google Cloud. You can use thefollowing OpenSSL command:

openssl rsa -inPRIVATE_KEY_FILE \    -outREPLACEMENT_PRIVATE_KEY_FILE

Replace the placeholders with valid values:

• PRIVATE_KEY_FILE: The path to your private key that'sprotected with a passphrase
• REPLACEMENT_PRIVATE_KEY_FILE: The path where you'dlike to save a copy of your plain text private key

Expiring intermediate certificates

If an intermediate certificate expires before the server (leaf) certificate,this might indicate that your CA isn't following best practices.

When an intermediate certificate expires, your leaf certificate used inGoogle Cloud might become invalid. This depends on the SSL client, asfollows:

• Some SSL clients only look at the expire time of the leaf certificate andignore expired intermediate certificates.
• Some SSL clients treat a chain with any expired intermediate certificate(s)as invalid and display a warning.

To resolve this issue:

1. Wait for the CA to switch to a new intermediate certificate.
2. Request a new certificate from them.
3. Re-upload the new certificate with the new keys.

Your CA might also allow cross-signing for intermediate certificates. Check withyour CA to confirm.

RSA public exponent is too large

The following error message appears when the RSA public exponent is larger than65537. Make sure to use65537, as specified inRFC4871.

ERROR: (gcloud.compute.ssl-certificates.create) Could not fetch resource: -   The RSA public exponent is too large.

Remove SSL certificate from target-proxy

The following steps demonstrate how to remove a single SSL certificate attachedto the target https proxy:

1. Export the target-https-proxy to a temporary file.

   gcloud compute target-https-proxies exportTARGET_PROXY_NAME > /tmp/proxy

2. Edit/tmp/proxy file and remove the following lines:

   sslCertificates:-https://www.googleapis.com/compute/v1/projects/...

3. Import the/tmp/proxy file.

   gcloud compute target-https-proxies importTARGET_PROXY_NAME \   --source=/tmp/proxy

4. Optional: Delete the SSL certificate.

   gcloud compute ssl-certificates deleteSSL_CERT_NAME

Replace the following:

• TARGET_PROXY_NAME: the name of the target httpsproxy resource.
• SSL_CERT_NAME: the name of the SSL certificate.