Question

Issue with Waiting for HTTP-01 challenge propagation: failed to perform self check GET request from ACME challenges

I’ve been stuck on this issue for a while now, and even though this is a common issue, I can’t seem to figure it out why the fixes proposed here (https://www.digitalocean.com/community/questions/how-do-i-correct-a-connection-timed-out-error-during-http-01-challenge-propagation-with-cert-manager) do not work for me.

Here’s my manifests: nginx-service.yaml code
kind: Service apiVersion: v1 metadata: name: ingress-nginx annotations: # See https://github.com/digitalocean/digitalocean-cloud-controller-manager/blob/master/docs/controllers/services/examples/README.md#accessing-pods-over-a-managed-load-balancer-from-inside-the-cluster service.beta.kubernetes.io/do-loadbalancer-hostname: “kube.mydomain.com” namespace: ingress-nginx labels: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/part-of: ingress-nginx spec: externalTrafficPolicy: Local type: LoadBalancer selector: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/part-of: ingress-nginx ports: - name: http port: 80 targetPort: http - name: https port: 443 targetPort: https

cluster-issuer.yaml

apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: letsencrypt-cluster-issuer spec: acme: server: https://acme-v02.api.letsencrypt.org/directory email: myemail@email.com privateKeySecretRef: name: letsencrypt-cluster-issuer-key solvers: - http01: ingress: class: nginx

certificate.yaml

apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: echo-cert namespace: default spec: dnsNames: - my.domain.com secretName: echo-tls issuerRef: name: letsencrypt-cluster-issuer kind: ClusterIssuer


The url provided by the challenge is accessible via browser and wget, so I'm assuming the issue is with the network within the cluster. Does anyone know how do I fix this issue?
Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

erichemmerlin • May 24, 2021
Accepted Answer

Hello Gabriel, I ran into the same issue today.

First, I assume that my.domain.com in the dnsNames of the certificate is a typo. I would have used : kube.mydomain.com

As I installed DigitalOcean “NGINX Ingress Controller” from the 1-Click Apps, I already had the two first annotations below. I only had to add the last line to make it work: service.beta.kubernetes.io/do-loadbalancer-hostname: “kube.mydomain.com”

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
  annotations:
    kubernetes.digitalocean.com/load-balancer-id: xxxxxxx
    service.beta.kubernetes.io/do-loadbalancer-enable-proxy-protocol: "true"
    service.beta.kubernetes.io/do-loadbalancer-hostname: "kube.mydomain.com"

The difference I can see in your configuration is the lack of second annotation: service.beta.kubernetes.io/do-loadbalancer-enable-proxy-protocol: “true”

Here’s a good article explaining this step: https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-with-cert-manager-on-digitalocean-kubernetes

I hope it helps.

Finally, until things work I suggest using the staging Let’s Encript url https://acme-staging-v02.api.letsencrypt.org/directory instead of the production one.

More information about this here : https://medium.com/flant-com/cert-manager-lets-encrypt-ssl-certs-for-kubernetes-7642e463bbce

“Let’s Encrypt imposes fairly strict limits on requests to ACME servers. To avoid unnecessary load on LE’s production environment, we recommend using the letsencrypt-staging certificate for testing (the difference is in the ACME server only).”