Raspbian, Stretch, Apache2, Webroot, Failed Authorization

Help
1

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:
n0tf0und.com note: zero not capital O
I ran this command:
sudo certbot --authenticator webroot --installer apache
entering n0tf0und.com for domain and /var/www/html for webroot
It produced this output:
Failed authorization procedure. n0tf0und.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://n0tf0und.com/.well-known/acme-challenge/uqWZ_3IWB-dwtfSa0aufq6FzWb5wcGwC3SxCrTRdfYI: "

EDM"

My web server is (include version):
Server version: Apache/2.4.25 (Raspbian)
Server built: 2017-09-19T18:58:57
Server’s Module Magic Number: 20120211:68
Server loaded: APR 1.5.2, APR-UTIL 1.5.4
Compiled using: APR 1.5.2, APR-UTIL 1.5.4
Architecture: 32-bit
The operating system my web server runs on is (include version):
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
Running on Raspberry Pi 2
My hosting provider, if applicable, is:

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

http://n0tf0und.com/.well-known/test.txt
The text file in .well-known works inside & outside firewall
SSL module enabled
Port 80 and 443 open on Firewall
I purged and reinstalled Apache leaving the configuration at defaults.
Certbot version 0.21.1 from Debian stretch-backports
all apt-get update and dist-upgrade done.

2

Euh, the site n0tf0und.com runs IIS 7.5 according to its HTTP response headers? Not Apache.

Hmm, I’ve got multiple IP addresses from my ISPs DNS server. First, I got 184.168.221.30. Then I got 50.63.202.23. And when I try a dig trace (so to check without caching), I got 184.168.221.7?

n0tf0und.com.		600	IN	A	184.168.221.7
n0tf0und.com.		3600	IN	NS	ns45.domaincontrol.com.
n0tf0und.com.		3600	IN	NS	ns46.domaincontrol.com.
;; Received 109 bytes from 2607:f208:302::17#53(ns46.domaincontrol.com) in 8 ms

 

n0tf0und.com.		600	IN	A	50.63.202.25
n0tf0und.com.		3600	IN	NS	ns45.domaincontrol.com.
n0tf0und.com.		3600	IN	NS	ns46.domaincontrol.com.
;; Received 109 bytes from 216.69.185.23#53(ns45.domaincontrol.com) in 21 ms

If you try multiple times, it responds with multiple and many different IP addresses, time after time…

When I take a look of the source code of your “test file”, you’d get this:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<html>

<head>
  <title>EDM2.0 </title>
  <META name="keywords" content="Electronic Decision Maker">
</head>
<frameset rows="100%,*" border="0">
  <frame src="http://68.74.132.15/.well-known/test.txt" frameborder="0" />
  <frame frameborder="0" noresize />
</frameset>

<!-- pageok -->
<!-- 07 -->
<!-- -->
</html>

Sometimes, the URL of the test file is rewritten to something including a random piece of characters like http://n0tf0und.com/mMSTX/.well-known/test.txt for no good reason…

So I assume 68.74.132.15 is the IP address of the end-point running your Raspberry Pi. And you’re using some kind of redirect service from your domain name to the IP address 68.74.132.15.

Alas, you cannot use certbots webroot authenticator with such redirect services. certbot needs direct access to the webroot of the webserver which directly runs the site, without frames and other stuff.

3

You are correct about redirecting
the domain name is from go daddy and i use forwarding with masking to 68.74.132.15
Not sure why the IP’s vary, must be a Go Daddy thing

I tried running Certbot without the masking and got a different error.
I’ll remove the mask and post the results again.

4

mask removed
now I get

5

Let's Encrypt doesn't follow redirects to IP addresses. http://example.com/ yes, http://192.0.2.1/ no.

Why not disable the forwarding service and set an A record for 68.74.132.15?

6

68.74.132.15 is lightspeed.miamfl.sbcglobal.net
residential internet
not sure how to do that or if it is even possible.
Thanks for the tip

7

ISPs can’t control what DNS names you point at their IP addresses. :slight_smile:

8

…but you’ve registered your domain name somewhere, right? Perhaps you’ve got a DNS control panel there?

9

In case you were responding to me, I meant that the ISP can’t prevent this (which is what I thought @n0tf0und might be wondering about).

1 Like
10

I’ll look into that
I do not have a fixed IP, but it seldom changes

11

So I went to the Go Daddy control panel and changed the A record from 600 ms to one hour.
I was prompted to re-enter the IP, and did so.
Ran Certbot again and it worked.
Not sure what I changed or why it worked.
Thanks for the help

12

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