Error using Let's Encrypt in Ingress:Issuing certificate as Secret does not exist using

1/26/2021

I followed this tutorial https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-with-cert-manager-on-digitalocean-kubernetes to issue a SSL certificate for my ingress using cert manager and Let's encrypt and I run this error Issuing certificate as Secret does not exist. Is my configuration wrong? It's a Minikube local cluster.

staging_issuer.yaml

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
 name: letsencrypt-staging
 namespace: cert-manager
spec:
 acme:
   # The ACME server URL
   server: https://acme-staging-v02.api.letsencrypt.org/directory
   # Email address used for ACME registration
   email: email_address
   # Name of a secret used to store the ACME account private key
   privateKeySecretRef:
     name: letsencrypt-staging
   # Enable the HTTP-01 challenge provider
   solvers:
   - http01:
       ingress:
         class:  nginx

ingress.yaml

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: echo-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/proxy-read-timeout: "12h"
    cert-manager.io/cluster-issuer: "letsencrypt-staging"
spec:
  tls:
  - hosts:
    - frontend.info
    - backend.info
    secretName: echo-tls
  rules:
  - host: frontend.info
    http:
      paths:
      - backend:
          serviceName: frontend
          servicePort: 80
  - host: backend.info
    http:
      paths:
      - backend:
          serviceName: backend
          servicePort: 8080

kubectl describe certificate

Name:         echo-tls
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  cert-manager.io/v1beta1
Kind:         Certificate
Metadata:
  Creation Timestamp:  2021-01-26T09:29:54Z
  Generation:          1
  Managed Fields:
    API Version:  cert-manager.io/v1alpha2
    Fields Type:  FieldsV1
    Manager:    controller
    Operation:  Update
    Time:       2021-01-26T09:29:55Z
  Owner References:
    API Version:           extensions/v1beta1
    Block Owner Deletion:  true
    Controller:            true
    Kind:                  Ingress
    Name:                  echo-ingress
    UID:                   <UID>
  Resource Version:        423812
  UID:                     <UID>
Spec:
  Dns Names:
    frontend.info
    backend.info
  Issuer Ref:
    Group:      cert-manager.io
    Kind:       ClusterIssuer
    Name:       letsencrypt-staging
  Secret Name:  echo-tls
Status:
  Conditions:
    Last Transition Time:        2021-01-26T09:29:54Z
    Message:                     Issuing certificate as Secret does not exist
    Reason:                      DoesNotExist
    Status:                      True
    Type:                        Issuing
    Last Transition Time:        2021-01-26T09:29:54Z
    Message:                     Issuing certificate as Secret does not exist
    Reason:                      DoesNotExist
    Status:                      False
    Type:                        Ready
  Next Private Key Secret Name:  echo-tls-hg5tt
Events:
  Type    Reason     Age    From          Message
  ----    ------     ----   ----          -------
  Normal  Issuing    7h56m  cert-manager  Issuing certificate as Secret does not exist
  Normal  Generated  7h56m  cert-manager  Stored new private key in temporary Secret resource "echo-tls-hg5tt"
  Normal  Requested  7h56m  cert-manager  Created new CertificateRequest resource "echo-tls-hmz86
-- efgdh
kubernetes
kubernetes-ingress
lets-encrypt
minikube
ssl

2 Answers

1/27/2021

Let' start from answering your question about the event:

Events:
  Type    Reason     Age    From          Message
  Normal  Issuing    7h56m  cert-manager  Issuing certificate as Secret does not exist

This is not an error and it is not a blocking factor. As you can see in the type section this is marked as Normal. The events type that you should worry about are Warning events, like here:

Events:
  Type     Reason     Age                From                                                    Message
  Warning  Unhealthy  2m (x2 over 2m)    kubelet, ip-XXX-XXX-XXX-XXX.us-west-2.compute.internal  Readiness probe failed: Get http://XXX.XXX.XXX.XXX:YYY/healthz: dial tcp connect: connection refused

Now coming to your real problem. The documentation that you provided clearly states in prerequisites section that you need to have a domain name and a DNS A record pointing to the DigitalOcean Load Balancer used by the Ingress (in your case you would want to point it towards minikube). Assuming you are the owner of the two domains you mentioned in the yamls I noticed that they points to a two different ip address:

$ dig frontend.info
;; ANSWER SECTION:
frontend.info.          599     IN      A       104.247.81.51
$ dig backend.info
;; ANSWER SECTION:
backend.info.           21599   IN      A       127.0.0.1

Domain has to point to external-ip address of a machine where minikube is running (in my case it was cloud virtual machine). Having this, it is sill not enough since minikube typically runs in its own docker container or vm. You need to make sure the traffic actually reaches your minikube cluster.

For that purpose I have used kubectl port-fowarding to expose the nginx-controller pod:

sudo kubectl port-forward pod/ingress-nginx-controller-69ccf5d9d8-mdkrr -n kube-system 80:80 --address 0.0.0.0

Forwarding from 0.0.0.0:80 -> 80 

Let's encrypt needs to have access to your application to prove that you are the owner of the domain. Once this is achieved your certificate object will change it status to True:

  ~ k get certificate                        
NAME       READY   SECRET     AGE
echo-tls   True    echo-tls   104m

Here you have final test. Please note that I was using my own domain which I just changed into <your-domain>. In your case this would frontend.info or backend.info

➜  ~ curl https://<your-domain> -v         
-----
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=test-domain.com
*  start date: Jan 27 10:09:31 2021 GMT
*  expire date: Apr 27 10:09:31 2021 GMT
*  subjectAltName: host "<your-domain>" matched cert's "<your-domain>"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
-----
-- acid_fuji
Source: StackOverflow

1/29/2021

I am also stuck there. But looking around, it seems that this website keeps popping up https://cert-manager.io/docs/faq/troubleshooting/

I am now trying to troubleshoot it myself. If I can fix it, I'll post the answer.

-- mazzespazze
Source: StackOverflow