Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:testui.globalu.com
Waiting for HTTP-01 challenge propagation: failed to perform self check GET request 'http://testui.globalu.com/.well-known/acme-challenge/AyMkKL_oWuBNE8oHUC0BXW_ZEaKYZpHlFSg6vhS3qqY': Get "https://testui.globalu.com:443/.well-known/acme-challenge/AyMkKL_oWuBNE8oHUC0BXW_ZEaKYZpHlFSg6vhS3qqY": remote error: tls: unrecognized name
I ran this command:I have installed cert-manager using kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.0/cert-manager.yaml
It produced this output:3 pods in running condition and I have added a clusterissuer yaml (letsencrypt-production)
The secret added in tls section testui-globalu-com has only tls.key but not tls.crt
Certificate status is
Issuing certificate as Secret does not exist
My web server is (include version):
The operating system my web server runs on is (include version):Linux
My hosting provider, if applicable, is:GoDaddy
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of
certbot --version or
certbot-auto --version if you're using Certbot):Am using Certbot not sure about the version
Welcome to the Let's Encrypt Community!
I believe that you are facing a certificate bootstrapping problem.
You need to either...
- have the challenge files served over HTTP and thus not have requests for them redirected to be served over HTTPS (until you have a working certificate)
- install a snakeoil/default certificate so that the challenge files can be served over HTTPS (which should be handled by k8s or your ingress controller)
Bear in mind that your tls.key is generated on your server along with your certificate signing request (CSR).
This suggests the service cannot resolve
testui.globalu.com which would seem to be a dns resolution problem.
Is there a specific reason you are pointing
kubectl apply at an old version (January 2022) of the cert-manager yaml?
The online tool https://unboundtest.com/ with
testui.globalu.com as the input yields these results
Query results for A testui.globalu.com
;; opcode: QUERY, status: NOERROR, id: 8349
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version 0; flags: do; udp: 512
;; QUESTION SECTION:
;testui.globalu.com. IN A
;; ANSWER SECTION:
testui.globalu.com. 0 IN CNAME a7014292b94d54cdcbab59c7cbda9cfd-985324450.eu-west-2.elb.amazonaws.com.
a7014292b94d54cdcbab59c7cbda9cfd-985324450.eu-west-2.elb.amazonaws.com. 0 IN A 188.8.131.52
a7014292b94d54cdcbab59c7cbda9cfd-985324450.eu-west-2.elb.amazonaws.com. 0 IN A 184.108.40.206
----- Unbound logs -----
Sep 06 19:07:38 unbound[1304248:0] notice: init module 0: validator
Sep 06 19:07:38 unbound[1304248:0] notice: init module 1: iterator
Sep 06 19:07:38 unbound[1304248:0] info: start of service (unbound 1.16.3).
Sep 06 19:07:39 unbound[1304248:0] info: 127.0.0.1 testui.globalu.com. A IN
Sep 06 19:07:39 unbound[1304248:0] info: resolving testui.globalu.com. A IN
I do not believe this is this scenario as https://decoder.link/sslchecker/testui.globalu.com/443 show a presently valid certificate issued by Let's Encrypt.
It's all about perspective.
From their vantage point, it fails.
Perhaps disabling the self-checks may produce a better result.
My assessment was likely too hastily made.
I was suspecting that they don't have an ingress installed in k8s for
testui.globalu.com for port 443 with tls configured.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.