HTTP challenge fails


#1

I’m having issues obtaining a certificate. A few months ago someone already had a working certificate, but last month it expired, so I’m trying to set up a new license. To my understanding, I have to issue a command from the server like:
certbot --staging --preferred-challenges=http --agree-tos --email name@example.com --break-my-certs -d natan-security.net -d www.natan-security.net --apache --debug-challenges

However, this results in an error:
Failed authorization procedure. www.natan-security.net (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.natan-security.net/.well-known/acme-challenge/NlmqO7IYCfx56u2WFD8Mmap8z0W_mceb4pGlvBtJfRg: "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<HTML><HEAD>\n<TITLE>404 Not Found</TITLE>\n</HEAD><BODY>\n<H1>Not Found</H1>\nTh"

I have also attempted using --manual, and then I can see that for the given challenge in my browser, and even at w3c-validator (my first attempt to validate my server isn’t blocking different countries), while certbot always shows the 404 result. What can cause this issue?

The strangest part is that my server gives a different HTML-document for a 404-message. With an added character:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /.well-known/acme-challenge/lrKZpQbfQQdLU1XsGUVva14dQEWg66NpLBvPg9gJWcI3 was not found on this server.</p>
<hr>
<address>Apache/2.4.18 (Ubuntu) Server at www.natan-security.net Port 80</address>
</body></html>

Thanks in advance


#2

That is indeed the problem, good job for spotting it yourself: https://letsdebug.net/www.natan-security.net/16886

Check that your IPv6 and IPv4 records point to the same physical server.


#3

Thanks a lot, didn’t think of that one. I’ve updated it, but apparently it’s not updated yet at your lookup. I’ll check again later today or monday.


#4

LE doesn’t cache DNS entries.
All queries are “fresh” and “new”; they go directly to your authoritative name servers.
So you should be able to check right away.


#5

rg305 is right - there is no caching (on the test either). Your nameserver is still currently serving the same IPv6 record that it was from my original test:

$ dig +noall +answer @ns1.ccchost1.nl www.natan-security.net aaaa
www.natan-security.net. 14400   IN      AAAA    2a00:8240:ccc::141

This IPv6 address still has a different server signature to the one from your IPv4 address.


#6

This is strange. I surely changed the quad-A record at transip, our hosting provider, and just changed it again (currently to the translated IPv4 address). I’ll look into it monday.


#7

I think you are updating the DNS records in the wrong place.

Indeed, you have changed your AAAA record at transip:

$ dig +noall +answer @ns0.transdns.eu www.natan-security.net aaaa
www.natan-security.net. 0       IN      CNAME   natan-security.net.
natan-security.net.     86400   IN      AAAA    2a01:7c8:3:1337::27

but your domain registration is set to the nameservers of an entirely different host!

natan-security.net.     172800  IN      NS      ns1.ccchost1.nl.
natan-security.net.     172800  IN      NS      ns2.ccchost1.nl.

You’ll need to change the AAAA record at the above.


#8

I changed the DNS to transip DNS servers, and it seems to be OK. Still guessing why it was ever changed in the first place…


#9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.