Challenge returns 404, what steps to take?

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:

Accepting challenge authorization failed: acme: authorization error for 403 urn:ietf:params:acme:error:unauthorized: 2a03:b0c0:2:d0::14bf:4001: Invalid response from 404

  • 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 :slight_smile:

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:

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


Using this online tool TCP Port Scanner, Online Port Scan, Port Scanning | IPVoid I get these results for the IPv6 Address.


And here is what curl -6 gives me from a remote IPv6 system I have access to

>curl -6 -Ii http://\[2a03:b0c0:2:d0::14bf:4001\]/
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 17 Jan 2023 22:17:19 GMT
Content-Type: text/html
Content-Length: 43
Last-Modified: Mon, 24 Oct 2022 12:13:37 GMT
Connection: keep-alive
Vary: Accept-Encoding
ETag: "63568171-2b"
Accept-Ranges: bytes

>curl -6 -k -Ii https://\[2a03:b0c0:2:d0::14bf:4001\]/
HTTP/2 200
server: nginx
date: Tue, 17 Jan 2023 22:17:26 GMT
content-type: text/html
content-length: 43
last-modified: Mon, 24 Oct 2022 12:13:37 GMT
vary: Accept-Encoding
etag: "63568171-2b"
accept-ranges: bytes

>curl -6 -Ii http://\[2a03:b0c0:2:d0::14bf:4001\]/.well-known/acme-challenge/sometestfile
HTTP/1.1 404 Not Found
Server: nginx
Date: Tue, 17 Jan 2023 22:17:37 GMT
Content-Type: text/html; charset=iso-8859-1
Connection: keep-alive
Vary: Accept-Encoding

>curl -6 -k -Ii https://\[2a03:b0c0:2:d0::14bf:4001\]/.well-known/acme-challenge/sometestfile
HTTP/2 404
server: nginx
date: Tue, 17 Jan 2023 22:17:47 GMT
content-type: text/html; charset=iso-8859-1
vary: Accept-Encoding

>curl -6 -k -vvI https://\[2a03:b0c0:2:d0::14bf:4001\]/
*   Trying [2a03:b0c0:2:d0::14bf:4001]:443...
* Connected to 2a03:b0c0:2:d0::14bf:4001 (2a03:b0c0:2:d0::14bf:4001) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
* [CONN-0-0][CF-SSL] TLSv1.3 (OUT), TLS handshake, Client hello (1):
* [CONN-0-0][CF-SSL] TLSv1.3 (IN), TLS handshake, Server hello (2):
* [CONN-0-0][CF-SSL] TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* [CONN-0-0][CF-SSL] TLSv1.3 (IN), TLS handshake, Certificate (11):
* [CONN-0-0][CF-SSL] TLSv1.3 (IN), TLS handshake, CERT verify (15):
* [CONN-0-0][CF-SSL] TLSv1.3 (IN), TLS handshake, Finished (20):
* [CONN-0-0][CF-SSL] TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* [CONN-0-0][CF-SSL] TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server accepted h2
* Server certificate:
*  subject:
*  start date: Jan  6 22:13:54 2023 GMT
*  expire date: Apr  6 22:13:53 2023 GMT
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Using HTTP2, server supports multiplexing
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* h2h3 [:method: HEAD]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: [2a03:b0c0:2:d0::14bf:4001]]
* h2h3 [user-agent: curl/7.87.0]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x8014f7800)
> Host: [2a03:b0c0:2:d0::14bf:4001]
> user-agent: curl/7.87.0
> accept: */*
* [CONN-0-0][CF-SSL] TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* [CONN-0-0][CF-SSL] TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
HTTP/2 200
< server: nginx
server: nginx
< date: Tue, 17 Jan 2023 22:38:31 GMT
date: Tue, 17 Jan 2023 22:38:31 GMT
< content-type: text/html
content-type: text/html
< content-length: 43
content-length: 43
< last-modified: Mon, 24 Oct 2022 12:13:37 GMT
last-modified: Mon, 24 Oct 2022 12:13:37 GMT
< vary: Accept-Encoding
vary: Accept-Encoding
< etag: "63568171-2b"
etag: "63568171-2b"
< accept-ranges: bytes
accept-ranges: bytes

* Connection #0 to host 2a03:b0c0:2:d0::14bf:4001 left intact

Hello @Chriskick,

Any update on providing more information?
Especially @rg305 request as shown below.


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 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
Ubuntu 22.10
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...


I am on an IPv4 only network.

So here is a list of issued certificates |, the latest, and only one, being 2022-12-07.

Using Let's Debug I see these results

Warning 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=,Address Type=IPv4,Server=nginx/1.17.1,HTTP Status=404] 

From here I see there is both an IPv4 and an IPv6 Address, the both have to give the same answers.
Best Practice - Keep Port 80 Open for both IPv4 & IPv6 Addresses.
Shows this:

So it would appear that content being deliver is not consistent.

$ curl -Ii
HTTP/1.1 404 Not Found
Content-Length: 153
Content-Type: text/html
Date: Thu, 19 Jan 2023 16:23:46 GMT
Server: nginx/1.17.1

Again, from an IPv4 only network. This is what I get for the certificate being served.
verify error:num=18:self-signed certificate

$ openssl s_client -showcerts -servername -connect < /dev/null
verify error:num=18:self-signed certificate
verify return:1
verify return:1
Certificate chain
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 19 16:21:21 2023 GMT; NotAfter: Jan 19 16:21:21 2024 GMT
Server certificate
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
SSL handshake has read 1405 bytes and written 378 bytes
Verification error: self-signed certificate
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 18 (self-signed certificate)
Post-Handshake New Session Ticket arrived:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_128_GCM_SHA256
    Session-ID: 965A12BB7BDB6A72CCC6B58D6DBE7343C773A60755224FE7FA4DC49CC2D7586B
    Resumption PSK: 3C6CC88E587C38B31D43F1F14FA05C3352E67071DA2322EC442C8631CD12EE16
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 604800 (seconds)
    TLS session ticket:
    0000 - 8b 37 3c d2 58 0f 60 db-e9 03 fc 37 f5 1f b7 87   .7<.X.`....7....
    0010 - b4 70 45 af 3f d0 bc c7-30 33 02 7e 39 ad f5 14   .pE.?...03.~9...
    0020 - ab 97 62 0a 36 c7 46 c3-20 63 ed e8 69 45 17 3b   ..b.6.F. c..iE.;
    0030 - 79 21 3e 03 5e 8d 7c be-e5 61 af aa be 2d c9 13   y!>.^.|..a...-..
    0040 - f4 79 f0 fc ea e3 7d 1d-2d 95 51 de c0 b8 80 39   .y....}.-.Q....9
    0050 - 14 fa ff 17 cd 64 73 35-5e 81 3b 90 e4 3b 9f a7   .....ds5^.;..;..
    0060 - 87 68 2c de 96 45 75 b2-97 f7 ef 0e 95 01 12 e2   .h,..Eu.........
    0070 - d2                                                .

    Start Time: 1674145962
    Timeout   : 7200 (sec)
    Verify return code: 18 (self-signed certificate)
    Extended master secret: no
    Max Early Data: 0
read R BLOCK

Just for your awareness
To force IPv4 use curl -4
To force IPv6 use curl -6

1 Like

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

  1. Switch VPS to IPv6 to be able to use the cert (done)
  2. 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


Is the site going to have both IPv4 & IPv6?


On a remote system I have access to that has both IPv4 & IPv6 I see this

IPv4 & IPv6 do not respond this same.

>curl -6 -k -Ii
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Thu, 19 Jan 2023 16:55:08 GMT
Content-Type: text/html
Content-Length: 162
Connection: keep-alive
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1
X-Download-Options: noopen
X-Permitted-Cross-Domain-Policies: master-only
X-DNS-Prefetch-Control: on
Referrer-Policy: no-referrer-when-downgrade
Strict-Transport-Security: max-age=31536000
Content-Security-Policy: block-all-mixed-content
Permissions-Policy: geolocation=(); midi=(); push=(); sync-xhr=(); microphone=(); camera=(); magnetometer=(); gyroscope=(); speaker=(); vibrate=(); fullscreen=(); payment=()

>curl -6 -k -Ii
HTTP/2 404
server: nginx
date: Thu, 19 Jan 2023 16:55:16 GMT
content-type: text/html; charset=iso-8859-1
vary: Accept-Encoding
x-frame-options: SAMEORIGIN

>curl -4 -k -Ii
HTTP/1.1 404 Not Found
Content-Length: 153
Content-Type: text/html
Date: Thu, 19 Jan 2023 16:55:26 GMT
Server: nginx/1.17.1

>curl -4 -k -Ii
HTTP/2 404
content-type: text/html
date: Thu, 19 Jan 2023 16:55:32 GMT
server: nginx/1.17.1
content-length: 153


Sorry, I must have made a typo as this works.

>curl -6 -k -Ii https://\[2a03:b0c0:2:d0::14bf:4001\]/
HTTP/2 200
server: nginx
date: Thu, 19 Jan 2023 17:23:26 GMT
content-type: text/html
content-length: 43
last-modified: Mon, 24 Oct 2022 12:13:37 GMT
vary: Accept-Encoding
etag: "63568171-2b"
accept-ranges: bytes

>curl -6 -k -Ii https://\[2a03:b0c0:2:d0::d7d:d001\]/
curl: (28) Failed to connect to 2a03:b0c0:2:d0::d7d:d001 port 443 after 75341 ms: Couldn't connect to server

PING6(56=40+8+8 bytes) 2001:418:1::62 --> 2a03:b0c0:2:d0::14bf:4001
16 bytes from 2a03:b0c0:2:d0::14bf:4001, icmp_seq=0 hlim=47 time=145.005 ms
16 bytes from 2a03:b0c0:2:d0::14bf:4001, icmp_seq=1 hlim=47 time=143.931 ms
--- ping6 statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 143.931/144.468/145.005/0.537 ms

>curl -6 -k -Ii
HTTP/2 200
server: nginx
date: Thu, 19 Jan 2023 17:20:11 GMT
content-type: text/html
content-length: 114960
vary: Accept-Encoding
x-accel-version: 0.01
last-modified: Wed, 07 Dec 2022 09:44:59 GMT
etag: "1c110-5ef39c61a6c7e"
accept-ranges: bytes
vary: Accept-Encoding,User-Agent
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1
x-download-options: noopen
x-permitted-cross-domain-policies: master-only
x-dns-prefetch-control: on
referrer-policy: no-referrer-when-downgrade
strict-transport-security: max-age=31536000
content-security-policy: block-all-mixed-content
permissions-policy: geolocation=(); midi=(); push=(); sync-xhr=(); microphone=(); camera=(); magnetometer=(); gyroscope=(); speaker=(); vibrate=(); fullscreen=(); payment=()

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.


Thus I have an impediment from not able to access my DNS management, right? I hope tomorrow I have access again. I will update again when I have changed it and waited the DNS to change.

Thanks so far! Not one step further but so much learned already! I will update soon.


Kindly wait for more knowledgeable Let's Encrypt community volunteers to articulate who are concise.

1 Like

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.


This clarity certainly helps, but one thing to be clear in order of importance;

  1. AAAA IPv6 Record
  2. AAAA IPv4 record
  3. A IPv4 Record

Where is IPv6 A Record in this? In between 1 and 2 or between 2 and 3?

In my DNS management so far is an A record IPv6 with the default ip (


And an IPv4 A record pointing to my VPS

On the DNS Management side I have to change the IPv6 A record to my VPS's IPv6


That is what I have learned so far.

That being said, the opening post still is valid. I get that error while solving the challenge and this afternoon I also looked in the cert-manager controller logs and found the following.

Pod successful

cert-manager/challenges/http01/selfCheck/http01/ensurePod "msg"="found one existing HTTP01 solver pod" "dnsName"="" "related_resource_kind"="Pod" "related_resource_name"="cm-acme-http-solver-dqhc7" "related_resource_namespace"="default" "related_resource_version"="v1" "resource_kind"="Challenge" "resource_name"="nutrizone-nl-995pb-1677145622-3177127015" "resource_namespace"="default" "resource_version"="v1" "type"="HTTP-01"

Service successful

cert-manager/challenges/http01/selfCheck/http01/ensureService "msg"="found one existing HTTP01 solver Service for challenge resource" "dnsName"="" "related_resource_kind"="Service" "related_resource_name"="cm-acme-http-solver-n8blx" "related_resource_namespace"="default" "related_resource_version"="v1" "resource_kind"="Challenge" "resource_name"="nutrizone-nl-995pb-1677145622-3177127015" "resource_namespace"="default" "resource_version"="v1" "type"="HTTP-01"

Ingress succesful

cert-manager/challenges/http01/selfCheck/http01/ensureIngress "msg"="found one existing HTTP01 solver ingress" "dnsName"="" "related_resource_kind"="Ingress" "related_resource_name"="cm-acme-http-solver-b9mn4" "related_resource_namespace"="default" "related_resource_version"="v1" "resource_kind"="Challenge" "resource_name"="nutrizone-nl-995pb-1677145622-3177127015" "resource_namespace"="default" "resource_version"="v1" "type"="HTTP-01"

Challenge fails

cert-manager/challenges/acceptChallenge "msg"="error waiting for authorization" "error"="acme: authorization error for 403 urn:ietf:params:acme:error:unauthorized: 2a03:b0c0:2:d0::14bf:4001: Invalid response from 404" "dnsName"="" "resource_kind"="Challenge" "resource_name"="nutrizone-nl-995pb-1677145622-3177127015" "resource_namespace"="default" "resource_version"="v1" "type"="HTTP-01"

There is no A record for IPv6. IPv6 is defined with an AAAA record. IPv4 is defined with an A record.