Creating a ManagedCertificate results in "Status: FailedNotVisible"

4/15/2019

Using Kubernetes 1.12.6-gke.7 or higher it is possible to create a ManagedCertificate which is then referenced from an Ingress Resource exposing a Service to the Internet.

Running kubectl describe managedcertificate certificate-name first indicates the certificate is in a Provisioning state but eventually goes to FailedNotVisible.

Despite using a Static IP and DNS that resolves fine to the http version of said service all ManagedCertificate's end up in a "Status: FailedNotVisible" state.

Outline of what I am doing:

  1. Generating a reserved (static) external IP Address

  2. Configuring DNS A record in CloudDNS to subdomain.domain.com to generated IP address from step 1.

  3. Creating a ManagedCertificate named "subdomain-domain-certificate" with kubectl apply -f with spec:domains containing a single domain corresponding to subdomain.domain.com DNS record in step 2.

  4. Creating a simple deployment and service exposing it
  5. Creating Ingress resource referring to default backend of service in step 4 as well as annotations for static ip created in step 1 and managed certificate generated in step 3.
  6. Confirm that Ingress is created and is assigned static IP
  7. Visiting http://subdomain.domain.com serves the output from pod created in deployment in step 4

After a little while

kubectl describe managedcertificate subdomain-domain-certificate

results in "Status: FailedNotVisible".

Name:         subdomain-domain-certificate
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1beta1
Kind:         ManagedCertificate
Metadata:
  Creation Timestamp:  2019-04-15T17:35:22Z
  Generation:          1
  Resource Version:    52637
  Self Link:           /apis/networking.gke.io/v1beta1/namespaces/default/managedcertificates/subdomain-domain-certificate
  UID:                 d8e5a0a4-5fa4-11e9-984e-42010a84001c
Spec:
  Domains:
    subdomain.domain.com
Status:
  Certificate Name:    mcrt-ac63730e-c271-4826-9154-c198d654f9f8
  Certificate Status:  Provisioning
  Domain Status:
    Domain:  subdomain.domain.com
    Status:  FailedNotVisible
Events:
  Type    Reason  Age   From                            Message
  ----    ------  ----  ----                            -------
  Normal  Create  56m   managed-certificate-controller  Create SslCertificate mcrt-ac63730e-c271-4826-9154-c198d654f9f8

From what I understand if the Load Balancer is configured correctly (done under the hood in the ManagedCertificate resource) and the DNS (which resolves fine to the non https endpoint) checks out the certificate should go in to a Status: Active state?

-- Smith
google-kubernetes-engine
https
tls1.2

3 Answers

5/21/2019

You need to make sure the domain name resolves to the IP address of your GKE Ingress, following the directions for "creating an Ingress with a managed certificate" exactly.

For more details, see the Google Cloud Load Balancing documentation. From https://cloud.google.com/load-balancing/docs/ssl-certificates#domain-status:

"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."

-- Evan Jones
Source: StackOverflow

4/16/2019

The issue underlying my problem ended up being a DNSSEC misconfiguration. After running the DNS through https://dnssec-analyzer.verisignlabs.com/ I was able to identify and fix the issue.

-- Smith
Source: StackOverflow

1/24/2020

DNSSEC was indeed not enabled for my domain but after configuring that, the ManagedCertificate configuration was still not going through and I had no clue what was going on. Deleting and re-applying the ManagedCertificate and Ingress manifests did not do the trick. But issuing the command gcloud beta compute ssl-certificates list showed several unused managed certificates hanging around and deleting them with cloud compute ssl-certificates delete NAME ..., and then restarting the configuration process did the trick in my case.

-- Bjorn Thor Jonsson
Source: StackOverflow