Http challenge end with "no route to host" error

Help
1

Hi. My domain is test01.locky.me

We use kubernetes add-on cert-manager for automate issuance of certificates, and we have some strange problem. We have configuration which is normally works for one server and didn’t works for another.
Domain is test01.locky.me. When we try to get certificate using HTTP validation, the challenge start but then we get the error in logs:

I0529 12:19:07.435434 1 controller.go:213] cert-manager/controller/challenges “level”=0 “msg”=“syncing resource” “key”=“test/test01lockyme-3966551427-0”
I0529 12:19:07.436132 1 pod.go:58] cert-manager/controller/challenges/http01/selfCheck/http01/ensurePod “level”=0 “msg”=“found one existing HTTP01 solver pod” “dnsName”=“test01.locky.me” “related_resource_kind”=“Pod” “related_resource_name”=“cm-acme-http-solver-xvh8t” “related_resource_namespace”=“test” “resource_kind”=“Challenge” “resource_name”=“test01lockyme-3966551427-0” “resource_namespace”=“test” “type”=“http-01”
I0529 12:19:07.436254 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”=“test01.locky.me” “related_resource_kind”=“Service” “related_resource_name”=“cm-acme-http-solver-cbkbl” “related_resource_namespace”=“test” “resource_kind”=“Challenge” “resource_name”=“test01lockyme-3966551427-0” “resource_namespace”=“test” “type”=“http-01”
I0529 12:19:07.436345 1 ingress.go:91] cert-manager/controller/challenges/http01/selfCheck/http01/ensureIngress “level”=0 “msg”=“found one existing HTTP01 solver ingress” “dnsName”=“test01.locky.me” “related_resource_kind”=“Ingress” “related_resource_name”=“cm-acme-http-solver-hnd6d” “related_resource_namespace”=“test” “resource_kind”=“Challenge” “resource_name”=“test01lockyme-3966551427-0” “resource_namespace”=“test” “type”=“http-01”
E0529 12:19:10.455477 1 sync.go:180] cert-manager/controller/challenges “msg”=“propagation check failed” “error”="failed to perform self check GET request ‘http://test01.locky.me/.well-known/acme-challenge/LKc3v0sB53eDkc6haj9QQtFBuebvOFutQnC3_b1RLWQ’: Get http://test01.locky.me/.well-known/acme-challenge/LKc3v0sB53eDkc6haj9QQtFBuebvOFutQnC3_b1RLWQ: dial tcp 95.216.76.14:80: connect: no route to host" “dnsName”=“test01.locky.me” “resource_kind”=“Challenge” “resource_name”=“test01lockyme-3966551427-0” “resource_namespace”=“test” “type”=“http-01”
I0529 12:19:10.455695 1 controller.go:219] cert-manager/controller/challenges “level”=0 “msg”=“finished processing work item” “key”=“test/test01lockyme-3966551427-0”

It seems like Let’s encrypt server can’t get access to test01.locky.me because of “no route to host”. The challenge URL is accessible. In the same time, with the same configuration, on another kubernetes cluster test02.locky.me everything is ok.

2

Hi @locky-me

there is an older check of your domain, ~4 hours old - https://check-your-website.server-daten.de/?q=test01.locky.me

The IP address is defined,

Host T IP-Address is auth. ∑ Queries ∑ Timeout
test01.locky.me A 95.216.76.14 yes 1 0
AAAA yes
www.test01.locky.me Name Error yes 1 0

http and https answers.

Domainname Http-Status redirect Sec. G
• http://test01.locky.me/
95.216.76.14 404 0.093 M
Not Found
• https://test01.locky.me/
95.216.76.14 404 0.406 N
Not Found
Certificate error: RemoteCertificateNameMismatch, RemoteCertificateChainErrors
• http://test01.locky.me/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
95.216.76.14 404 0.093 A
Not Found
Visible Content: 404 Not Found nginx/1.15.9

But: This

propagation check failed” “error”="failed to perform self check GET request

isn't a Letsencrypt error. Looks like that client does a self check, that fails. Does that tool have the correct ip address?

Or is it possible to skip that test?

1 Like
3

Like @JuergenAuer mentioned (thanks!) this isn't an error from Let's Encrypt - it's coming from Cert-manager itself.

Are you using some form of split-horizon DNS? This self-check and more advanced Kubernetes networking comes up fairly frequently as a pain point for cert-manager users. See this issue for one example. One user in that thread had to set up hairpin NAT in their environment for the self-check to pass and that sounds similar to your case.

It's not clear to me as a non-user if the self-check can be disabled or skipped but that will also likely resolve your problem.

1 Like
4

Thank you for answers. We find out that this was not Let’s Encrypt error. It was wrong configuration of our cluster - virtual machines couldn’t reach each others by external addresses, only by internal.

2 Likes
5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.