For a about one and a half years the webroot challenge was working for me fine. Now it is broken and I have no clue to get it working. I spent many hours again with several things browsed via the internet.
This works fine for authentification but it does not for registration:
With e.g. certbot certonly --webroot -w /path/to/root -d www.mediawikiwidgets.org --dry-run I get:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for www.mediawikiwidgets.org
Using the webroot path /path/to/root for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. www.mediawikiwidgets.org (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.mediawikiwidgets.org/.well-known/acme-challenge/PxS4t_GEM9Oj4fElEDL0dwa9NHUa1srhiwDj-PqOZ5w: "<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/D"
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: www.mediawikiwidgets.org
Type: unauthorized
Detail: Invalid response from
http://www.mediawikiwidgets.org/.well-known/acme-challenge/PxS4t_GEM9Oj4fElEDL0dwa9NHUa1srhiwDj-PqOZ5w:
"<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/D"
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address.
Apparently I have no idea how to mitigate. Perhaps there are some people around who may help me with my misery. Moreover I am utterly sorry to bother you with something like this but I personally am out of luck. Sadly the DNS challenge is no option for me.
I’m getting a 404 file not found error when I try to reach your challenge file. Which isn’t surprisingly, as certbot already removed it after cleaning up
Could you put a test file in /path/to/root/.well-known/acme-challenge/ ?
Also, your HTTP to HTTPS is completely broken when I removed the whole acme-challenge and well-known part of the URL. I’m guessing it’s because when you’re not having a DocumentRoot in your HTTP VirtualHost, but you are specifying a specific <Directory> directive, the whole Rewrite part isn’t called upon.
I’m guessing it’s because when you’re not having a DocumentRoot in your HTTP VirtualHost, but you are specifying a specific directive, the whole Rewrite part isn’t called upon.
No I showed the whole config file. Perhaps this is the issue. I am wondering why this is working for other domains like this.
Well, a few minutes ago, when I surfed to the HTTP site http://www.mediawikiwidgets.org/, I got a "Everything works" kind of example page of your webserver in German, not the redirect to HTTPS Ăłr your main site through HTTP. And now I'm getting the redirect. So you did change something
No and you can trust me on this one. However when testing different solutions it got this too in arbitrary occasions. What makes me crazy is that the page you are referring to is at /var/www/html/ whereas default.conf and default-ssl.conf specifiy /var/www/htdocs/. This is indeed driving me crazy too.
The error certbot provides suggests that it is getting /var/www/html/index.html. I do not know why since Apache is configured to go for /var/www/htdocs/…
No idea what is going on. The setup worked for one and a half years and it is still working for the other websites on the same server. I am clueless - no kidding.
Ok. So what to do? If I place a file it works like https://www.mediawikiwidgets.org/.well-known/acme-challenge/challenge.txt Moreover I wonder why it worked for one and a half years and now starts failing. The only difference is that I require user to log in. In the meantime I believe that this does not make a difference.
Also, in a certbot above you only specified -d www.mediawikiwidgets.org, NOT also -d mediawikiwidgets.org, which is required if you also want the base domain to be accessible through HTTPS.
Try the --manual plugin for testing purposes. The webroot plugin removes the challenge file again, which makes debugging sometimes a little bit more difficult.