Authorization failing with 404 but file is being properly served

Help
1

Hi,

I’m having trouble trying to install a certficate. I’ve done the same procedure before succesfully but this time it’s not working.

I’m manually creating the file it’s asking me for here:

http://igloofest.ca/.well-known/acme-challenge/sx5E4eWF3y0QWtU2cv3JoARvjCaf6KSWoCKwJ8oQhjs

But the output is telling me the file is not being found. Not sure where the problem could be…

My domain is: igloofest.ca

I ran this command: sudo certbot --manual certonly

It produced this output:

Failed authorization procedure. igloofest.ca (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://igloofest.ca/.well-known/acme-challenge/sx5E4eWF3y0QWtU2cv3JoARvjCaf6KSWoCKwJ8oQhjs: "<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>"

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: igloofest.ca
   Type:   unauthorized
   Detail: Invalid response from
   http://igloofest.ca/.well-known/acme-challenge/sx5E4eWF3y0QWtU2cv3JoARvjCaf6KSWoCKwJ8oQhjs:
   "<html>
   <head><title>404 Not Found</title></head>
   <body bgcolor="white">
   <center><h1>404 Not Found</h1></center>
   <hr><center>"

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address.

My web server is (include version): nginx/1.10.3 (Ubuntu)

The operating system my web server runs on is (include version): 16.04.4 LTS

My hosting provider, if applicable, is: Linode

I can login to a root shell on my machine (yes or no, or I don’t know): Yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No

2

I figured it out looking through the logs: my nginx installation was not properly configured for ipv6 so was not handling the requests. My fault, but this should maybe be documented somewhere to help others with troubleshooting?

1 Like
3

Hi @33degrees

the ipv6 - configuration is sometimes a problem. But there are tools like letsdebug

to check that.

Often it's this

problem. The ipv6 points to another server or the ipv6 - vHost isn't configured.

4

Hi, thank you for the link to the tool, I will use it next time I have problems.

My first attempt at creating a certificate was with the nginx plugin, I wonder if it’s feasible for it to detect the missing ipv6 configuration?

1 Like
5

The tool sends GET - requests: To every ip-address found. Sometimes, ipv4 answers with a (correct) http status 404, but ipv6 answers with a timeout, a connection refused or a http status 200.

Or one ip-address sends a nginx header, the other an Apache-header.

6

What I mean is, the nginx plugin parses the nginx configuration to figure out which server names are configured. It could potentially check if they’re setup for ipv6.

1 Like
7

This is only a part of the solution. When ordering a certificate and using http-01 - validation, Letsencrypt checks, if there are ipv4- and ipv6 - addresses. Then addresses are randomly picked and checked.

But I don't think that a letsencrypt - client (like certbot) checks these dns-settings and checks, if there is an ipv6 address, but no ipv6 - webserver - setup.

8

I think the best way might be a future integration with something like letsdebug, perhaps via an API or generating a link to "consult letsdebug to learn more about reasons why this certificate request may have failed".

1 Like
9

That would be a great idea. Could be added there:

To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Check your settings with https://letsdebug.net/
1 Like
10

I bet doing this would reduce Certbot questions on the forum by about 5-10%.

One thing about this is that we’ve seen that Certbot versions stick around for a long time in older OS packages (until recently we had quite a lot of users still on Certbot 0.10.0, which is missing all sorts of functionality). So, if we mention letsdebug, we might want to be sure that @_az plans to keep running it for a long time, because there will potentially be users using any given release of Certbot for a long time.

2 Likes
12

If 5-10% is an accurate assessment, it’s probably not worthwhile. Developing first-party diagnostic abilities in Certbot might be better (that upload logs, ACME client + webserver configuration, system information, bound processes, network connectivity, NAT detection, make a dry-run). All stuff that is externally impossible to determine. That’s a huge time and sanity saver for our own ACME client for which we provide support to a large user base with 2 people. And life without this will be even harder once/if the ACME v3 signed POST-for-GET changes land.

But it seems that the challenge is slightly different for a public forum where data sharing is more of a concern so I don’t know what the solution is (and users’ domains showing up on this site in SRPs is a major unaddressed problem too). For Certbot it seems like the idea was already considered and not done:

https://github.com/certbot/certbot/issues/1019

1 Like
13

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