CODEWITHSUNDEEP
sslkubernetesgoogle-kubernetes-enginegcloudkubernetes-ingress
Viktor Hedefalk
Viktor Hedefalk

Reputation: 3914

gcloud managedcertificate provisioning fails with FailedNotVisible

I've followed the instructions on

https://cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs

to setup a new ssl certificate to us in a gke lb ingress.

The cert:

apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: mydomain.se-certificate
spec:
  domains:
    - sub.mydomain.se

The ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: myip-se
    networking.gke.io/managed-certificates: mydomain.se-certificate
    kubernetes.io/ingress.class: "gce"
    kubernetes.io/ingress.allow-http: "true"
spec:
  rules:
    - host: sub.mydomain.se
      http:
        paths:
        - pathType: ImplementationSpecific
          path: "/"
          backend:
            service:
              name:  my-service
              port: 
                number: 8080

Still the hostname always fails with FAILED_NOT_VISIBLE

I've had success with this setup before and have running apps using this since a couple of years when I moved from LetsEncrypt certs to the google ones. These are still running fine with very similar setup albeit in beta apiVersions. But inspecting they look just the same. The only thing I'm thinking of is that there's something with the backing app that might be the culprit.

The backing app is a service that should not be used over http, only https. By k8s necessity, have a "/healthz"-endpoint served over http but anything else goes to an early https redirect.

So I'm wondering what the provisioning details are. I found this in the docs:

If you are using the annotation networking.gke.io/managed-certificates you cannot use the annotation kubernetes.io/ingress.allow-http: false. You can update the Ingress and add the annotation kubernetes.io/ingress.allow-http: false only after the external HTTP(S) load balancer is fully programmed.

I have not disallowed http, but I am doing https redirects in the serving deployment for everything but the health-check path. I'm therefore thinking along the lines that the provisioning maybe demands a 2xx response on the actual nodeport and fails because of 3xx. Could this be?

Longshot and super-weird if so, but I'm grasping for straws.

Upvotes: 1

Views: 1092

Answers (1)

Woodrow K.
Woodrow K.

Reputation: 111

Without knowing what else is on your GCP project or VPC, there can be several scenarios where a Google-managed certificate will not provision. I'll share the fix that worked in my case and may apply to you as well.

If your DNS record happens to include an AAAA record (IPv6), then you must also include that address on a load balancer with the same Google-managed certificate you want to provision.

From my experience with this problem, the project happened to have a vestigial load balancer configured with the IPv6 address of the domain, which had been set up by someone else and I had been ignoring as I was only working with the IPv4 address. Getting rid of the other load balancer and adding the IPv6 address to my new load balancer resolved the issue with provisioning a Google-managed certificate.

Google now has some specific documentation on the scenario here. That documentation page was updated yesterday (possibly in response to the GCP support ticket I submitted two days ago) before which the only clue was a hard to find sentence on the SSL troubleshooting page describing FAILED_NOT_VISIBLE.

Upvotes: 2

Related Questions