I am trying to get a certificate issued from Let's Encrypt, and it has been 3 and a half hours.
I accidentally originally set my secretName as "echo-tls" before switching it to the correct "pandaist-tls" that I want to use instead.
I currently have this:
kubectl get CertificateRequest -o wide
NAME READY ISSUER STATUS AGE
pandaist-tls-1926992011 False letsencrypt-prod Waiting on certificate issuance from order default/pandaist-tls-1926992011-2163900139: "pending" 3h26m
When I describe the certificate, I get this:
Deployment kubectl describe CertificateRequest pandaist-tls-1926992011
Name: pandaist-tls-1926992011
Namespace: default
Labels: <none>
Annotations: cert-manager.io/certificate-name: pandaist-tls
cert-manager.io/private-key-secret-name: pandaist-tls
API Version: cert-manager.io/v1alpha2
Kind: CertificateRequest
Metadata:
Creation Timestamp: 2020-04-07T15:41:13Z
Generation: 1
Owner References:
API Version: cert-manager.io/v1alpha2
Block Owner Deletion: true
Controller: true
Kind: Certificate
Name: pandaist-tls
UID: 25c3ff31-447f-4abf-a23e-ec48f5a591a9
Resource Version: 500795
Self Link: /apis/cert-manager.io/v1alpha2/namespaces/default/certificaterequests/pandaist-tls-1926992011
UID: 8295836d-fb99-4ebf-8803-a344d6edb574
Spec:
Csr: ABUNCHOFVALUESTHATIWILLNOTDESCRIBE
Issuer Ref:
Group: cert-manager.io
Kind: ClusterIssuer
Name: letsencrypt-prod
Status:
Conditions:
Last Transition Time: 2020-04-07T15:41:13Z
Message: Waiting on certificate issuance from order default/pandaist-tls-1926992011-2163900139: "pending"
Reason: Pending
Status: False
Type: Ready
Events: <none>
And then I look at my logs for my cert-manager pods - here are small slices of each:
I0407 19:01:35.499469 1 service.go:43] cert-manager/controller/challenges/http01/selfCheck/http01/ensureService "level"=0 "msg"="found one existing HTTP01 solver Service for challenge resource" "dnsName"="pandaist.com" "related_resource_kind"="Service" "related_resource_name"="cm-acme-http-solver-2fp58" "related_resource_namespace"="default" "resource_kind"="Challenge" "resource_name"="pandaist-tls-1926992011-2163900139-2157075729" "resource_namespace"="default" "type"="http-01"
I0407 19:01:35.499513 1 service.go:43] cert-manager/controller/challenges/http01/selfCheck/http01/ensureService "level"=0 "msg"="found one existing HTTP01 solver Service for challenge resource" "dnsName"="auth.pandaist.com" "related_resource_kind"="Service" "related_resource_name"="cm-acme-http-solver-xhjsr" "related_resource_namespace"="default" "resource_kind"="Challenge" "resource_name"="pandaist-tls-1926992011-2163900139-832917849" "resource_namespace"="default" "type"="http-01"
I0407 19:01:35.499534 1 ingress.go:91] cert-manager/controller/challenges/http01/selfCheck/http01/ensureIngress "level"=0 "msg"="found one existing HTTP01 solver ingress" "dnsName"="pandaist.com" "related_resource_kind"="Ingress" "related_resource_name"="cm-acme-http-solver-pd9fh" "related_resource_namespace"="default" "resource_kind"="Challenge" "resource_name"="pandaist-tls-1926992011-2163900139-2157075729" "resource_namespace"="default" "type"="http-01"
I0407 19:01:35.499578 1 ingress.go:91] cert-manager/controller/challenges/http01/selfCheck/http01/ensureIngress "level"=0 "msg"="found one existing HTTP01 solver ingress" "dnsName"="auth.pandaist.com" "related_resource_kind"="Ingress" "related_resource_name"="cm-acme-http-solver-b6zr2" "related_resource_namespace"="default" "resource_kind"="Challenge" "resource_name"="pandaist-tls-1926992011-2163900139-832917849" "resource_namespace"="default" "type"="http-01"
E0407 19:03:46.571074 1 sync.go:184] cert-manager/controller/challenges "msg"="propagation check failed" "error"="failed to perform self check GET request 'http://pandaist.com/.well-known/acme-challenge/6Wduj2Ejr59OZ9SFy_Rw4jnozE50xspK-a5OIvCwYsc': Get http://pandaist.com/.well-known/acme-challenge/6Wduj2Ejr59OZ9SFy_Rw4jnozE50xspK-a5OIvCwYsc: dial tcp 178.128.132.218:80: connect: connection timed out" "dnsName"="pandaist.com" "resource_kind"="Challenge" "resource_name"="pandaist-tls-1926992011-2163900139-2157075729" "resource_namespace"="default" "type"="http-01"
E0407 19:03:46.571109 1 sync.go:184] cert-manager/controller/challenges "msg"="propagation check failed" "error"="failed to perform self check GET request 'http://auth.pandaist.com/.well-known/acme-challenge/gO91--fK0SGG15aS3ALOHXXYtCSly2Q9pbVO8OJW2aE': Get http://auth.pandaist.com/.well-known/acme-challenge/gO91--fK0SGG15aS3ALOHXXYtCSly2Q9pbVO8OJW2aE: dial tcp 178.128.132.218:80: connect: connection timed out" "dnsName"="auth.pandaist.com" "resource_kind"="Challenge" "resource_name"="pandaist-tls-1926992011-2163900139-832917849" "resource_namespace"="default" "type"="http-01"
I0407 19:03:46.571382 1 controller.go:135] cert-manager/controller/challenges "level"=0 "msg"="finished processing work item" "key"="default/pandaist-tls-1926992011-2163900139-832917849"
I0407 19:03:46.571528 1 controller.go:129] cert-manager/controller/challenges "level"=0 "msg"="syncing item" "key"="default/pandaist-tls-1926992011-2163900139-832917849"
I0407 19:03:46.571193 1 controller.go:135] cert-manager/controller/challenges "level"=0 "msg"="finished processing work item" "key"="default/pandaist-tls-1926992011-2163900139-2157075729"
I0407 19:03:46.572009 1 controller.go:129] cert-manager/controller/challenges "level"=0 "msg"="syncing item" "key"="default/pandaist-tls-1926992011-2163900139-2157075729"
I0407 19:03:46.572338 1 pod.go:58] cert-manager/controller/challenges/http01/selfCheck/http01/ensurePod "level"=0 "msg"="found one existing HTTP01 solver pod" "dnsName"="auth.pandaist.com" "related_resource_kind"="Pod" "related_resource_name"="cm-acme-http-solver-scqtx" "related_resource_namespace"="default" "resource_kind"="Challenge" "resource_name"="pandaist-tls-1926992011-2163900139-832917849" "resource_namespace"="default" "type"="http-01"
I0407 19:03:46.572600 1 service.go:43] cert-manager/controller/challenges/http01/selfCheck/http01/ensureService "level"=0 "msg"="found one existing HTTP01 solver Service for challenge resource" "dnsName"="auth.pandaist.com" "related_resource_kind"="Service" "related_resource_name"="cm-acme-http-solver-xhjsr" "related_resource_namespace"="default" "resource_kind"="Challenge" "resource_name"="pandaist-tls-1926992011-2163900139-832917849" "resource_namespace"="default" "type"="http-01"
I0407 19:03:46.572860 1 ingress.go:91] cert-manager/controller/challenges/http01/selfCheck/http01/ensureIngress "level"=0 "msg"="found one existing HTTP01 solver ingress" "dnsName"="auth.pandaist.com" "related_resource_kind"="Ingress" "related_resource_name"="cm-acme-http-solver-b6zr2" "related_resource_namespace"="default" "resource_kind"="Challenge" "resource_name"="pandaist-tls-1926992011-2163900139-832917849" "resource_namespace"="default" "type"="http-01"
I0407 19:03:46.573128 1 pod.go:58] cert-manager/controller/challenges/http01/selfCheck/http01/ensurePod "level"=0 "msg"="found one existing HTTP01 solver pod" "dnsName"="pandaist.com" "related_resource_kind"="Pod" "related_resource_name"="cm-acme-http-solver-jn65v" "related_resource_namespace"="default" "resource_kind"="Challenge" "resource_name"="pandaist-tls-1926992011-2163900139-2157075729" "resource_namespace"="default" "type"="http-01"
I0407 19:03:46.573433 1 service.go:43] cert-manager/controller/challenges/http01/selfCheck/http01/ensureService "level"=0 "msg"="found one existing HTTP01 solver Service for challenge resource" "dnsName"="pandaist.com" "related_resource_kind"="Service" "related_resource_name"="cm-acme-http-solver-2fp58" "related_resource_namespace"="default" "resource_kind"="Challenge" "resource_name"="pandaist-tls-1926992011-2163900139-2157075729" "resource_namespace"="default" "type"="http-01"
I0407 19:03:46.573749 1 ingress.go:91] cert-manager/controller/challenges/http01/selfCheck/http01/ensureIngress "level"=0 "msg"="found one existing HTTP01 solver ingress" "dnsName"="pandaist.com" "related_resource_kind"="Ingress" "related_resource_name"="cm-acme-http-solver-pd9fh" "related_resource_namespace"="default" "resource_kind"="Challenge" "resource_name"="pandaist-tls-1926992011-2163900139-2157075729" "resource_namespace"="default" "type"="http-01"
And then here, where I still see echo-tls, despite the fact that I changed my ingress to use pandaist-tls:
I0407 15:34:37.115159 1 controller.go:242] cert-manager/controller-runtime/controller "level"=1 "msg"="Successfully Reconciled" "controller"="validatingwebhookconfiguration" "request"={"Namespace":"","Name":"cert-manager-webhook"}
I0407 15:34:37.118246 1 controller.go:170] cert-manager/inject-controller "level"=1 "msg"="updated object" "resource_kind"="ValidatingWebhookConfiguration" "resource_name"="cert-manager-webhook" "resource_namespace"=""
I0407 15:34:37.118520 1 controller.go:242] cert-manager/controller-runtime/controller "level"=1 "msg"="Successfully Reconciled" "controller"="validatingwebhookconfiguration" "request"={"Namespace":"","Name":"cert-manager-webhook"}
I0407 15:34:37.119415 1 sources.go:176] cert-manager/inject-controller "level"=0 "msg"="Extracting CA from Secret resource" "resource_kind"="ValidatingWebhookConfiguration" "resource_name"="cert-manager-webhook" "resource_namespace"="" "secret"="cert-manager/cert-manager-webhook-tls"
I0407 15:34:37.120959 1 controller.go:170] cert-manager/inject-controller "level"=1 "msg"="updated object" "resource_kind"="MutatingWebhookConfiguration" "resource_name"="cert-manager-webhook" "resource_namespace"=""
I0407 15:34:37.121399 1 controller.go:242] cert-manager/controller-runtime/controller "level"=1 "msg"="Successfully Reconciled" "controller"="mutatingwebhookconfiguration" "request"={"Namespace":"","Name":"cert-manager-webhook"}
I0407 15:34:37.124545 1 controller.go:170] cert-manager/inject-controller "level"=1 "msg"="updated object" "resource_kind"="ValidatingWebhookConfiguration" "resource_name"="cert-manager-webhook" "resource_namespace"=""
I0407 15:34:37.125160 1 controller.go:242] cert-manager/controller-runtime/controller "level"=1 "msg"="Successfully Reconciled" "controller"="validatingwebhookconfiguration" "request"={"Namespace":"","Name":"cert-manager-webhook"}
E0407 16:19:36.762436 1 indexers.go:93] cert-manager/secret-for-certificate-mapper "msg"="unable to fetch certificate that owns the secret" "error"="Certificate.cert-manager.io \"echo-tls\" not found" "certificate"={"Namespace":"default","Name":"echo-tls"} "secret"={"Namespace":"default","Name":"echo-tls"}
E0407 16:19:36.762573 1 indexers.go:93] cert-manager/secret-for-certificate-mapper "msg"="unable to fetch certificate that owns the secret" "error"="Certificate.cert-manager.io \"echo-tls\" not found" "certificate"={"Namespace":"default","Name":"echo-tls"} "secret"={"Namespace":"default","Name":"echo-tls"}
E0407 16:19:36.762753 1 indexers.go:93] cert-manager/secret-for-certificate-mapper "msg"="unable to fetch certificate that owns the secret" "error"="Certificate.cert-manager.io \"echo-tls\" not found" "certificate"={"Namespace":"default","Name":"echo-tls"} "secret"={"Namespace":"default","Name":"echo-tls"}
E0407 16:19:36.762766 1 indexers.go:93] cert-manager/secret-for-certificate-mapper "msg"="unable to fetch certificate that owns the secret" "error"="Certificate.cert-manager.io \"echo-tls\" not found" "certificate"={"Namespace":"default","Name":"echo-tls"} "secret"={"Namespace":"default","Name":"echo-tls"}
My ingress:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: pandaist-ingress
annotations:
kubernetes.io/ingress.class: "nginx"
cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
tls:
- hosts:
- pandaist.com
- auth.pandaist.com
secretName: pandaist-tls
rules:
- host: pandaist.com
http:
paths:
- backend:
serviceName: pandaist-main
servicePort: 80
- host: auth.pandaist.com
http:
paths:
- backend:
serviceName: pandaist-keycloak
servicePort: 80
This ingress was absolutely applied after the echo one.
Is this just normal certificate approval time (3.5 hours) or did the accidental inclusion of echo-tls mess up my certificate issuance? If so, how do I fix it?
Due to a bug in how load balancers work on Digital Ocean:
https://www.digitalocean.com/community/questions/how-do-i-correct-a-connection-timed-out-error-during-http-01-challenge-propagation-with-cert-manager
This will solve the problem:
kind: Service
apiVersion: v1
metadata:
name: ingress-nginx
annotations:
# See https://github.com/digitalocean/digitalocean-cloud-controller-manager/blob/master/docs/controllers/services/examples/README.md#accessing-pods-over-a-managed-load-balancer-from-inside-the-cluster
service.beta.kubernetes.io/do-loadbalancer-hostname: "kube.mydomain.com"
namespace: ingress-nginx
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
spec:
externalTrafficPolicy: Local
type: LoadBalancer
selector:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
ports:
- name: http
port: 80
targetPort: http
- name: https
port: 443
targetPort: https
This might be worthwhile to look at in case #Cecil's solution doesn't work. I was facing similar issue with Connection Timeout
Change LoadBalancer in ingress-nginx service.
Add/Change externalTrafficPolicy: Cluster.
Reason being, pod with the certificate-issuer wound up on a different node than the load balancer did, so it couldn’t talk to itself through the ingress.
Below is complete block taken from https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.26.1/deploy/static/provider/cloud-generic.yaml
kind: Service
apiVersion: v1
metadata:
name: ingress-nginx
namespace: ingress-nginx
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
spec:
#CHANGE/ADD THIS
externalTrafficPolicy: Cluster
type: LoadBalancer
selector:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
ports:
- name: http
port: 80
targetPort: http
- name: https
port: 443
targetPort: https
---
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
Im trying create wildcard cert on Rancher kubernetes engine behind cloud loadbalancer.
After install rancher i have a Issuer:
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
annotations:
meta.helm.sh/release-name: rancher
meta.helm.sh/release-namespace: cattle-system
creationTimestamp: "2021-09-21T12:10:25Z"
generation: 1
labels:
app: rancher
app.kubernetes.io/managed-by: Helm
chart: rancher-2.5.9
heritage: Helm
release: rancher
name: rancher
namespace: cattle-system
resourceVersion: "1318"
selfLink: /apis/cert-manager.io/v1/namespaces/cattle-system/issuers/rancher
uid: #
spec:
acme:
email: #
preferredChain: ""
privateKeySecretRef:
name: letsencrypt-production
server: https://acme-v02.api.letsencrypt.org/directory
solvers:
- http01:
ingress: {}
status:
acme:
lastRegisteredEmail: #
uri: https://acme-v02.api.letsencrypt.org/#
conditions:
- lastTransitionTime: "2021-09-21T12:10:27Z"
message: The ACME account was registered with the ACME server
reason: ACMEAccountRegistered
status: "True"
type: Ready
this is order:
kubectl describe order wildcard-dev-mctqj-4171528257 -n cattle-system
Name: wildcard-dev-mctqj-4171528257
Namespace: cattle-system
Labels: <none>
Annotations: cert-manager.io/certificate-name: wildcard-dev
cert-manager.io/certificate-revision: 1
cert-manager.io/private-key-secret-name: wildcard-dev-2g4rc
API Version: acme.cert-manager.io/v1
Kind: Order
Metadata:
Creation Timestamp: 2021-09-21T14:10:50Z
Generation: 1
Managed Fields:
API Version: acme.cert-manager.io/v1
Fields Type: FieldsV1
fieldsV1:
f:metadata:
f:annotations:
.:
f:cert-manager.io/certificate-name:
f:cert-manager.io/certificate-revision:
f:cert-manager.io/private-key-secret-name:
f:kubectl.kubernetes.io/last-applied-configuration:
f:ownerReferences:
.:
k:{"uid":"}
.:
f:apiVersion:
f:blockOwnerDeletion:
f:controller:
f:kind:
f:name:
f:uid:
f:spec:
.:
f:commonName:
f:dnsNames:
f:issuerRef:
.:
f:kind:
f:name:
f:request:
f:status:
.:
f:authorizations:
f:finalizeURL:
f:state:
f:url:
Manager: controller
Operation: Update
Time: 2021-09-21T14:10:52Z
Owner References:
API Version: cert-manager.io/v1
Block Owner Deletion: true
Controller: true
Kind: CertificateRequest
Name: wildcard-dev-mctqj
UID: #
Resource Version: 48930
Self Link: /apis/acme.cert-manager.io/v1/namespaces/cattle-system/orders/wildcard-dev-mctqj-4171528257
UID: #
Spec:
Common Name: *.
Dns Names:
*.rancher-dev.com
Issuer Ref:
Kind: Issuer
Name: rancher
Request:
Status:
Authorizations:
Challenges:
Token: #######
Type: dns-01
URL: https://acme-v02.api.letsencrypt.org/acme/chall-v3/##
Identifier: rancher.dev.com
Initial State: pending
URL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/##
Wildcard: true
Finalize URL: https://acme-v02.api.letsencrypt.org/acme/finalize/###
State: pending
URL: https://acme-v02.api.letsencrypt.org/acme/order/###
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning Solver 49m cert-manager Failed to determine a valid solver configuration for the set of domains on the Order: no configured challenge solvers can be used for th is challenge
dns changed ofc
Certificate:
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: wildcard-dev
namespace: cattle-system
spec:
secretName: wildcard-dev
issuerRef:
kind: Issuer
name: rancher
commonName: '*.rancher.dev.com'
dnsNames:
- '*.rancher.dev.com'
i dont create ingress yet..
i think trubl in order
Type: dns-01
What i do wrong ?
Mbe create second issuer ?
Actually, i want create wildcard certificate and clone him wit kubed, becouse i need a lot namespaces in kube with 1 wldcard cert. What can you advise me, guys?)
As it is written here serving-a-wildcard-to-ingress, http01 solver does not support wildcard. Instead you should use dns01 for wildcard certificates.
See documentation to dns01 solver.
I am trying to work with TLS in our Kubernetes cluster.
I've followed MS documentation on "Create an HTTPS ingress controller on Azure Kubernetes Service" (https://learn.microsoft.com/en-us/azure/aks/ingress-tls).
I've deployed a nginx-ingress controller, added the DNS record and installed the cert-manager.
I created a CA ClusterIssuer of SelfSigned and also created the 2 demo applications.
When I created the ingress route, the certificate created automatically and with "True" on the Ready status, but the route is not working - I can't access the demo applications with the host name deployed (https://hello-world-ingress.<Ingress_Service_DNS_Name>).
The Self-Signed ClusterIssuer:
apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
name: selfsigned-issuer
spec:
selfSigned: {}
The Ingress route:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: hello-world-ingress
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/rewrite-target: /$2
cert-manager.io/cluster-issuer: selfsigned-issuer
spec:
tls:
- hosts:
- hello-world-ingress.<Ingress_Service_DNS_Name>
secretName: tls-secret
rules:
- host: hello-world-ingress.<Ingress_Service_DNS_Name>
http:
paths:
- backend:
serviceName: aks-helloworld
servicePort: 80
path: /(.*)
- backend:
serviceName: aks-helloworld-two
servicePort: 80
path: /hello-world-two(/|$)(.*)
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: hello-world-ingress-static
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/rewrite-target: /static/$2
cert-manager.io/cluster-issuer: selfsigned-issuer
spec:
tls:
- hosts:
- hello-world-ingress.<Ingress_Service_DNS_Name>
secretName: tls-secret
rules:
- host: hello-world-ingress.<Ingress_Service_DNS_Name>
http:
paths:
- backend:
serviceName: aks-helloworld
servicePort: 80
path: /static(/|$)(.*)
I've created a DNS record on GoDaddy in our domain for <Ingress_Service_DNS_Name> (but with the real name) that points to the external ingress controller service IP Address.
The rest of the installations and deployments are the same as the documentation.
Does anyone has any idea why it's not working?
---------------- Edit ----------------------
Ingress-controller logs:
I0330 06:03:16.780788 7 event.go:281] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"ingress-basic", Name:"hello-world-ingress", UID:"488a4c00-7072-11ea-a46c-1a8c7fb34cf9", APIVersion:"networking.k8s.io/v1beta1", ResourceVersion:"37375594", FieldPath:""}): type: 'Normal' reason: 'UPDATE' Ingress ingress-basic/hello-world-ingressI0330 06:03:46.358414 7 event.go:281] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"ingress-basic", Name:"hello-world-ingress-static", UID:"48b91e0e-7072-11ea-a46c-1a8c7fb34cf9", APIVersion:"networking.k8s.io/v1beta1", ResourceVersion:"37375687", FieldPath:""}): type: 'Normal' reason: 'UPDATE' Ingress ingress-basic/hello-world-ingress-static
I0330 06:03:46.386930 7 event.go:281] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"ingress-basic", Name:"hello-world-ingress", UID:"488a4c00-7072-11ea-a46c-1a8c7fb34cf9", APIVersion:"networking.k8s.io/v1beta1", ResourceVersion:"37375688", FieldPath:""}): type: 'Normal' reason: 'UPDATE' Ingress ingress-basic/hello-world-ingress
I0330 06:04:16.783483 7 event.go:281] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"ingress-basic", Name:"hello-world-ingress", UID:"488a4c00-7072-11ea-a46c-1a8c7fb34cf9", APIVersion:"networking.k8s.io/v1beta1", ResourceVersion:"37375802", FieldPath:""}): type: 'Normal' reason: 'UPDATE' Ingress ingress-basic/hello-world-ingress
I0330 06:04:16.788210 7 event.go:281] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"ingress-basic", Name:"hello-world-ingress-static", UID:"48b91e0e-7072-11ea-a46c-1a8c7fb34cf9", APIVersion:"networking.k8s.io/v1beta1", ResourceVersion:"37375803", FieldPath:""}): type: 'Normal' reason: 'UPDATE' Ingress ingress-basic/hello-world-ingress-static
I0330 06:04:46.584035 7 event.go:281] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"ingress-basic", Name:"hello-world-ingress", UID:"488a4c00-7072-11ea-a46c-1a8c7fb34cf9", APIVersion:"networking.k8s.io/v1beta1", ResourceVersion:"37375904", FieldPath:""}): type: 'Normal' reason: 'UPDATE' Ingress ingress-basic/hello-world-ingress
I0330 06:04:46.587677 7 event.go:281] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"ingress-basic", Name:"hello-world-ingress-static", UID:"48b91e0e-7072-11ea-a46c-1a8c7fb34cf9", APIVersion:"networking.k8s.io/v1beta1", ResourceVersion:"37375905", FieldPath:""}): type: 'Normal' reason: 'UPDATE' Ingress ingress-basic/hello-world-ingress-static
I0330 06:05:16.938952 7 event.go:281] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"ingress-basic", Name:"hello-world-ingress", UID:"488a4c00-7072-11ea-a46c-1a8c7fb34cf9", APIVersion:"networking.k8s.io/v1beta1", ResourceVersion:"37376008", FieldPath:""}): type: 'Normal' reason: 'UPDATE' Ingress ingress-basic/hello-world-ingress
I0330 06:05:16.938975 7 event.go:281] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"ingress-basic", Name:"hello-world-ingress-static", UID:"48b91e0e-7072-11ea-a46c-1a8c7fb34cf9", APIVersion:"networking.k8s.io/v1beta1", ResourceVersion:"37376007", FieldPath:""}): type: 'Normal' reason: 'UPDATE' Ingress ingress-basic/hello-world-ingress-static
I0330 06:05:46.337384 7 event.go:281] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"ingress-basic", Name:"hello-world-ingress-static", UID:"48b91e0e-7072-11ea-a46c-1a8c7fb34cf9", APIVersion:"networking.k8s.io/v1beta1", ResourceVersion:"37376095", FieldPath:""}): type: 'Normal' reason: 'UPDATE' Ingress ingress-basic/hello-world-ingress-static
Cert-manager logs:
I0330 06:16:19.953430 1 reflector.go:432] external/io_k8s_client_go/tools/cache/reflector.go:108: Watch close - *v1alpha2.Order total 0 items received
I0330 06:16:19.989382 1 reflector.go:278] external/io_k8s_client_go/tools/cache/reflector.go:108: forcing resync
I0330 06:16:39.861201 1 metrics.go:304] cert-manager/metrics "msg"="attempting to clean up metrics for recently deleted certificates"
I0330 06:16:39.861233 1 metrics.go:307] cert-manager/metrics "msg"="active certificates is still uninitialized"
I0330 06:16:46.353253 1 controller.go:129] cert-manager/controller/ingress-shim "msg"="syncing item" "key"="ingress-basic/hello-world-ingress"
I0330 06:16:46.354661 1 metrics.go:385] cert-manager/metrics "msg"="incrementing controller sync call count" "controllerName"="ingress-shim"
I0330 06:16:46.355124 1 sync.go:163] cert-manager/controller/ingress-shim "msg"="certificate already exists for ingress resource, ensuring it is up to date" "related_resource_kind"="Certificate" "related_resource_name"="tls-secret-selfsigned" "related_resource_namespace"="ingress-basic" "resource_kind"="Ingress" "resource_name"="hello-world-ingress" "resource_namespace"="ingress-basic"
I0330 06:16:46.356804 1 sync.go:176] cert-manager/controller/ingress-shim "msg"="certificate resource is already up to date for ingress" "related_resource_kind"="Certificate" "related_resource_name"="tls-secret-selfsigned" "related_resource_namespace"="ingress-basic" "resource_kind"="Ingress" "resource_name"="hello-world-ingress" "resource_namespace"="ingress-basic"
I0330 06:16:46.357190 1 controller.go:135] cert-manager/controller/ingress-shim "msg"="finished processing work item" "key"="ingress-basic/hello-world-ingress"
I0330 06:16:46.358636 1 controller.go:129] cert-manager/controller/ingress-shim "msg"="syncing item" "key"="ingress-basic/hello-world-ingress-static"
I0330 06:16:46.361782 1 metrics.go:385] cert-manager/metrics "msg"="incrementing controller sync call count" "controllerName"="ingress-shim"
I0330 06:16:46.367596 1 sync.go:163] cert-manager/controller/ingress-shim "msg"="certificate already exists for ingress resource, ensuring it is up to date" "related_resource_kind"="Certificate" "related_resource_name"="tls-secret-selfsigned" "related_resource_namespace"="ingress-basic" "resource_kind"="Ingress" "resource_name"="hello-world-ingress-static" "resource_namespace"="ingress-basic"
I0330 06:16:46.368271 1 sync.go:171] cert-manager/controller/ingress-shim "msg"="certificate resource is not owned by this ingress. refusing to update non-owned certificate resource for ingress" "related_resource_kind"="Certificate" "related_resource_name"="tls-secret-selfsigned" "related_resource_namespace"="ingress-basic" "resource_kind"="Ingress" "resource_name"="hello-world-ingress-static" "resource_namespace"="ingress-basic"
I0330 06:16:46.368424 1 controller.go:135] cert-manager/controller/ingress-shim "msg"="finished processing work item" "key"="ingress-basic/hello-world-ingress-static"
I0330 06:16:47.581355 1 reflector.go:278] external/io_k8s_client_go/tools/cache/reflector.go:108: forcing resync
I0330 06:16:49.383317 1 reflector.go:278] external/io_k8s_client_go/tools/cache/reflector.go:108: forcing resync
The only thing that looks like it can be a problem is in the cert manager logs:
"certificate resource is not owned by this ingress. refusing to update non-owned certificate resource for ingress" "related_resource_kind"="Certificate" "related_resource_name"="tls-secret-selfsigned" "related_resource_namespace"="ingress-basic" "resource_kind"="Ingress" "resource_name"="hello-world-ingress-static" "resource_namespace"="ingress-basic" "
Thanks,
Afik
Based on the information provided a believe that the problem is two ingresses using the same self-signed certificate.
What you trying to achieve here is that you want to manage your certificate from two different places. As the documentation states:
Deploy a TLS Ingress Resource - “There are two primary ways to do
this: using annotations on the ingress with ingress-shim or directly
creating a certificate resource.”
So your hello-world-ingress can use the annotation:
cert-manager.io/cluster-issuer: selfsigned-issuer
But the helo-world-ingress-static cant because the certificate has been already created under secretName: tls-secret.
So from the hello-world-ingress-static you should remove the annotation:
cert-manager.io/cluster-issuer: selfsigned-issuer
Because it creates interest conflict since the secretName is already created and managed by other resource. In this case CertificateRequest from another Ingress.
Let me know if this helps.
I can't seem to get cert-manager working:
$ kubectl get certificates -o wide
NAME READY SECRET ISSUER STATUS AGE
example-ingress False example-ingress letsencrypt-prod Waiting for CertificateRequest "example-ingress-2556707613" to complete 6m23s
$ kubectl get CertificateRequest -o wide
NAME READY ISSUER STATUS AGE
example-ingress-2556707613 False letsencrypt-prod Referenced "Issuer" not found: issuer.cert-manager.io "letsencrypt-prod" not found 7m7s
and in the logs i see:
I1025 06:22:00.117292 1 sync.go:163] cert-manager/controller/ingress-shim "level"=0 "msg"="certificate already exists for ingress resource, ensuring it is up to date" "related_resource_kind"="Certificate" "related_resource_name"="example-ingress" "related_resource_namespace"="default" "resource_kind"="Ingress" "resource_name"="example-ingress" "resource_namespace"="default"
I1025 06:22:00.117341 1 sync.go:176] cert-manager/controller/ingress-shim "level"=0 "msg"="certificate resource is already up to date for ingress" "related_resource_kind"="Certificate" "related_resource_name"="example-ingress" "related_resource_namespace"="default" "resource_kind"="Ingress" "resource_name"="example-ingress" "resource_namespace"="default"
I1025 06:22:00.117382 1 controller.go:135] cert-manager/controller/ingress-shim "level"=0 "msg"="finished processing work item" "key"="default/example-ingress"
I1025 06:22:00.118026 1 sync.go:361] cert-manager/controller/certificates "level"=0 "msg"="no existing CertificateRequest resource exists, creating new request..." "related_resource_kind"="Secret" "related_resource_name"="example-ingress" "related_resource_namespace"="default" "resource_kind"="Certificate" "resource_name"="example-ingress" "resource_namespace"="default"
I1025 06:22:00.147147 1 controller.go:129] cert-manager/controller/certificaterequests-issuer-venafi "level"=0 "msg"="syncing item" "key"="default/example-ingress-2556707613"
I1025 06:22:00.147267 1 sync.go:373] cert-manager/controller/certificates "level"=0 "msg"="created certificate request" "related_resource_kind"="Secret" "related_resource_name"="example-ingress" "related_resource_namespace"="default" "resource_kind"="Certificate" "resource_name"="example-ingress" "resource_namespace"="default" "request_name"="example-ingress-2556707613"
I1025 06:22:00.147284 1 controller.go:129] cert-manager/controller/certificaterequests-issuer-acme "level"=0 "msg"="syncing item" "key"="default/example-ingress-2556707613"
I1025 06:22:00.147273 1 conditions.go:200] Setting lastTransitionTime for CertificateRequest "example-ingress-2556707613" condition "Ready" to 2019-10-25 06:22:00.147254385 +0000 UTC m=+603.871617341
I1025 06:22:00.147392 1 conditions.go:200] Setting lastTransitionTime for CertificateRequest "example-ingress-2556707613" condition "Ready" to 2019-10-25 06:22:00.147380513 +0000 UTC m=+603.871743521
E1025 06:22:00.147560 1 pki.go:128] cert-manager/controller/certificates "msg"="error decoding x509 certificate" "error"="error decoding cert PEM block" "related_resource_kind"="Secret" "related_resource_name"="example-ingress" "related_resource_namespace"="default" "resource_kind"="Certificate" "resource_name"="example-ingress" "resource_namespace"="default" "secret_key"="tls.crt"
I1025 06:22:00.147620 1 conditions.go:155] Setting lastTransitionTime for Certificate "example-ingress" condition "Ready" to 2019-10-25 06:22:00.147613112 +0000 UTC m=+603.871976083
I1025 06:22:00.147731 1 controller.go:129] cert-manager/controller/certificaterequests-issuer-ca "level"=0 "msg"="syncing item" "key"="default/example-ingress-2556707613"
I1025 06:22:00.147765 1 conditions.go:200] Setting lastTransitionTime for CertificateRequest "example-ingress-2556707613" condition "Ready" to 2019-10-25 06:22:00.14776244 +0000 UTC m=+603.872125380
I1025 06:22:00.147912 1 controller.go:129] cert-manager/controller/certificaterequests-issuer-selfsigned "level"=0 "msg"="syncing item" "key"="default/example-ingress-2556707613"
I1025 06:22:00.147942 1 conditions.go:200] Setting lastTransitionTime for CertificateRequest "example-ingress-2556707613" condition "Ready" to 2019-10-25 06:22:00.147938966 +0000 UTC m=+603.872301909
I1025 06:22:00.147968 1 controller.go:129] cert-manager/controller/certificaterequests-issuer-vault "level"=0 "msg"="syncing item" "key"="default/example-ingress-2556707613"
I1025 06:22:00.148023 1 conditions.go:200] Setting lastTransitionTime for CertificateRequest "example-ingress-2556707613" condition "Ready" to 2019-10-25 06:22:00.148017945 +0000 UTC m=+603.872380906
i deployed cert-manager via the manifest:
https://github.com/jetstack/cert-manager/releases/download/v0.11.0/cert-manager.yaml
$ kubectl get clusterissuer letsencrypt-prod -o yaml
apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"cert-manager.io/v1alpha2","kind":"ClusterIssuer","metadata":{"annotations":{},"name":"letsencrypt-prod"},"spec":{"acme":{"email":"me#me.com","privateKeySecretRef":{"name":"letsencrypt-prod"},"server":"https://acme-staging-v02.api.letsencrypt.org/directory","solvers":[{"http01":{"ingress":{"class":"nginx"}},"selector":{}}]}}}
creationTimestamp: "2019-10-25T06:27:06Z"
generation: 1
name: letsencrypt-prod
resourceVersion: "1759784"
selfLink: /apis/cert-manager.io/v1alpha2/clusterissuers/letsencrypt-prod
uid: 05831417-b359-42de-8298-60da553575f2
spec:
acme:
email: me#me.com
privateKeySecretRef:
name: letsencrypt-prod
server: https://acme-staging-v02.api.letsencrypt.org/directory
solvers:
- http01:
ingress:
class: nginx
selector: {}
status:
acme:
lastRegisteredEmail: me#me.com
uri: https://acme-staging-v02.api.letsencrypt.org/acme/acct/11410425
conditions:
- lastTransitionTime: "2019-10-25T06:27:07Z"
message: The ACME account was registered with the ACME server
reason: ACMEAccountRegistered
status: "True"
type: Ready
and my ingress is:
$ kubectl get ingress example-ingress -o yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
cert-manager.io/issuer: letsencrypt-prod
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"extensions/v1beta1","kind":"Ingress","metadata":{"annotations":{"cert-manager.io/issuer":"letsencrypt-prod","kubernetes.io/ingress.class":"nginx","kubernetes.io/tls-acme":"true"},"name":"example-ingress","namespace":"default"},"spec":{"rules":[{"host":"example-ingress.example.com","http":{"paths":[{"backend":{"serviceName":"apple-service","servicePort":5678},"path":"/apple"},{"backend":{"serviceName":"banana-service","servicePort":5678},"path":"/banana"}]}}],"tls":[{"hosts":["example-ingress.example.com"],"secretName":"example-ingress"}]}}
kubernetes.io/ingress.class: nginx
kubernetes.io/tls-acme: "true"
creationTimestamp: "2019-10-25T06:22:00Z"
generation: 1
name: example-ingress
namespace: default
resourceVersion: "1758822"
selfLink: /apis/extensions/v1beta1/namespaces/default/ingresses/example-ingress
uid: 921b2e91-9101-4c3c-a0d8-3f871dafdd30
spec:
rules:
- host: example-ingress.example.com
http:
paths:
- backend:
serviceName: apple-service
servicePort: 5678
path: /apple
- backend:
serviceName: banana-service
servicePort: 5678
path: /banana
tls:
- hosts:
- example-ingress.example.com
secretName: example-ingress
status:
loadBalancer:
ingress:
- ip: x.y.z.a
any idea whats wrong? cheers,
Your ingress is referring to an issuer, but the issuer is a ClusterIssuer. Could that be the reason? I have a similar setup with Issuer instead of a ClusterIssuer and it is working.
I have done this implementation, you can follow this way -
Install jetstack from here
Then follow these steps from this stackoverflow post
Make one clusterIssuer or you can make individual issuer too, once you patch the hostname to ingress, then the tls-certificate in that namespace will be autogenerated by Jetstack after the acme-challenge validation
Kindly make sure to map the IP of loadbalancer nginx/traefik etc to DNS/hostname
I am trying to set up a cluster with Istio on it, where the SSL traffic gets terminated at the Ingress. I have deployed Istio with SDS and Mutual TLS. With the below yaml, I only get the error message upstream connect error or disconnect/reset before headers. reset reason: connection failure when accessing my cluster in the browser:
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: default-gateway
namespace: istio-system
spec:
selector:
istio: ingressgateway
servers:
- hosts:
- '*'
port:
name: http
number: 80
protocol: HTTP
---
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: nginx1
name: nginx1
spec:
containers:
- image: nginx
name: nginx
resources: {}
ports:
- containerPort: 80
dnsPolicy: ClusterFirst
restartPolicy: Never
status: {}
---
apiVersion: v1
kind: Service
metadata:
labels:
run: nginx1
name: nginx1
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
run: nginx1
sessionAffinity: None
type: ClusterIP
status:
loadBalancer: {}
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: nginx1
spec:
hosts:
- "*"
gateways:
- istio-system/default-gateway
http:
- match:
- uri:
prefix: /nginx1
route:
- destination:
port:
number: 80
host: nginx1.default.svc.cluster.local
The ingressgateway logs show the following TLS error:
[2019-07-09 09:07:24.907][29][debug][pool] [external/envoy/source/common/http/http1/conn_pool.cc:88] creating a new connection
[2019-07-09 09:07:24.907][29][debug][client] [external/envoy/source/common/http/codec_client.cc:26] [C4759] connecting
[2019-07-09 09:07:24.907][29][debug][connection] [external/envoy/source/common/network/connection_impl.cc:702] [C4759] connecting to 100.200.1.59:80
[2019-07-09 09:07:24.907][29][debug][connection] [external/envoy/source/common/network/connection_impl.cc:711] [C4759] connection in progress
[2019-07-09 09:07:24.907][29][debug][pool] [external/envoy/source/common/http/conn_pool_base.cc:20] queueing request due to no available connections
[2019-07-09 09:07:24.907][29][debug][connection] [external/envoy/source/common/network/connection_impl.cc:550] [C4759] connected
[2019-07-09 09:07:24.907][29][debug][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:168] [C4759] handshake error: 2
[2019-07-09 09:07:24.907][29][debug][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:168] [C4759] handshake error: 1
[2019-07-09 09:07:24.907][29][debug][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:201] [C4759] TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER
[2019-07-09 09:07:24.907][29][debug][connection] [external/envoy/source/common/network/connection_impl.cc:188] [C4759] closing socket: 0
[2019-07-09 09:07:24.907][29][debug][client] [external/envoy/source/common/http/codec_client.cc:82] [C4759] disconnect. resetting 0 pending requests
[2019-07-09 09:07:24.907][29][debug][pool] [external/envoy/source/common/http/http1/conn_pool.cc:129] [C4759] client disconnected, failure reason: TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER
[2019-07-09 09:07:24.907][29][debug][pool] [external/envoy/source/common/http/http1/conn_pool.cc:164] [C4759] purge pending, failure reason: TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER
[2019-07-09 09:07:24.907][29][debug][router] [external/envoy/source/common/router/router.cc:671] [C4753][S3527573287149425977] upstream reset: reset reason connection failure
[2019-07-09 09:07:24.907][29][debug][http] [external/envoy/source/common/http/conn_manager_impl.cc:1137] [C4753][S3527573287149425977] Sending local reply with details upstream_reset_before_response_started{connection failure,TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER}
Reading though this blog I thought I might need to add
- hosts:
- '*'
port:
name: https
number: 443
protocol: HTTPS
tls:
mode: SIMPLE
serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
privateKey: /etc/istio/ingressgateway-certs/tls.key
to the ingressgateway configuration. However, this did not solve the problem. Additionally, since I am using SDS, there won't be any certificates in ingressgateway-certs (see https://istio.io/docs/tasks/security/auth-sds/#verifying-no-secret-volume-mounted-file-is-generated) as it is described in https://istio.io/docs/tasks/traffic-management/ingress/secure-ingress-mount/
Can anyone point me to a correct configuration? Most of what I find online is referring to the "old" filemount approach...
The issue has been resolved by not using istio-cni. See https://github.com/istio/istio/issues/15701
You may have to specify the minimum or maximum TLS version. The options are documented here, under minProtocolVersion and maxProtocolVersion:
https://istio.io/docs/reference/config/networking/v1alpha3/gateway/#Server-TLSOptions
Under the hood, these values map to the following Envoy parameters:
https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/auth/cert.proto#auth-tlsparameters
I followed https://docs.cert-manager.io/en/venafi/tutorials/quick-start/index.html from start to end and everything seems to be working except that I'm not getting an external ip for my ingress.
NAME HOSTS ADDRESS PORTS AGE
staging-site-ingress staging.site.io,staging.admin.site.io, 80, 443 1h
Altough I'm able to use the nginx ingress controller external ip and use dns to access the sites. When I'm going to the urls I'm being redirected to https, so I assume that's working fine.
It redirects to https but still says "not secured", so he don't get a certificate issued.
When I'm debugging I get the following information:
Ingress:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal CreateCertificate 54m cert-manager Successfully created Certificate "tls-secret-staging"
Normal UPDATE 35m (x3 over 1h) nginx-ingress-controller Ingress staging/staging-site-ingress
Normal CreateCertificate 23m (x2 over 35m) cert-manager Successfully created Certificate "letsencrypt-staging-tls"
Certificate:
Status:
Conditions:
Last Transition Time: 2019-02-27T14:02:29Z
Message: Certificate does not exist
Reason: NotFound
Status: False
Type: Ready
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal OrderCreated 3m (x2 over 14m) cert-manager Created Order resource "letsencrypt-staging-tls-593754378"
Secret:
Name: letsencrypt-staging-tls
Namespace: staging
Labels: certmanager.k8s.io/certificate-name=staging-site-io
Annotations: <none>
Type: kubernetes.io/tls
Data
====
ca.crt: 0 bytes
tls.crt: 0 bytes
tls.key: 1679 bytes
Order:
Status:
Certificate: <nil>
Finalize URL:
Reason:
State:
URL:
Events: <none>
So it seems something goes wrong in order and no challenges are created.
Here are my ingress.yaml and issuer.yaml:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: staging-site-ingress
annotations:
kubernetes.io/ingress.class: "nginx"
certmanager.k8s.io/issuer: "letsencrypt-staging"
certmanager.k8s.io/acme-challenge-type: http01
spec:
tls:
- hosts:
- staging.site.io
- staging.admin.site.io
- staging.api.site.io
secretName: letsencrypt-staging-tls
rules:
- host: staging.site.io
http:
paths:
- backend:
serviceName: frontend-service
servicePort: 80
path: /
- host: staging.admin.site.io
http:
paths:
- backend:
serviceName: frontend-service
servicePort: 80
path: /
- host: staging.api.site.io
http:
paths:
- backend:
serviceName: gateway-service
servicePort: 9000
path: /
apiVersion: certmanager.k8s.io/v1alpha1
kind: Issuer
metadata:
name: letsencrypt-staging
namespace: staging
spec:
acme:
server: https://acme-staging-v02.api.letsencrypt.org/directory
email: hello#site.io
privateKeySecretRef:
name: letsencrypt-staging-tls
http01: {}
Anyone knows what I can do to fix this or what went wrong? Certmanager is installed correctly 100%, I'm just not sure about the ingress and what went wrong in the order.
Thanks in advance!
EDIT: I found this in the nginx-ingress-controller:
W0227 14:51:02.740081 8 controller.go:1078] Error getting SSL certificate "staging/letsencrypt-staging-tls": local SSL certificate staging/letsencrypt-staging-tls was not found. Using default certificate
It's getting spammed & the CPU load is always at 0.003 and the cpu graph is full (the other services are almost nothing)
I stumbled over the same issue once, following exactly the same official tutorial.
As #mikebridge mentioned, the issue is with Issuer/Secret's namespace mismatch.
For me, the best was to switch from Issuer to ClusterIssuer, which is not scoped to a single namespace.
The reason your certificate order is not completing is because the challenge is failing to successfully complete. Review your solver configuration in either your Issuer or ClusterIssuer.
See my answer here for more details.
https://stackoverflow.com/a/75454772/4820940