Let's encrypt challenge is failed because of http01

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! :slightly_smiling_face:

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

; EDNS: version 0; flags: do; udp: 512

;testui.globalu.com.	IN	 A

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
a7014292b94d54cdcbab59c7cbda9cfd-985324450.eu-west-2.elb.amazonaws.com.	0	IN	A

----- 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: 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. :slightly_smiling_face:

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.