Cert-manager: Cluster Issuer is not found

[zhaochenglan]

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:
A clear and concise description of what the bug is.

I created a Issuer of cloudflare ,but not found in k8s

edgar.zhao@edgarzhao-2 ~/data/strikingly/eosx_deploy/cert-manager/eosscan # cat cloudflare_ssl_dns.yaml
apiVersion: cert-manager.io/v1alpha2
kind: Issuer
metadata:
  name: letsencrypt-prod-cloudflare
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-prod-cloudflare
    solvers:
    - selector: {}
      dns01:
        cloudflare:
          email: [email protected]
          apiKeySecretRef:
            name: cloudflare-credentials
            key: secret-access-key

edgar.zhao@edgarzhao-2 ~/data/strikingly/eosx_deploy/cert-manager/eosscan # kubectl create -f cloudflare_ssl_dns.yaml
issuer.cert-manager.io/letsencrypt-prod-cloudflare created
edgar.zhao@edgarzhao-2 ~/data/strikingly/eosx_deploy/cert-manager/eosscan # kubectl get Issuer --all-namespaces
No resources found.

Expected behaviour:
A concise description of what you expected to happen.

Steps to reproduce the bug:
Steps to reproduce the bug should be clear and easily reproducible to help people
gain an understanding of the problem.

Anything else we need to know?:

Environment details::

• Kubernetes version (e.g. v1.10.2):

1.12.10-gke.17

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

helm install \
  --name cert-manager \
  --namespace cert-manager \
  --set ingressShim.defaultIssuerKind=ClusterIssuer \
  --set ingressShim.defaultIssuerName=letsencrypt-prod \
  --set webhook.enabled=false \
  --version v0.12.0-beta.1 \
  jetstack/cert-manager

/kind bug

[emas80]

I have a similar problem with a cloudflare cluster issuer.
I have created the two cluser issuers, if I run
kubectl get clusterissuer
I can see both

But even if I specify to use the cloudflare one by using the ingress annotation, the other one is used, as if the cloudflare one was completely ignored.

I have also tried removing the other one, and nothing works, as it's like if the cloudflare issuer does not exist.

I've tried to put multiple solvers - http01 and dns01, with all the possible combination of selectors, and I cannot make the cloudflare one working.
Even specifying it as a unique resolver does not work, it's as if I do not have any resolver set up.

I'm using version 0.11.0 of Cert Manager.

[walterdolce]

Same here on a GKE cluster (master 1.12.10-gke.17, nodes 1.12.8-gke.10). For me it's happening for a ClusterIssuer, though.

How could we troubleshoot this? I found no documentation anywhere on the docs website.

[walterdolce]

After investigating this, turns out my ClusterIssuer had already been there since I first created it.

However, I had two sets of cert-manager related CRDs setup on the cluster and it might have confused kubectl.

This is what my environment looked like before I had to manually delete the old cert-manager CRDs to be able to see the ClusterIssuer returned by kubectl. Please see https://github.com/kubernetes/kubernetes/65818#issuecomment-557520865

[JoshVanL]

What is most likely being seen in all cases is having multiple grouos of CRDs installed in a cluster (we changed the group from certmanager.k8s.io to cert-manager.io. These resources have aliases for use with kubectl. When multiple CRDs of different groups are installed that use the same short names kubectl may be referencing the resource with the wrong group.

If you try kubectl get cert-manager.io.Issuers --all-namespace you should see the resources available.

To fix this, delete the old CRDs from your cluster.
kubectl delete -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.10/deploy/manifests/00-crds.yaml

Just ensure you are running >v0.11 and all your resources have move to the new group otherwise this is a destructive operation.

[Raghubalam]

I'm having issue with letsencrypt prod, the tls-secret that it creates should not have tls.crt empty, ca.crt shows empty too in working clusters so I think that may be fine. However, the empty tls.crt field is definitively the one causing Nginx to use fake certificate.

Cert-manager:

helm install \
cert-manager \
--namespace ingress-public \
--version v0.13.0 \
jetstack/cert-manager

cluster-issuer.yaml

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: [email protected]
privateKeySecretRef:
name: letsencrypt-prod
solvers:
- http01:
ingress:
class: nginx

The app is having issues because cert is invalid/fake. Help needed!

[bbearce]

@Raghubalam, I'm seeing the same thing. I'm trying to follow this tutorial and I'm getting hung up at the certificate part. Actually everything deploys fine, and I can even see my site (below). However the cert is fake and is not allowing a smooth https experience.

cluster-issuer.yaml:

apiVersion: cert-manager.io/v1beta
kind: ClusterIssuer
metadata:
  # name: letsencrypt-staging
  name: letsencrypt-prod
spec:
  acme:
    email: [email protected]
    # server: https://acme-staging-v02.api.letsencrypt.org/directory
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      # name: letsencrypt-staging
      name: letsencrypt-prod
    solvers:
    - http01:
        ingress:
          class: nginx

This link has
Spec: Issuer Ref: Group: cert-manager.io Kind: ClusterIssuer Name: letsencrypt-production
whereas we have
Spec: Issuer Ref: Group: cert-manager.io Kind: ClusterIssuer Name: letsencrypt-prod
...to the experts, would this matter? Also @Raghubalam you have "cert-manager.io/v1alpha2" and I'm using "cert-manager.io/v1beta1". I'm really new to this (Kubernetes), but I need to get this cert issue figured out.