Cert-manager: Letsencrypt V02 endpoint: Failed to determine order status: unrecognised existing acme order status: "ready"

Created on 1 Jul 2018  路  5Comments  路  Source: jetstack/cert-manager

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind bug
/kind feature

What happened:
Creating Certificate Resource using Letsencrypt Acme V02 Prod Endpoint causes error:
Failed to determine order status: unrecognised existing acme order status: "ready"

What you expected to happen:
Certificate creation should succeed.
How to reproduce it (as minimally and precisely as possible):

# ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: ingress-static-ip
  labels:
    component: myapp
spec:
  backend:
    serviceName: myapp-svc
    servicePort: 8000
---
#  letsencrypt-issuer.yaml
apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: secret-key-name
    http01: {}
---
# certificate.yaml
apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: mydomain-com-certificate
  namespace: default
spec:
  secretName: secret-key-name
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  commonName: mydomain.com
  dnsNames:
  - mydomain.com
  acme:
    config:
    - http01:
        ingress: my-ingress
      domains:
      - mydomain.com

After running
kubectl apply -f thefileabove.yaml
I see the following in the cert-manager pod logs

I0630 21:34:24.891739       1 controller.go:166] ingress-shim controller: Finished processing work item "default/my-ingress"
I0630 21:35:20.960081       1 controller.go:177] certificates controller: syncing item 'default/mydomain-com-certificate'
I0630 21:35:20.960314       1 sync.go:239] Preparing certificate default/mydomain-com-certificate with issuer
I0630 21:35:20.960325       1 acme.go:159] getting private key (letsencrypt-prod->tls.key) for acme issuer kube-system/letsencrypt-prod
I0630 21:35:20.960642       1 logger.go:27] Calling GetOrder
I0630 21:35:21.077864       1 sync.go:241] Error preparing issuer for certificate default/mydomain-com-certificate: unrecognised existing acme order status: "ready"

Anything else we need to know?:
Appears to be a new status to the acme v2 endpoint added in May according to this certbot PR
Environment:

  • Kubernetes version (use kubectl version):
Client Version: version.Info{
      Major:"1", 
      Minor:"10", 
      GitVersion:"v1.10.3", 
      GitCommit:"2bba0127d85d5a46ab4b778548be28623b32d0b0", 
      GitTreeState:"clean", 
      BuildDate:"2018-05-28T20:03:09Z", 
      GoVersion:"go1.9.3", 
      Compiler:"gc", 
      Platform:"darwin/amd64"
}
Server Version: version.Info{
    Major:"1", 
    Minor:"10+", 
    GitVersion:"v1.10.4-gke.2", 
    GitCommit:"eb2e43842aaa21d6f0bb65d6adf5a84bbdc62eaf", 
    GitTreeState:"clean", 
    BuildDate:"2018-06-15T21:48:39Z", 
    GoVersion:"go1.9.3b4", 
    Compiler:"gc", 
    Platform:"linux/amd64"
}
  • Cloud provider or hardware configuration:
    GKE
  • Install tools:
    Helm, Tiller, cert-manager, kubernetes-dashboard
  • Others:
kinbug

All 5 comments

Is there a known work around for this? I'm my cert generation is failing because of this bug. should I create a new issuer on another API address?

@kyleterry as long as you're not generating wildcard certificates I think you should be able to just use the v01 endpoint and not the v02 one.

@programatt

status:
  conditions:
  - lastTransitionTime: 2018-07-03T22:30:03Z
    message: Your ACME server URL is set to a v1 endpoint (https://acme-v01.api.letsencrypt.org/directory).
      You should update the spec.acme.server field to "https://acme-v02.api.letsencrypt.org/directory"
    reason: InvalidConfig
    status: "False"
    type: Ready

Doesn't look like that will do the trick.

@kyleterry dang. I'm a new user of cert-manager so I'm not sure then. I just hope they get it in soon! One workaround that i've been using on mine to get the certs generated since I do need wildcards is just calling certbot on my local to get the certificate and manually uploading to the secret with kubectl. But obviously that "workaround" is basically not using cert-manager at all.

Fixed in #698 - v0.3.2 will be released shortly which will contain this patch!

Was this page helpful?
0 / 5 - 0 ratings