Help regarding timeout issues

Help
1

Hi Dears,
I am sticking with one issue for almost two weeks, I am trying to have cert in Kubernetes and i followed exactly like the example but always get issues as Waiting for HTTP-01 challenge propagation: failed to perform self-check GET request. Can somebody help me, please?

2

I would really appreciate any help

3

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:

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

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):

9 Likes
4

As Osiris already pointed out, we would need more info. Especially more of the error message. That looks like it was from cert-manager and should have displayed more info.

Also look at this cert-manager troubleshooting page. Search page for 'self-check'

If that is not enough, please fill out the form and provide more details of error. Thanks

10 Likes
5

Hi Thanks for the answer:
Let me explain to you the setup: we have bare-metal Kubernetes (Kubespray) where we have metallb loadbalancer assign ip address and NGINX ingress controller with a grabbed IP address from metallb. As IP address is not public, we mapped to an public IP address therefore our x.x.x.x nginx controller ip mapped to y.y.y.y with opened 80 and 443 ports.
Then i created cert-manager-v1.8.2 already checked all pods up and running. Then create two staging and production as following:
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-staging
spec:
acme:
# You must replace this email address with your own.
# Let's Encrypt will use this to contact you about expiring
# certificates, and issues related to your account.
email: sarang.kahva@gmail.com
server: https://acme-staging-v02.api.letsencrypt.org/directory
privateKeySecretRef:
# Secret resource that will be used to store the account's private key.
name: letsencrypt-staging-private-key
# Add a single challenge solver, HTTP01 using nginx
solvers:
- http01:
ingress:
class: nginx

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-production
spec:
acme:
# You must replace this email address with your own.
# Let's Encrypt will use this to contact you about expiring
# certificates, and issues related to your account.
email: sarang.kahva@gmail.com
server: https://acme-v02.api.letsencrypt.org/directory
privateKeySecretRef:
# Secret resource that will be used to store the account's private key.
name: mediahub-issuer-account-key
# Add a single challenge solver, HTTP01 using nginx
solvers:
- http01:
ingress:
class: nginx

both checked and status are TRUE then i create and deployment in namespace test then create an ingress as following:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: vsp-ingress-nginx
namespace: test
annotations:

kubernetes.io/ingress.class: "nginx"

ingress.kubernetes.io/ssl-redirect: "false"
nginx.org/redirect-to-https: "false"
cert-manager.k8s.io/cluster-issuer: letsencrypt-staging
acme.cert-manager.io/http01-edit-in-place: "true"

spec:
ingressClassName: nginx
tls:

7

This looks like a comms problem on your end. You are better off asking about this on a Kubernetes or cert-manager forum. People there are more experienced at its configuration than we are. We can't be experts in every possible program that requests certificates.

The only thing I see your config uses port 8080 but I don't see a port 8080 open for your domain. So, maybe it can't connect outbound on that port? I am just guessing.

I can connect to your domain just fine on both http and https so inbound connections from the public internet are fine. It looks like just this self-check is failing. Example of working request to port 443:

openssl s_client -connect cttc.netapps-5gmediahub.eu:443 

Certificate chain
 0 s:/serialNumber=1234567890
   i:/CN=cert-manager.local

subject= /serialNumber=1234567890
issuer= /CN=cert-manager.local
notBefore=Jul  7 12:53:10 2022 GMT
notAfter=Oct  5 12:53:10 2022 GMT
serial=7F45E334AEACAF040D2C2296CF0E87AE
SHA1 Fingerprint=DC:5F:0D:D3:B8:65:7C:72:7B:B2:86:B0:D1:F5:34:E9:CD:5D:48:13

SANs:
cttc.netapps-5gmediahub.eu
9 Likes
8

To add to the "information", I see this cert on port 443:

subject=/O=Acme Co/CN=Kubernetes Ingress Controller Fake Certificate
issuer=/O=Acme Co/CN=Kubernetes Ingress Controller Fake Certificate
8 Likes
9

I see that fake cert now too. I guess that's some sort of progress :slight_smile:

8 Likes
10

Most clients implement a "Self Check", in which they try to query the HTTP or DNS server to ensure the expected challenge is live. If it passes, they'll trigger the ACME Server endpoint - if it fails, they won't and will abort the validation/order.

Your self check failed. This could be because:

  • Container routing is broken or misconfigured (inbound ports to the service/container are not working)
  • The expected service/container is not running
  • There is a bug in the service/container
  • There is an issue on the challenge setup
  • other issues

The line "Client.Timeout exceeded while awaiting headers" suggests you have not correctly configured your port80 service or routing.

It is impossible to debug these situations without detailed logs. As others said, the Kubernetes or Cert-Manager are your best option for support.

8 Likes
11

Hi Dears,
Hi Dears,
I really appreciate it if somebody gives me a solution to this. I am sticking with one issue for almost two weeks, I am trying to have cert in Kubernetes and i followed exactly like the example but always get issues as Waiting for HTTP-01 challenge propagation: failed to perform self-check GET request. Can somebody help me, please?
here is some info:
Let me explain to you the setup: we have bare-metal Kubernetes (Kubespray) where we have metallb loadbalancer assign ip address and NGINX ingress controller with a grabbed IP address from metallb. As IP address is not public, we mapped to an public IP address therefore our x.x.x.x nginx controller ip mapped to y.y.y.y with opened 80 and 443 ports.
Then i created cert-manager-v1.8.2 already checked all pods up and running. Then create two staging and production as following:
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-staging
spec:
acme:
email: sarang.kahva@gmail.com
server: https://acme-staging-v02.api.letsencrypt.org/directory
privateKeySecretRef:
name: letsencrypt-staging-private-key
solvers:

1 Like
12

I already check with slack cermanager community no help comes from them

13

I don't know that I have a solution for you, but I do see some things that are curious and might not add up:

5 Likes
14

This is the same problem you posted about previously - isn't it?

I don't see any new info in this post.

6 Likes
15

[merged both topics]

6 Likes
16

Hi Dears,
Yes its same as i am struggling with it almost three weeks :slight_smile: i hope and appreciate that you can help me to figure out, if you need any logs or input let me know

17

Begin at the beginning.
You must have a working HTTP site before you can get a cert via HTTP authentication:

curl -Ii http://cttc.netapps-5gmediahub.eu/
HTTP/1.1 404 Not Found
Date: Mon, 11 Jul 2022 16:04:56 GMT
Content-Type: text/html
Content-Length: 146
Connection: keep-alive
5 Likes
18

i change domain now is mediahub.cttc.es
try to curl this one:
HTTP/1.1 308 Permanent Redirect
Date: Mon, 11 Jul 2022 16:07:24 GMT
Content-Type: text/html
Content-Length: 164
Connection: keep-alive
Location: https://mediahub.cttc.es

19 
curl -Ii mediahub.cttc.es
HTTP/1.1 308 Permanent Redirect
Date: Mon, 11 Jul 2022 16:07:24 GMT
Content-Type: text/html
Content-Length: 164
Connection: keep-alive
Location: https://mediahub.cttc.es

curl -Iik https://mediahub.cttc.es/
HTTP/2 405
date: Mon, 11 Jul 2022 16:07:29 GMT
content-type: application/json
content-length: 31
strict-transport-security: max-age=15724800; includeSubDomains
5 Likes
20

Does it mean it's regarding security policies from DNS provider ? Whats your suggestion for this 308 and 405 ?

21

No.

I do see:

WARNING: cannot verify mediahub.cttc.es's certificate, issued by ‘CN=cert-manager.local’

I don't know cert-manager, but the challenge requests are always better handled in HTTP than redirecting them to HTTPS.

5 Likes