I am running my first k3s single node cluster on a ubuntu VPS which works when I curl the http endpoints of an angular application. Via Helm I install cert-manager and followed this tutorial to implement letsEncrypt Tutorial . However, when I run the clusterissuer, cert etc. the challenge fails with the following:
I have added the domain to the VPS's /etc/hosts/ with the external IP of treafik ingress
When you browse to the domain you get the default DNS providers page and when you curl to http/https on the vps you get webpage on http and cert error on https, as expected I think because of the challenge that fails.
I am a bit lost now and do not know what or how to debug this? Is more info needed? Just ask and thanks in advance?
Hi @Chriskick, and welcome to the LE community forum
That sounds like a default landing page.
It is using HTML to redirect or shows your content within a frame, etc.
None of which will work with HTTP-01 authentication.
Also, be sure your site works via IPv6: 2a03:b0c0:2:d0::14bf:4001
Yes, a lot.
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. https://crt.sh/?q=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):
Thanks for the welcoming first post! Appreciated! So first try for all the remaining information, hope I do not break any rules by naming my providers by name.
@Bruce5051 lol was typing when I got your message. We have builders here at home, so my time is limited, sorry for that!
As i understand it correctly, it is the default landing page that I can delete in their local storage, but I would assume that there is some functionality that redirects to this html. Curling to https://nutrizone.nl responds with curl: (60) SSL certificate problem: self-signed certificate, so that is why assume this.
My VPS had IPv6 turned off and I have turned it on now, only this, because does my loadbalancer also have its external ip switched to this? Now it is on its IPv4 adress (same as VPS ip)
So I ran through the tuturial and ended up with a clusterIssuer, certificate and ingress (just ask if needed)
Installed cert-manager --version v1.10.1 via helm
It is a local domain registy company with DirectAdmin as their DNS management system
VPS is digital ocean droplet
I SSH onto the server, but on my pc I can access k3s single node cluster.
Hope this give you guys a start, all help appreciated, I will go look into the IPv6 and try the same curls I tried with IPv4
edit after trying IPv6: @Bruce5051 I have tried the curls you mentioned and I get a curl: (7) Couldn't connect to server. Looking further into this...
nutrizone.nl has multiple IP addresses in its DNS records. While they appear to be accessible on the network, we have detected that they produce differing results when sent an ACME HTTP validation request. This may indicate that some of the IP addresses may unintentionally point to different servers, which would cause validation to fail.
[Address=2a03:b0c0:2:d0::14bf:4001,Address Type=IPv6,Server=nginx,HTTP Status=301,Number of Redirects=1,Final HTTP Status=404] vs [Address=184.108.40.206,Address Type=IPv4,Server=nginx/1.17.1,HTTP Status=404]
Currently I am blocklisted from my DNS management system, but with little knowledge of IPv6 I think maybe there is a whole IPv6 list not pointing to the IPv6 of my VPS. I will fix this as soon I have access.
So far I have on my action list
Switch VPS to IPv6 to be able to use the cert (done)
DNS management point change default IPv6 records to VPS IPv6 (TODO)
The loadbalancers IP has port 80 open so I guess this is no problem?
Yes I used your curl -6 -k -Ii https://\[2a03:b0c0:2:d0::d7d:d001\]/ command, which is the IPv6 and go the mentioned couldnt connect
Lots of info already, thanks, those websites to check certain things are already helpful, although I feel I do not automatically all the errors, so if more is needed to the above action list, feel free to add
No preference really, since IPv6 is needed for LetsEncrypt AND I hear everyone (my work environment) is switching to also use IPv6 I would choose IPv6 as the most important. I cannot find reasons to keep IPv4, but all post on stackoverflow says keep both haha.
The -6 ones are not working, because my dns management is still pointing to the default ip. There is no way it could work now right? I read the above error as an error that DirectAdmin gives on it default ip.
-4 == 404 not found because there is no cert working setup via the IPv6, so when I have access to my DNS management and change IPv6 I can check again right? I think this is blocking at the moment.
To make sure we understand eachother
The DirectAdmin IPv6 IP that is default and I still need to change in my DNS management
Below the new IPv6 I opened on my VPS
So until I update my DNS management, the results from curl -6 are not correctly directing to my VPS
If you have both IPv4 & IPv6 (my personal opinion is that is good) but the Let's Encrypt Challenges are for Domain Validation, which means that the Fully Qualified Domain Name is being looked up from DNS for an A, AAAA, or CNAME record. So to pass the Challenge what ever path is being taken from Let's Encrypt must give the correct response. Thus both all IP Addresses must give the same response.
The problem when IPv4 and IPv6 addresses return different results is that this is a symptom of misconfiguration. You want "regular" clients like browsers to see the same result regardless of whether they used IPv4 or IPv6.
The LE HTTP Challenge is different. The Let's Encrypt Servers will try IPv6 if an AAAA record is present. If it works it's done and IPv4 is not involved. Only if there are specific comms failures will IPv4 be tried when an AAAA record is present.
When no AAAA record is present, the IPv4 A address is used.
LE does not need IPv6. IPv4-only is perfectly acceptable. But as I noted above if you have AAAA it will be favored by LE for HTTP Challenge
I can't follow what's happening in this thread so not sure what suggestions to make. Just hoping this clarity will help.