cert-manager after major update stopped working - kubernetes

The issue started after a major update of cert-manager from 0.6.0 to 0.11.0 version.
The update has been processed via config backup, cert-manager remove, helm update, then cert-manager install and backup restore. No config changes during the update.
Pod and service are up, but no certs issued after update.
There are logs for cert-manager service:
E0114 04:34:18.126497 1 sync.go:57] cert-manager/controller/ingress-shim "msg"="failed to determine issuer to be used for ingress resource" "error"="failed to determine issuer name to be used for ingress resource" "resource_kind"="Ingress" "resource_name"="ucb-sandbox-ingress" "resource_namespace"="cloud-engagement-sandbox"
I0114 04:34:18.126791 1 controller.go:135] cert-manager/controller/ingress-shim "level"=0 "msg"="finished processing work item" "key"="cloud-engagement-sandbox/ucb-sandbox-ingress"
I0114 04:34:18.127064 1 controller.go:129] cert-manager/controller/ingress-shim "level"=0 "msg"="syncing item" "key"="cloud-engagement-sandbox/ucf-sandbox-ingress"
E0114 04:34:18.127294 1 sync.go:57] cert-manager/controller/ingress-shim "msg"="failed to determine issuer to be used for ingress resource" "error"="failed to determine issuer name to be used for ingress resource" "resource_kind"="Ingress" "resource_name"="ucf-sandbox-ingress" "resource_namespace"="cloud-engagement-sandbox"
I0114 04:34:18.127534 1 controller.go:135] cert-manager/controller/ingress-shim "level"=0 "msg"="finished processing work item" "key"="cloud-engagement-sandbox/ucf-sandbox-ingress"
My ClusterIssuer yaml:
apiVersion: certmanager.k8s.io/v1alpha2
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: [removed]
privateKeySecretRef:
name: letsencrypt-prod
http01: {}
And describe ClusterIssuer letsencrypt-prod
ClusterIssuer letsencrypt-prod
Name: letsencrypt-prod
Namespace:
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"certmanager.k8s.io/v1alpha1","kind":"ClusterIssuer","metadata":{"annotations":{},"creationTimestamp":"2019-02-17T22:42:55Z"...
API Version: certmanager.k8s.io/v1alpha1
Kind: ClusterIssuer
Metadata:
Creation Timestamp: 2019-02-17T22:42:55Z
Generation: 1
Resource Version: 53383155
Self Link: /apis/certmanager.k8s.io/v1alpha1/clusterissuers/letsencrypt-prod
UID: 5e0c332f-3305-11e9-93cb-069443f5754c
Spec:
Acme:
Email: [removed]
Http 01:
Private Key Secret Ref:
Key:
Name: letsencrypt-prod
Server: https://acme-v02.api.letsencrypt.org/directory
Status:
Acme:
Uri: https://acme-v02.api.letsencrypt.org/acme/acct/51694394
Conditions:
Last Transition Time: 2019-02-17T22:42:57Z
Message: The ACME account was registered with the ACME server
Reason: ACMEAccountRegistered
Status: True
Type: Ready
Events: <none>

The apiVersion has been changed from certmanager.k8s.io/v1alpha1 to cert-manager.io/v1alpha2. But You still have CRD with old apiVersion which you need to remove.
Follow below steps to upgrade cert manager paying attention to
step 3 and 4.
1.Back up existing cert-manager resources, as per the backup and restore guide.
2.Uninstall cert-manager
3.Ensure the old cert-manager CRD resources have also been deleted: kubectl get crd | grep certmanager.k8s.io
4.Update the apiVersion on all your backed up resources from certmanager.k8s.io/v1alpha1 to cert-manager.io/v1alpha2.
5.Re-install cert-manager from scratch according to the installation guide
Here is the official upgrade guide

It's sorted. The culprit was in 1) incomplete cert-manager install.
2) Also I've modified backup and replaced ALL certmanager.k8s.io with cert-manager.io and v1alpha1 with v1alpha2.
3) manually deleted other related to certmanager.k8s.io CRDs

Thanks for reply.
I removed old CRD after helm purge cert-manager and installed a fresh version 0.12 using manifests.
My current CRD below:
kubectl get crd
NAME CREATED AT
certificaterequests.cert-manager.io 2019-11-01T01:37:03Z
certificates.cert-manager.io 2019-11-01T01:37:03Z
challenges.acme.cert-manager.io 2019-11-01T01:37:03Z
challenges.certmanager.k8s.io 2020-01-15T05:31:48Z
clusterissuers.cert-manager.io 2019-11-01T01:37:03Z
healthstates.azmon.container.insights 2019-08-29T10:13:59Z
issuers.cert-manager.io 2019-11-01T01:37:03Z
orders.acme.cert-manager.io 2019-11-01T01:37:03Z
orders.certmanager.k8s.io 2020-01-15T05:31:49Z
And updated description of ClusterIssuer
kubectl describe ClusterIssuer letsencrypt-prod
Name: letsencrypt-prod
Namespace:
Labels: <none>
Annotations: <none>
API Version: cert-manager.io/v1alpha2
Kind: ClusterIssuer
Metadata:
Creation Timestamp: 2020-01-15T05:38:32Z
Generation: 1
Resource Version: 71299934
Self Link: /apis/cert-manager.io/v1alpha2/clusterissuers/letsencrypt-prod
UID: 4465c9ce-3759-11ea-be9c-0a7022c023e8
Spec:
Acme:
Email:
Private Key Secret Ref:
Name: letsencrypt-prod
Server: https://acme-v02.api.letsencrypt.org/directory
Solvers:
Http 01:
Ingress:
Class: nginx
Selector:
Events: <none>
I don't have ingress under cert-manager namespace. Also, my backup includes old certificates, CRD, Issuers, Certs and Certs requests etc but I don't know how to restore just what needed.

Related

Cert-Manager get certificate, but web browser shows "Kubernetes Ingress Controller Fake Certificate"

I have an issue with Certificate from Let's Encrypt in Kubernetes in Azure AKS.
It seems to be valid in k8s, but web browsers shows "Kubernetes Ingress Controller Fake Certificate". Following steps from https://cert-manager.io/docs/troubleshooting/ to describe my state:
kubectl get certificates --all-namespaces
NAMESPACE NAME READY SECRET AGE
gap tls-secret True tls-secret 5h29m
kubectl get CertificateRequests --all-namespaces
NAMESPACE NAME APPROVED DENIED READY ISSUER REQUESTOR AGE
gap tls-secret-h8xvm True True letsencrypt-prod system:serviceaccount:ingress-basic:cert-manager 5h31m
kubectl get clusterissuer --all-namespaces
NAME READY AGE
letsencrypt-prod True 5h45m
kubectl describe clusterissuer letsencrypt-prod
...
Spec:
Acme:
Email: aaa#company.com
Preferred Chain:
Private Key Secret Ref:
Name: letsencrypt-prod
Server: https://acme-v02.api.letsencrypt.org/directory
Solvers:
http01:
Ingress:
Class: nginx
Pod Template:
Metadata:
Spec:
Node Selector:
kubernetes.io/os: linux
Status:
Acme:
Last Registered Email: aaa#company.com
Uri: https://acme-v02.api.letsencrypt.org/acme/acct/XXXXXXXX
Conditions:
Last Transition Time: 2022-09-07T15:05:07Z
Message: The ACME account was registered with the ACME server
Observed Generation: 1
Reason: ACMEAccountRegistered
Status: True
Type: Ready
Events: <none>
kubectl get order --all-namespaces
NAMESPACE NAME STATE AGE
gap tls-secret-h8xvm-907122039 valid 5h38m
kubectl describe order -n gap tls-secret-h8xvm-907122039
Spec:
Dns Names:
my.app.com
Issuer Ref:
Group: cert-manager.io
Kind: ClusterIssuer
Name: letsencrypt-prod
Request: XXXXXXXXX
Status:
Authorizations:
Challenges:
Token: XXXXXXXXXXX
Type: http-01
URL: https://acme-v02.api.letsencrypt.org/acme/chall-v3/XXX/YYY
Identifier: dev01.got-dev.ligenius.app
Initial State: valid
URL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/XXX
Wildcard: false
Certificate: XXXXXXX
Finalize URL: https://acme-v02.api.letsencrypt.org/acme/finalize/YYY/ZZZ
State: valid
URL: https://acme-v02.api.letsencrypt.org/acme/order/YYY/ZZZ
Events: <none>
kubectl get challenges --all-namespaces
No resources found
Is it ok that challenge doesn't exist?
Update 1
Ingress definition
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: XXX-chart
labels:
helm.sh/chart: xxx-chart-0.1.0
app.kubernetes.io/name: xxx-chart
app.kubernetes.io/instance: RELEASE-NAME
app.kubernetes.io/version: "1.16.0"
app.kubernetes.io/managed-by: Helm
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
tls:
- hosts:
- "my.app.com"
secretName: tls-secret
rules:
- host: "my.app.com"
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: "yyy-svc"
port:
number: 80
- ... more path definition
curl -k https://my.app.com/
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
It looks like ingress nginx return default 404 page, but it shouldn't matter for certificate instalation. The yyy-svc and other services are up and running.
Kubernetes server 1.22.6
ingress-nginx/controller v1.3.1
cert-manager v1.9.1
Any thought what is misconfigured?
Earlier it worked for cert-manager v0.16.1, after upgrade to 1.9.1 and solving https://github.com/cert-manager/cert-manager/issues/3501 it doesn't work anymore.
I found the issue. In Ingress the annotation: kubernetes.io/ingress.class: nginx was missing. I removed it some time ago because of some changes in cluster and now it's needed again.

Ingress and cert manager are not creating certificate

I am trying to deploy ingress-routes in Kubernetes following these guides:
https://cert-manager.io/docs/tutorials/acme/ingress/
https://learn.microsoft.com/en-us/azure/aks/ingress-static-ip
I have deployed a cluster-issuer:
apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
name: letsencrypt
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: <Myemail>
privateKeySecretRef:
name: letsencrypt
solvers:
- http01:
ingress:
class: nginx
podTemplate:
spec:
nodeSelector:
"kubernetes.io/os": linux
Then I have deployed ingress:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: airflow-ingress
namespace: airflow6
annotations:
kubernetes.io/ingress.class: nginx
certmanager.k8s.io/cluster-issuer: letsencryp
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
tls:
- hosts:
- <MYhost>
secretName: tls-secret1
rules:
- host: <MYhost>
http:
paths:
- path: /
backend:
serviceName: airflow-web
servicePort: 8080
Then if I try to get the certificate:
kubectl describe certificate tls-secret1 --namespace airflow6
Error from server (NotFound): certificates.cert-manager.io "tls-secret1" not found
I have tried to deploy my own certificate:
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
name: tls-secret1
namespace: airflow6
spec:
secretName: tls-secret1
dnsNames:
- <MYhost>
issuerRef:
name: letsencrypt
# We can reference ClusterIssuers by changing the kind here.
# The default value is Issuer (i.e. a locally namespaced Issuer)
kind: ClusterIssuer
group: cert-manager.io
Then run the same command:
kubectl describe certificate tls-secret1 --namespace airflow6
Name: tls-secret1
Namespace: airflow6
Labels: <none>
Annotations: API Version: cert-manager.io/v1beta1
Kind: Certificate
Metadata:
Creation Timestamp: 2020-10-12T10:50:25Z
Generation: 1
Resource Version: 9408916
Self Link: /apis/cert-manager.io/v1beta1/namespaces/airflow6/certificates/quickstart-example-tls
UID: 5c4f06e2-bb61-4eed-8999-58540d4055ce
Spec:
Dns Names:
<Myhost>
Issuer Ref:
Group: cert-manager.io
Kind: ClusterIssuer
Name: letsencrypt
Secret Name: tls-secret1
Status:
Conditions:
Last Transition Time: 2020-10-12T10:50:25Z
Message: Issuing certificate as Secret does not exist
Reason: DoesNotExist
Status: True
Type: Issuing
Last Transition Time: 2020-10-12T10:50:25Z
Message: Issuing certificate as Secret does not exist
Reason: DoesNotExist
Status: False
Type: Ready
Next Private Key Secret Name: tls-secret1
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Issuing 3m8s cert-manager Issuing certificate as Secret does not exist
Normal Requested 3m8s cert-manager Created new CertificateRequest resource "quickstart-example-tls-hl7vk"
Normal Requested <invalid> cert-manager Created new CertificateRequest resource "quickstart-example-tls-vqmbh"
Normal Generated <invalid> (x3 over 3m8s) cert-manager Stored new private key in temporary Secret resource "quickstart-example-tls-fgvn6"
Normal Requested <invalid> cert-manager Created new CertificateRequest resource "quickstart-example-tls-5gg9l"
I don't know if I need to create a secret like this:
apiVersion: v1
kind: Secret
name: example-tls
namespace: foo
data:
tls.crt: <base64 encoded cert>
tls.key: <base64 encoded key>
type: kubernetes.io/tls
But I really don't know what I have to put in tls.crt and tls.key.
In all the guides I have read I saw that when the ingress-routes is deployed automatically a certificate is created but for me is not working, what I am going wrong?
no you are not supposed to create the TLS secret on your own, it's like when you put the secret name in the ingress rule's tls section, then while doing the DNS verification, the secret will be created by issuer itself for the respective namespace in which the ingress rule has been created.
To cross-check on configs created or to create new one, you can refer this
Then you can follow this stack overflow post, it will help you likely

Cert-Manager dns01 challenge order pending

Followed steps mentioned at https://cert-manager.io/docs/installation/kubernetes/
# Kubernetes 1.16+
$ kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.0.3/cert-manager.yaml
$ kubectl -n cert-manager get pods
NAME READY STATUS RESTARTS AGE
cert-manager-958cb7d4d-m62xm 1/1 Running 0 137m
cert-manager-cainjector-8495f7f6c9-56ck6 1/1 Running 0 137m
cert-manager-webhook-5dcdfbd9d4-6mw74 1/1 Running 0 137m
ClusterIssuer
% kubectl -n cert-manager describe ClusterIssuer letsencrypt
Name: letsencrypt
Namespace:
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"cert-manager.io/v1alpha2","kind":"ClusterIssuer","metadata":{"annotations":{},"name":"letsencrypt"},"spec":{"acme":{"email"...
API Version: cert-manager.io/v1
Kind: ClusterIssuer
Metadata:
Creation Timestamp: 2020-10-21T17:31:16Z
Generation: 1
Resource Version: 120254050
Self Link: /apis/cert-manager.io/v1/clusterissuers/letsencrypt
UID: fe54ce07-61be-446f-9db1-4745b742ac71
Spec:
Acme:
Email: admin#example.com
Preferred Chain:
Private Key Secret Ref:
Name: letsencrypt-test-key
Server: https://acme-v02.api.letsencrypt.org/directory
Solvers:
dns01:
route53:
Access Key ID: ####
Hosted Zone ID: ####
Region: us-west-2
Secret Access Key Secret Ref:
Key: secret_key
Name: aws-secret
Selector:
Dns Zones:
example.com
Status:
Acme:
Last Registered Email: admin#example.com
Uri: https://acme-v02.api.letsencrypt.org/acme/acct/98054390
Conditions:
Last Transition Time: 2020-10-21T17:31:16Z
Message: The ACME account was registered with the ACME server
Reason: ACMEAccountRegistered
Status: True
Type: Ready
Events: <none>
Certificate
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
name: test-cert
namespace: cert-manager
spec:
commonName: '*.test.example.com'
secretName: test-cert
dnsNames:
- '*.test.example.com'
issuerRef:
name: letsencrypt
kind: ClusterIssuer
$ kubectl -n cert-manager get certificate
NAME READY SECRET AGE
test-cert False test-cert 65m
$ kubectl -n cert-manager describe certificate test-cert
Name: test-cert
Namespace: cert-manager
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"cert-manager.io/v1alpha2","kind":"Certificate","metadata":{"annotations":{},"name":"test-cert","namespace":"cert-manager"},...
API Version: cert-manager.io/v1
Kind: Certificate
Metadata:
Creation Timestamp: 2020-10-21T17:31:23Z
Generation: 1
Resource Version: 120254080
Self Link: /apis/cert-manager.io/v1/namespaces/cert-manager/certificates/test-cert
UID: 82148eee-5f4b-47d7-a09a-407e4d041101
Spec:
Common Name: *.test.example.com
Dns Names:
*.test.example.com
Issuer Ref:
Kind: ClusterIssuer
Name: letsencrypt
Secret Name: test-cert
Status:
Conditions:
Last Transition Time: 2020-10-21T17:31:23Z
Message: Issuing certificate as Secret does not exist
Reason: DoesNotExist
Status: False
Type: Ready
Last Transition Time: 2020-10-21T17:31:23Z
Message: Issuing certificate as Secret does not exist
Reason: DoesNotExist
Status: True
Type: Issuing
Next Private Key Secret Name: test-cert-gqhmj
CertificateRequest
$ kubectl -n cert-manager get CertificateRequest
NAME READY AGE
test-cert-zqbwz False 67m
$ kubectl -n cert-manager describe CertificateRequest test-cert-zqbwz
Name: test-cert-zqbwz
Namespace: cert-manager
Labels: <none>
Annotations: cert-manager.io/certificate-name: test-cert
cert-manager.io/certificate-revision: 1
cert-manager.io/private-key-secret-name: test-cert-gqhmj
kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"cert-manager.io/v1alpha2","kind":"Certificate","metadata":{"annotations":{},"name":"test-cert","namespace":"cert-manager"},...
API Version: cert-manager.io/v1
Kind: CertificateRequest
Metadata:
Creation Timestamp: 2020-10-21T17:31:24Z
Generate Name: test-cert-
Generation: 1
Owner References:
API Version: cert-manager.io/v1
Block Owner Deletion: true
Controller: true
Kind: Certificate
Name: test-cert
UID: 82148eee-5f4b-47d7-a09a-407e4d041101
Resource Version: 120254090
Self Link: /apis/cert-manager.io/v1/namespaces/cert-manager/certificaterequests/test-cert-zqbwz
UID: bb9d218d-084d-40a5-8f83-46ca5ac4f70a
Spec:
Issuer Ref:
Kind: ClusterIssuer
Name: letsencrypt
Request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSR...Q0FURSBSRVFVRVNULS0tLS0K
Status:
Conditions:
Last Transition Time: 2020-10-21T17:31:24Z
Message: Waiting on certificate issuance from order cert-manager/test-cert-zqbwz-2027085711: "pending"
Reason: Pending
Status: False
Type: Ready
Events: <none>
Order :
$ kubectl -n cert-manager get order
NAME STATE AGE
test-cert-zqbwz-2027085711 pending 68m
$ kubectl -n cert-manager describe order test-cert-zqbwz-2027085711
Name: test-cert-zqbwz-2027085711
Namespace: cert-manager
Labels: <none>
Annotations: cert-manager.io/certificate-name: test-cert
cert-manager.io/certificate-revision: 1
cert-manager.io/private-key-secret-name: test-cert-gqhmj
kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"cert-manager.io/v1alpha2","kind":"Certificate","metadata":{"annotations":{},"name":"test-cert","namespace":"cert-manager"},...
API Version: acme.cert-manager.io/v1
Kind: Order
Metadata:
Creation Timestamp: 2020-10-21T17:31:24Z
Generation: 1
Owner References:
API Version: cert-manager.io/v1
Block Owner Deletion: true
Controller: true
Kind: CertificateRequest
Name: test-cert-zqbwz
UID: bb9d218d-084d-40a5-8f83-46ca5ac4f70a
Resource Version: 120254091
Self Link: /apis/acme.cert-manager.io/v1/namespaces/cert-manager/orders/test-cert-zqbwz-2027085711
UID: 622c3ce4-fa2f-484f-a280-c125e09e37d3
Spec:
Common Name: *.test.example.com
Dns Names:
*.test.example.com
Issuer Ref:
Kind: ClusterIssuer
Name: letsencrypt
Request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBS...USUZJQ0FURSBSRVFVRVNULS0tLS0K
Status:
Authorizations:
Challenges:
Token: QCbSEvy4g6wIHpcOyU4UkIES9TtBoKMuOOyYNVsJ13w
Type: dns-01
URL: https://acme-v02.api.letsencrypt.org/acme/chall-v3/8048950916/RQu94g
Identifier: test.example.com
Initial State: pending
URL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/8048950916
Wildcard: true
Finalize URL: https://acme-v02.api.letsencrypt.org/acme/finalize/68054360/5803374286
State: pending
URL: https://acme-v02.api.letsencrypt.org/acme/order/68054360/5803374286
Events: <none>
Events: <none>
Why certificate order is pending state, in Route53 I do see TXT for _acme-challenge.test.example.com is created
Whats I am missing in my setup here ?
Probably the same situation
Waiting on certificate issuance from order status "pending"

cert-mananger configuration on GKE with clouddns

So I am looking to set up cert-manager on GKE using google clouddns. It seems like a lot of the older questions on SO that have been asked are using http01 instead of dns01. I want to make sure everything is correct so I don't get rate limited.
here is my issuer.yaml
apiVersion: cert-manager.io/v1alpha2
kind: Issuer
metadata:
name: letsencrypt-staging
spec:
acme:
server: https://acme-staging-v02.api.letsencrypt.org/directory
email: engineering#company.com
privateKeySecretRef:
name: letsencrypt-staging
solvers:
- dns01:
clouddns:
project: MY-GCP_PROJECT
# This is the secret used to access the service account
serviceAccountSecretRef:
name: clouddns-dns01-solver-svc-acct
key: key.json
here is my certificate.yaml
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
name: my-website
namespace: default
spec:
secretName: my-website-tls
issuerRef:
# The issuer created previously
name: letsencrypt-staging
dnsNames:
- my.website.com
I ran these commands to get everything configured:
kubectx my-cluster
kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.15.1/cert-manager.yaml
kubectl get pods --namespace cert-manager
gcloud iam service-accounts create dns01-solver --display-name "dns01-solver"
gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:dns01-solver#$PROJECT_ID.iam.gserviceaccount.com --role roles/dns.admin
gcloud iam service-accounts keys create key.json --iam-account dns01-solver#$PROJECT_ID.iam.gserviceaccount.com
kubectl create secret generic clouddns-dns01-solver-svc-acct --from-file=key.json
kubectl apply -f issuer.yaml
kubectl apply -f certificate.yaml
here is the output from kubectl describe certificaterequests
Name: my-certificaterequests
Namespace: default
Labels: <none>
Annotations: cert-manager.io/certificate-name: my-website
cert-manager.io/private-key-secret-name: my-website-tls
kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"cert-manager.io/v1alpha2","kind":"Certificate","metadata":{"annotations":{},"name":"my-cluster","namespace":"default...
API Version: cert-manager.io/v1alpha3
Kind: CertificateRequest
Metadata:
Creation Timestamp: 2020-06-28T00:05:55Z
Generation: 1
Owner References:
API Version: cert-manager.io/v1alpha2
Block Owner Deletion: true
Controller: true
Kind: Certificate
Name: my-cluster
UID: 81efe2fd-5f58-4c84-ba25-dd9bc63b032a
Resource Version: 192470614
Self Link: /apis/cert-manager.io/v1alpha3/namespaces/default/certificaterequests/my-certificaterequests
UID: 8a0c3e2d-c48e-4cda-9c70-b8dcfe94f14c
Spec:
Csr: ...
Issuer Ref:
Name: letsencrypt-staging
Status:
Certificate: ...
Conditions:
Last Transition Time: 2020-06-28T00:07:51Z
Message: Certificate fetched from issuer successfully
Reason: Issued
Status: True
Type: Ready
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal OrderCreated 16m cert-manager Created Order resource default/my-certificaterequests-484284207
Normal CertificateIssued 14m cert-manager Certificate fetched from issuer successfully
I see the secret kubectl get secret my-website-tls
NAME TYPE DATA AGE
my-website-tls kubernetes.io/tls 3 18m
Does that means everything worked and I should try it in prod? What worries me is that I didn't see any DNS records change in my cloud console.
In addition I wanted to confirm:
How would I change the certificate to be for a wildcard *.company.com?
If in fact I am ready for prod and will get the cert, I just need to updated the secret name in my ingress deployment to redeploy?
Any insight would be greatly appreciated. Thanks
I answered you on Slack already. And you would change the name by changing the value in the dnsNames section of the Certificate or the spec.tls.*.hosts if using ingress-shim, you just include the wildcard name exactly as you showed it.

Error from server: conversion webhook for cert-manager.io/v1alpha2 for cert-manager ClusterIssuer

When I try configuring TLS Let's Encrypt certificates for my cluster application with a NGINX Ingress controller and cert-manager, something goes wrong with the ClusterIssuer.
My ClusterIssuer is defined as followed:
apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
email: user#example.com
server: https://acme-v02.api.letsencrypt.org/directory
privateKeySecretRef:
name: letsencrypt-prod
solvers:
- http01:
ingress:
class: nginx
When I check out the clusterissuer via kubectl, it says that the ClusterIssuer is READY.
$ kubectl get clusterissuer --namespace mynamespace
Response:
NAME READY AGE
letsencrypt-prod True 13s
But when I describe the ClusterIssuer I get an error.
$ kubectl describe clusterissuer letsencrypt-prod --namespace mynamespace
Response:
Error from server: conversion webhook for cert-manager.io/v1alpha2, Kind=ClusterIssuer failed: Post https://cert-manager-webhook.cert-manager.svc:443/convert?timeout=30s: service "cert-manager-webhook" not found
I installed cert-manager with Helm 3 with manually adding the CRDs.
How to solve this?
The cert-manager chart does not accept different namespacing when the CRDs are applied manually to your cluster. Instead of applying them manually first, install the CRDs as part of the Helm 3 release.
$ helm repo add jetstack https://charts.jetstack.io
$ helm repo update
$ helm install \
cert-manager jetstack/cert-manager \
--namespace mynamespace \
--version v0.15.1 \
--set installCRDs=true
I solved this issue by adding namespace: cert-manager under metadata
It would look something like this:
apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
namespace: cert-manager
spec:
acme:
email: user#example.com
server: https://acme-v02.api.letsencrypt.org/directory
privateKeySecretRef:
name: letsencrypt-prod
solvers:
- http01:
ingress:
class: nginx