Error checking existing TLS certificate #339

WB3Tech · 2018-02-22T22:28:05Z

Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug

What happened:
Attempting to install certificate and receive the following message:
Error checking existing TLS certificate: no data for "tls.crt" in secret

When I check the secret, there is only a tls.key

I deleted all the objects, then attempted to create again. Before I created the certificate, I check the secret after the issuer was created, there was only a tls.key in there as well.

I'm using ACME with http01. I have also tried dns01 with clouddns, and I receive the same messages.

I was able to get everything to work with a CA.

Anything else we need to know?:
Attempting to find out what the issue is, possibly something i'm doing wrong?

Environment:

Kubernetes version 1.8.6
GKE

apiVersion: certmanager.k8s.io/v1alpha1
kind: Issuer
metadata:
  name: clatsch
  namespace: default
spec:
  acme:
    email: [removed email address]
    server: https://acme-v01.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: clatsch-com-tls
    http01: {}

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: clatsch-com
  namespace: default
spec:
  secretName: clatsch-com-tls
  issuerRef:
    name: lets-encrypt
    kind: Issuer
  commonName: clatsch.com
  dnsNames:
  - www.clatsch.com
  - www.k8s.clatsch.com
  - k8s.clatsch.com
  acme:
    config:
    - http01:
        ingressClass: nginx
      domains:
      - clatsch.com
      - www.clatsch.com
      - www.k8s.clatsch.com
      - k8s.clatsch.com
    - http01:
        ingress: hellok8s
      domains:
      - clatsch.com
      - www.clatsch.com
      - www.k8s.clatsch.com
      - k8s.clatsch.com

The text was updated successfully, but these errors were encountered:

munnerz · 2018-02-22T22:29:48Z

That is not an actual error - it is expected during the normal validation flow. Can you provide additional logs and details of your environment?

Namely, the output of kubectl describe certificate,issuer,clusterissuer --all-namespaces and if possible, the cert-manager logs too.

WB3Tech · 2018-02-22T22:34:41Z

@munnerz , Here is the output from kubectl describe certificate,issuer,clusterissuer --all-namespaces.

Name:         clatsch-com
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  certmanager.k8s.io/v1alpha1
Kind:         Certificate
Metadata:
  Cluster Name:
  Creation Timestamp:  2018-02-22T22:24:06Z
  Resource Version:    59977
  Self Link:           /apis/certmanager.k8s.io/v1alpha1/namespaces/default/certificates/clatsch-com
  UID:                 18193202-181f-11e8-82f9-42010a800079
Spec:
  Acme:
    Config:
      Domains:
        clatsch.com
        www.clatsch.com
        www.k8s.clatsch.com
        k8s.clatsch.com
      Http 01:
        Ingress Class:  nginx
      Domains:
        clatsch.com
        www.clatsch.com
        www.k8s.clatsch.com
        k8s.clatsch.com
      Http 01:
        Ingress:  hellok8s
  Common Name:    clatsch.com
  Dns Names:
    www.clatsch.com
    www.k8s.clatsch.com
    k8s.clatsch.com
  Issuer Ref:
    Kind:       Issuer
    Name:       clatsch
  Secret Name:  clatsch-com-tls
Events:
  Type     Reason                 Age               From                     Message
  ----     ------                 ----              ----                     -------
  Warning  ErrorCheckCertificate  1m (x17 over 7m)  cert-manager-controller  Error checking existing TLS certificate: no data for "tls.crt" in secret 'default/clatsch-com-tls'

Name:         clatsch
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  certmanager.k8s.io/v1alpha1
Kind:         Issuer
Metadata:
  Cluster Name:
  Creation Timestamp:  2018-02-22T22:20:12Z
  Generation:          0
  Resource Version:    59317
  Self Link:           /apis/certmanager.k8s.io/v1alpha1/namespaces/default/issuers/clatsch
  UID:                 8cb08240-181e-11e8-82f9-42010a800079
Spec:
  Acme:
    Email:  [removed]
    Http 01:
    Private Key Secret Ref:
      Key:
      Name:  clatsch-com-tls
    Server:  https://acme-v01.api.letsencrypt.org/directory
Status:
  Acme:
    Uri:  https://acme-v01.api.letsencrypt.org/acme/reg/29943805
  Conditions:
    Last Transition Time:  2018-02-22T22:20:15Z
    Message:               The ACME account was registered with the ACME server
    Reason:                ACMEAccountRegistered
    Status:                True
    Type:                  Ready
Events:                    <none>

Here is a copy of a log entry, they are all the same:

{
 insertId:  "19so4gfg1h6hj2z"  
 jsonPayload: {
  apiVersion:  "v1"   
  involvedObject: {
   apiVersion:  "certmanager.k8s.io"    
   kind:  "Certificate"    
   name:  "clatsch-com"    
   namespace:  "default"    
   resourceVersion:  "59977"    
   uid:  "18193202-181f-11e8-82f9-42010a800079"    
  }
  kind:  "Event"   
  message:  "Error checking existing TLS certificate: no data for "tls.crt" in secret 'default/clatsch-com-tls'"   
  metadata: {
   creationTimestamp:  "2018-02-22T22:24:06Z"    
   name:  "clatsch-com.1515c615cbee42a3"    
   namespace:  "default"    
   resourceVersion:  "2027"    
   selfLink:  "/api/v1/namespaces/default/events/clatsch-com.1515c615cbee42a3"    
   uid:  "181c490a-181f-11e8-82f9-42010a800079"    
  }
  reason:  "ErrorCheckCertificate"   
  source: {
   component:  "cert-manager-controller"    
  }
  type:  "Warning"   
 }
 logName:  "projects/clatsch-discover-18/logs/events"  
 receiveTimestamp:  "2018-02-22T22:35:06.661334792Z"  
 resource: {
  labels: {
   cluster_name:  "clatsch-production"    
   location:  ""    
   project_id:  "clatsch-discover-18"    
  }
  type:  "gke_cluster"   
 }
 severity:  "WARNING"  
 timestamp:  "2018-02-22T22:35:01Z"  
}

WB3Tech · 2018-02-23T11:35:07Z

@munnerz, I let it run over night to see if anything would come of it. It still shows that same error, here is a describe output of the certificate object:

Name:         clatsch-com
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  certmanager.k8s.io/v1alpha1
Kind:         Certificate
Metadata:
  Cluster Name:
  Creation Timestamp:  2018-02-22T23:22:54Z
  Resource Version:    69933
  Self Link:           /apis/certmanager.k8s.io/v1alpha1/namespaces/default/certificates/clatsch-com
  UID:                 4f685462-1827-11e8-879d-42010a8000f7
Spec:
  Common Name:  clatsch.com
  Dns Names:
    www.clatsch.com
    www.k8s.clatsch.com
    k8s.clatsch.com
  Issuer Ref:
    Kind:       Issuer
    Name:       clatsch
  Secret Name:  clatsch-com-tls
Events:
  Type     Reason                 Age                From                     Message
  ----     ------                 ----               ----                     -------
  Warning  ErrorCheckCertificate  8m (x61 over 12h)  cert-manager-controller  Error checking existing TLS certificate: no data for "tls.crt" in secret 'default/clatsch-com-tls'

munnerz · 2018-02-23T11:49:14Z

It seems you've specified both the ingress field as well as ingressClass:

      Domains:
        clatsch.com
        www.clatsch.com
        www.k8s.clatsch.com
        k8s.clatsch.com
      Http 01:
        Ingress Class:  nginx
      Domains:
        clatsch.com
        www.clatsch.com
        www.k8s.clatsch.com
        k8s.clatsch.com
      Http 01:
        Ingress:  hellok8s

one or the other should be used - not both. This influences how cert-manager validates your ownership of the domain. For more info, see: https://github.com/jetstack/cert-manager/blob/master/docs/user-guides/acme-http-validation.md

Namely:

The fields ingress and ingressClass in the http01 stanza can be used to control how cert-manager interacts with Ingress resources:

* If the ingress field is specified, then an Ingress resource with the same name in the same namespace as the Certificate must already exist and it will be modified only to add the appropriate rules to solve the challenge. This field is useful for the GCLB ingress controller, as well as a number of others, that assign a single public IP address for each ingress resource. Without manual intervention, creating a new ingress resource would cause any challenges to fail.

* If the ingressClass field is specified, a new ingress resource with a randomly generated name will be created in order to solve the challenge. This new resource will have an annotation with key kubernetes.io/ingress.class and value set to the value of the ingressClass field. This works for the likes of the NGINX Ingress controller.

* If neither are specified, new ingress resources will be created with a randomly generated name, but they will not have the ingress class annotation set.

* If both are specified, then the ingress field will take precedence.

WB3Tech · 2018-02-26T18:22:38Z

@munnerz , thank you for pointing this out.

I tried splitting them apart, and still got the same outcome. Below are my configs. Based on the examples, I cannot see what the issue is. Am I missing something which is staring me in the face?

I have an ingress controller setup with the name 'hellok8s'.

apiVersion: certmanager.k8s.io/v1alpha1
kind: Issuer
metadata:
  name: clatsch
  namespace: default
spec:
  acme:
    server: https://acme-v01.api.letsencrypt.org/directory
    email: [removed email]
    privateKeySecretRef:
      name: clatsch-com-tls
    http01: {}

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: clatsch-cert
spec:
  secretName: clatsch-com-tls
  issuerRef:
    name: clatsch
  dnsNames:
  - clatsch.com
  - www.clatsch.com
  - k8s.clatsch.com
  - www.k8s.clatsch.com
  acme:
    config:
    - http01:
        ingress: hellok8s
      domains:
      - clatsch.com
      - www.clatsch.com
      - k8s.clatsch.com
      - www.k8s.clatsch.com

whereisaaron · 2018-02-26T19:18:25Z

Eh, looks like you are trying to use the same Secret 'clatsch-com-tls' for this Certificate and also for your Issuer secret key? That will end in tears 😄

The Issuer secret is the same for all Certificates from that ACME Issuer (e.g. Let's Encrypt) and stored separate from any of the Certificates that are issued. One 'Issuer' with one Secret issues Many 'Certificates' each with their own Secret.

WB3Tech · 2018-02-27T00:39:01Z

@whereisaaron Ah! Thanks, that makes sense now. Not sure how I crossed those wires.

Do I need to have some existing data in the secret (clatsch-com-tls)? I noticed that if I do not create an empty secret, the certificate events look like they process successfully, except there comes a point where it states "cannot find secret clatsch-com-tls." When I create a generic secret before hand, I get:

Error checking existing TLS certificate: no data for "tls.crt" in secret 'default/clatsch-com-tls'

Which is the correct method to dealing with the secret (clatsch-com-tls)?

The lets encrypt url i'm using is

https://acme-v01.api.letsencrypt.org/directory

WB3Tech · 2018-02-27T02:13:38Z

I removed all the old artifacts and re-ran the processes, and all works. thanks @munnerz and @whereisaaron !

whereisaaron · 2018-02-27T03:58:56Z

@WB3Tech great it is working! You don't need to create the Issuer or Certificate Secrets yourself.

The Issuer is Secret will be created when cert-manager registers your account and email address with Let's Encrypt. You shouldn't create it yourself, that will probably only causes problems. If you see problems, you are probably best to delete the Issuer Secret and let cert-manager recreate it.

jetstack-bot added the kind/bug Categorizes issue or PR as related to a bug. label Feb 22, 2018

WB3Tech closed this as completed Feb 27, 2018

ZigZagT pushed a commit to ZigZagT/Networking that referenced this issue Aug 7, 2018

bug fix, thanks to cert-manager/cert-manager#339

1f74745

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Error checking existing TLS certificate #339

Error checking existing TLS certificate #339

WB3Tech commented Feb 22, 2018 •

edited

munnerz commented Feb 22, 2018

WB3Tech commented Feb 22, 2018 •

edited

WB3Tech commented Feb 23, 2018

munnerz commented Feb 23, 2018

WB3Tech commented Feb 26, 2018 •

edited

whereisaaron commented Feb 26, 2018

WB3Tech commented Feb 27, 2018 •

edited

WB3Tech commented Feb 27, 2018

whereisaaron commented Feb 27, 2018

Error checking existing TLS certificate #339

Error checking existing TLS certificate #339

Comments

WB3Tech commented Feb 22, 2018 • edited

munnerz commented Feb 22, 2018

WB3Tech commented Feb 22, 2018 • edited

WB3Tech commented Feb 23, 2018

munnerz commented Feb 23, 2018

WB3Tech commented Feb 26, 2018 • edited

whereisaaron commented Feb 26, 2018

WB3Tech commented Feb 27, 2018 • edited

WB3Tech commented Feb 27, 2018

whereisaaron commented Feb 27, 2018

WB3Tech commented Feb 22, 2018 •

edited

WB3Tech commented Feb 22, 2018 •

edited

WB3Tech commented Feb 26, 2018 •

edited

WB3Tech commented Feb 27, 2018 •

edited