Load balancer - Google-managed cetificate provision failing

[Kuba Bartel]

Hello,

I created new Google-managed certificate on an existing Load balancer's frontend but it still fails into FAILED_NOT_VISIBLE status.

If I read the documentation correctly this status should be related to DNS records - which I believe are set up correctly to the frontend's IP.

I've used gcloud cli and also manual set up in web Console. Both with the same result.

Are there any special requirements or restrictions related to DNS records?

Thanks

[Nur]

Hello Kuba, 

I have done a reproduction following "Setting up a load balancer using Google-managed SSL certificates".The only time I was able to reproduce this issue (to get the same error) where there was no entry of the HTTP(S) LB IP as an A record in the designated domain. In this scenario, the managed status was PROVISIONING and domain status was showing 'FAILED_NOT_VISIBLE'.

You can use the following command to get this information:

$ gcloud beta compute ssl-certificates list

As per GCP documentation, "The status FAILED_NOT_VISIBLE indicates that certificate provisioning failed for a domain because of a problem with DNS or the load balancing configuration. Make sure that DNS is configured so that the certificate's domain resolves to the IP address of the load balancer".

 So, to rectify this issue, I have created an A record with the domain name pointing to the HTTPS Load Balancer IP. Once I have done that the Managed status became  'ACTIVE', according to Google-managed SSL certificate resource domain status documentation.

It worth to mention that, for the certificate provisioning process to proceed, all of the following conditions must be met:

1) The DNS records for your domain must reference the IP address of your load balancer's target proxy,

2) Your target proxy must reference the Google-managed certificate resource.

3) Your load balancer configuration must be complete, including the creation of a forwarding rule.

In light of this, I would recommend reviewing this GCP documentation on Creating and Using SSL Certificates and follow the setup instruction accordingly.

[Kuba Bartel]

Hi Nur,

thanks for the detailed elaboration. I believe I've checked all mentioned steps. To be more specific:

- the tested domain is tiles.lbs.meteopress.cz

- backend is GCS bucket and CDN is enabled

- it is currently working with Let's encrypt certificate, see e.g. https://tiles.lbs.meteopress.cz/tiles/raster/cz/v0.1/8/136/8...@2x.png

- (as documentation suggests) I created new certificate that is google-managed beside the current (Let's encrypt) one

- new certificate is attached to the working proxy

- DNS A record is configured, see the example url (A record is actually a wildcard record but I also created A record for tiles.lbs.meteopress.cz specifically)

- I believe the configuration is complete due to working urls

Outputs of cli commands:

(meteopress-radars)$ gcloud beta compute ssl-certificates list
NAME                     TYPE          CREATION_TIMESTAMP             EXPIRE_TIME                    MANAGED_STATUS
lets-encrypt-wildcard-1                2018-07-25T15:51:40.987-07:00
lets-encrypt-wildcard-2  SELF_MANAGED  2018-10-19T13:02:44.298-07:00  2019-01-17T07:26:29.000-08:00
tiles-lbs-google         MANAGED       2018-10-20T14:59:21.978-07:00                                 PROVISIONING
    tiles.lbs.meteopress.cz: FAILED_NOT_VISIBLE

(meteopress-radars)$ gcloud compute target-https-proxies describe meteopress-services-lb-target-proxy-2
creationTimestamp: '2018-07-25T15:52:00.040-07:00'
id: '8625586705454678527'
kind: compute#targetHttpsProxy
name: meteopress-services-lb-target-proxy-2
quicOverride: ENABLE
selfLink: https://www.googleapis.com/compute/v1/projects/meteopress-radars/global/targetHttpsProxies/meteopress-services-lb-target-proxy-2
sslCertificates:
- https://www.googleapis.com/compute/v1/projects/meteopress-radars/global/sslCertificates/lets-encrypt-wildcard-2
- https://www.googleapis.com/compute/v1/projects/meteopress-radars/global/sslCertificates/tiles-lbs-google
urlMap: https://www.googleapis.com/compute/v1/projects/meteopress-radars/global/urlMaps/meteopress-services-lb

Could it be somehow related to the fact that I'm attaching new managed certificate to already existing proxy?

[mebad...@google.com]

I reproduced the issue at my end by setting up an HTTPS load balancer using SSL certificate and was able to add the certificate to the load balancer. But it took some time for the settings to take effect, approximately five minutes. It seems like your issue might be related to attaching the new managed certificate to already existing one. If you still not able to do this, then I would suggest you to create a PIT for this, and we will investigate this.

On Wednesday, October 24, 2018 at 8:25:14 AM UTC-4, Kuba Bartel wrote:

[Andrew]

I'm getting the same issue, I have done everything listed in the documentation, but still getting a FAILED_NOT_VISIBILE status for the domain. I set up the load balancer yesterday, but didn't update the A host record to point to load balancer until today. Will the load balancer automatically retry, since it's been failing for almost a day? What can I do to resolve this? Thanks

[Md (Google Cloud Support)]

The certificate provisioning failed ( error: FAILED_NOT_VISIBLE) for a domain is due to the misconfiguration of DNS. The certificate’s domain is not resolving to the IP address of the load balancer.

- Make sure A record maps a domain name to the IP address (IPv4) of the server hosting the domain. Your dns A record should map your domain names to the IP of HTTPS load balancer.

- - Make sure target proxy is referencing the Google-managed certificate resource and there is proper configuration in load balancer including forwarding rule.

[Andrew]

I got it working now. I think the issue was that it was taking a long time for my DNS A record changes to propagate.

[Nicholas Martin]

I came to this forum because we experienced a simliar issue. In our case the issue was that the challenge certificate Google issue is an ECDSA one, and we had disallowed the _ECDSA_ cipher suites. This meant the load balancer was unable to serve it to Let's Encrypt.

Once we enabled an ECDSA cipher suite (that the Let's Encrypt RA system also supports for TLS) the provisioning and renewal processes succeeded.

(thanks to Google Support for helping us with this).

#eSourcing - More than just software

Registered in England and Wales, # 7332766. 11 Wolseley Road, Bishopston, Bristol, BS7 8EL.

Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify us immediately. If you or your employer does not consent to Internet email messages of this kind, please advise us. Opinions, conclusions and other information expressed in this message are not given or endorsed by my firm unless otherwise indicated by an authorised representative independent of this message.