The troubleshooting procedures differ, depending whether you're using Google-managed SSL certificates or self-managed SSL certificates.
Troubleshoot Google-managed certificates
For Google-managed certificates, there are two types of status:
- Managed status
- Domain status
To check the certificate status, run the following command:
gcloud compute ssl-certificates describe CERTIFICATE_NAME \ --global \ --format="get(name,managed.status)"
Values for managed status are as follows:
The Google-managed certificate has been created and Google Cloud is working with the Certificate Authority to sign it.
Provisioning a Google-managed certificate might take up to 60 minutes from the moment your DNS and load balancer configuration changes have propagated across the internet. If you have updated your DNS configuration recently, it can take a significant amount of time for the changes to fully propagate. Sometimes propagation takes up to 72 hours worldwide, although it typically takes a few hours. For more information on DNS propagation, see Propagation of changes.
If the certificate remains in the PROVISIONING state, make sure that the correct
certificate is associated with the target proxy. You can check this by
||The Google-managed SSL certificate is obtained from the Certificate Authority. It might take an additional 30 minutes to be available for use by a load balancer.|
||You might briefly see
If the status remains
Google Cloud retries provisioning until successful or the status changes to
||The Google-managed certificate is created, but the Certificate Authority
can't sign it because of a DNS or load balancer configuration issue. In
this state, Google Cloud doesn't retry provisioning.
Create a replacement Google-managed SSL certificate, and make sure that the replacement is associated with your load balancer's target proxy. Verify or complete all steps in Using Google-managed SSL certificates. Afterwards, you can delete the certificate that permanently failed provisioning.
The Google-managed certificate renewal failed because of an issue with the load balancer or DNS configuration. If any of the domains or subdomains in a managed certificate aren't pointing to the load balancer's IP address by using an A/AAAA record, the renewal process fails. The existing certificate continues to serve, but expires shortly. Check your configuration.
If the status remains
For more information about certificate renewal, see Google-managed SSL certificate renewal.
To check the domain status, run the following command:
gcloud compute ssl-certificates describe CERTIFICATE_NAME \ --global \ --format="get(managed.domainStatus)"
Values for domain status are described in this table.
||The Google-managed certificate is created for the domain. Google Cloud is working with the Certificate Authority to sign the certificate.|
The domain has been successfully validated for provisioning the
certificate. If the SSL certificate is for multiple domains, the
certificate can only be provisioned once all the domains have an
Certificate provisioning hasn't completed for the domain. Any of the following might be the issue:
||Certificate provisioning failed because of a configuration issue with your domain's CAA record. Ensure that you have followed the correct procedure.|
||Certificate provisioning failed because your domain's CAA record doesn't specify a CA that Google Cloud needs to use. Ensure that you have followed the correct procedure.|
||Certificate provisioning failed because a Certificate Authority has rate-limited certificate signing requests. You can provision a new certificate, switch to using the new certificate, and delete the old certificate, or you can contact Google Cloud Support.|
Managed certificate renewal
If any of the domains or subdomains in a managed certificate aren't pointing to the load balancer's IP address, the renewal process fails. To avoid renewal failure, make sure that all your domains and subdomains are pointing to the load balancer's IP address.
Troubleshoot self-managed SSL certificates
Certificate cannot be parsed
Google Cloud requires certificates in PEM format. If the certificate is PEM formatted, check the following:
You can validate your certificate using the following OpenSSL command, replacing
CERTIFICATE_FILE with the path to your certificate file:
openssl x509 -in CERTIFICATE_FILE -text -noout
If OpenSSL is unable to parse your certificate:
- Contact your CA for help.
- Create a new private key and certificate.
Missing common name or subject alternative name
Google Cloud requires that your certificate have either a common name
CN) or subject alternative name (
SAN) attribute. See Create a
When both attributes are absent, Google Cloud displays an error message like the following when you try to create a self-managed certificate:
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 the private key criteria.
You can validate your private key using the following OpenSSL command, replacing
PRIVATE_KEY_FILE with the path to your private key:
openssl rsa -in PRIVATE_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 must create a new private key and certificate.
Private keys with passphrases
If OpenSSL prompts for a passphrase, you'll need to remove the passphrase from your private key before you can use it with Google Cloud. You can use the following OpenSSL command:
openssl rsa -in PRIVATE_KEY_FILE \ -out REPLACEMENT_PRIVATE_KEY_FILE
Replace the placeholders with valid values:
PRIVATE_KEY_FILE: The path to your private key that's protected with a passphrase
REPLACEMENT_PRIVATE_KEY_FILE: A file path where you'd like to save a copy of your plaintext private key
Expiring intermediate certificate(s)
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 in Google Cloud might become invalid. This depends on the SSL client, as follows:
- Some SSL clients only look at the expire time of the leaf certificate and ignore 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:
- Wait for the CA to switch to a new intermediate certificate.
- Request a new certificate from them.
- Re-upload the new certificate with the new keys.
Your CA might also allow cross-signing for intermediate certificates. Check with your CA to confirm.
RSA public exponent is too large
The following error message appears when the RSA public exponent is larger
than 65537. Make sure to use
65537, as specified in
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 attached to the target https proxy:
Export the target-https-proxy to a temporary file.
gcloud compute target-https-proxies export TARGET_PROXY_NAME > /tmp/proxy
/tmp/proxyfile and remove the following lines:
sslCertificates: - https://www.googleapis.com/compute/v1/projects/...
gcloud compute target-https-proxies import TARGET_PROXY_NAME \ --source=/tmp/proxy
Optional: Delete the SSL certificate.
gcloud compute ssl-certificates delete SSL_CERT_NAME
Replace the following:
TARGET_PROXY_NAME: the name of the target https proxy resource.
SSL_CERT_NAME: the name of the SSL certificate.