Waiting for HTTP-01 challenge propagation: wrong status code '404', expected '200'

Question

I just set up cert-manager on Kube.netes GCP but when I check my logs I get this error:

cert-manager/challenges "msg"="propagation check failed" "error"="wrong status code '404', expected '200'" "dnsName"="api.lumiwealth.com" "resource_kind"="Challenge" "resource_name"="test-certificate-h4m8c-1804713970-576085961" "resource_namespace"="backend" "resource_version"="v1" "type"="HTTP-01"

From what I can tell the issue is that the ingress that gets created does not have access to the external inte.net, I confirmed this by running this in Terminal:

curl http://api.lumiwealth.com/.well-known/acme-challenge/vhoLg-lNAgXAwEJlknfBbRlYuKuHBakgeG_d40c09Zk

Which returns:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
</head>
<body>
<pre>Cannot GET /.well-known/acme-challenge/vhoLg-lNAgXAwEJlknfBbRlYuKuHBakgeG_d40c09Zk</pre>
</body>
</html>

Here are my YAML files:

Issuer:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata: 
  name: letsencrypt-prod
spec: 
  acme: 
    email: "rob@lumiwealth.com"
    privateKeySecretRef: 
      name: letsencrypt-prod
    server: "https://acme-v02.api.letsencrypt.org/directory"
    solvers:
      - http01:
          ingress:
            class: ingress-gce

Test certificate:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: test-certificate
  namespace: backend
spec:
  secretName: certificate-test
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
  - api.lumiwealth.com

When I kubectl apply the certificate it creates an ingress in GCP that looks like this (but doesn't seem to have.network access? not sure how it could have possibly gotten the IP address from my DNS)

Any ideas what I'm missing?

Answer 1

Based on the error message and the information you've provided, it seems that the issue is related to the ingress not having access to the external inte.net.

There are a few things you can try to resolve this issue:

Make sure that the ingress controller you're using (ingress-gce in this case) has the correct configuration and that it's properly setup to access the external inte.net.
Check that the firewall rules of the cluster are configured to allow traffic to the external inte.net.
Check that the.network configuration of your cluster allows communication with the external inte.net.
Check that your DNS is configured correctly and that it's pointing to the correct IP address.
Check that the load balancer created by the ingress controller has a public IP address.

It could be that there is a problem in the.network configuration or in the firewall rules of your cluster. In this case, you should check the logs of your ingress controller and the firewall rules of your cluster to see if there is any configuration error.

It could also be that the ingress controller is not running in the correct namespace or with the correct configuration, in this case you could check the yaml configuration of the ingress controller and make sure that it's properly set up.

It's also possible that the issue is related to DNS, in this case you should check that the DNS is configured correctly and that it's pointing to the correct IP address.

Finally, you should check that the load balancer created by the ingress controller has a public IP address

Answer 2

I believe the issue is a routing issue rather than a.network issue.

When you query

curl http://api.lumiwealth.com/.well-known/acme-challenge/vhoLg-lNAgXAwEJlknfBbRlYuKuHBakgeG_d40c09Zk

This does indeed work and can exit the cluster and the broader inte.net. What that query does is that then it tries to access the challenge file within the cluster.

Would you kindly check for the values of

kubectl -A get challenges

To make sure that there is only one set of challenges?, if there are more you may want to delete everything and start over.

So all you have to do is modify your ingress routes to capture the route

.well-known/acme-challenge/*

This has to be routed to the ACME solver pod/service within your cluster.

The basic troubleshooting steps for https01 Docs

You can access the URL from the public inte.net
The ACME solver pod is up and running
Use kubectl describe ingress to check the status of the HTTP01 solver ingress. (unless you use acme.cert-manager.io/http01-edit-in-place, then check the same ingress as your domain)

Waiting for HTTP-01 challenge propagation: wrong status code '404', expected '200'

Question

1 answers

solution1
0 2023-01-16 08:55:20

solution2
0 2023-01-16 14:12:06

Waiting for HTTP-01 challenge propagation: wrong status code '404', expected '200'

Question

1 answers

solution1 0 2023-01-16 08:55:20

solution2 0 2023-01-16 14:12:06

solution1
0 2023-01-16 08:55:20

solution2
0 2023-01-16 14:12:06