Cert-manager: JWS verification error

[christianhuening]

Bugs should be filed for issues encountered whilst operating cert-manager.
You should first attempt to resolve your issues through the community support
channels, e.g. Slack, in order to rule out individual configuration errors.
Please provide as much detail as possible.

Describe the bug:
We deployed Cert-Manager 0.6.0 onto a new cluster and reused our config from another cluster. We use http challenge and the nginx-ingress annotations for automatic Let's Encrypt certificate issueing. While some certificates are retrieved just fine, for one we get repeated errors, which we do not understand atm.
Error is:
Re-queuing item "goldpinger/goldpinger-tls-3032880182" due to error processing: error creating new order: acme: urn:ietf:params:acme:error:malformed: JWS verification error

Expected behaviour:
the certificate gets issued just fine

Anything else we need to know?:

Environment details::

• Kubernetes version (e.g. v1.10.2): 1.13.2
• Cloud-provider/provisioner (e.g. GKE, kops AWS, etc): bare-metal
• cert-manager version (e.g. v0.4.0): v0.6.0
• Install method (e.g. helm or static manifests): helm

/kind bug

[munnerz]

I imagine this is due to the cached account URI on your Certificate resource being invalid, and cert-manager's caching then not invalidating and refreshing the account information properly.

Can you see any messages similar to Skipping re-verifying ACME account as cached registration details look sufficient. for your Issuer in the logs anywhere?

If yes, can you share the output (including account URI) of kubectl get issuer -o yaml <issuer-name>

[christianhuening]

Yes we see those messages. Before I share things: Could it simply be a problem that we use the same config and account we also use on our other cluster? we have two clusters, one for prod and one for dev and just copied over the config. Doesn't cert-manager create a private key upon startup which is then different?

[munnerz]

This shouldn't make a difference, although I do wonder if you copied across the accounts private key between the two clusters too?

[christianhuening]

Alright we forgot to copy the secret, that solved the issue. thanks!

[EIrwin]

Seeing this same issue. It's a new cluster, so not sure what the fix would be for this.

[christianhuening]

@EIrwin did you use the same config and creds on another cluster before?

[gvuyk]

Stumbled upon this today after upgrading from 0.5.2 to 0.6.2 (which actually seems to be 0.6.6 with helm :see_no_evil:)
Issue went away when I re-created the cluster issuer

[goloxxly]

We've seen the same issue with cert-manager chart version v0.6.6 after completely re-installing a chart that contained ingresses. Deleting and re-creating the ClusterIssuers solved the problem.

[drewwells]

Can we get better error messaging for expired clusterissuer? I've run into this multiple times and this issue is the only mention of the problem.

[bazouie]

We've got the same issue. Do you think, rebooting the cert-manager would solve the issue? or I have to delete and re-create the ClusterIssure?