Using the webroot path /var/www/demo for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. www.example.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.example.com/.well-known/acme-challenge/tD5IpKZdzKYb4d-r16--j4S2a1oUo2sVKkCh0GyoB-Y: "<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
I have been using my own wrapper script around your
so when I got this error on a new server I knew it was something local to my server … root cause was I had setup nginx with its normal config which broke your code
SOLUTION : just remove my nginx install as per
sudo apt-get remove --purge nginx-*
then letsencrypt ran OK … Would be great for other folks if instead of your above error messages instead it performed a quick probe to recognize the server has a preexisting nginx config in place and CLEARLY stated as such so that people would be guided to the solution … as is the error message gives no such clue
I do have a project on the back burner to have Certbot provide links to an “error detail” web site that explains all of the meanings and likely causes of validation errors from the certificate authority.
In this case, when you specified --webroot-path=$DIR, what you were telling Certbot is that it could serve files on all of the domains in $DOMAINS by putting files in $DIR and that they would then appear at the corresponding locations on the web site. If this is not true for any reason, then your use of --webroot-path=$DIR is not correct from Certbot’s point of view. If the directory on the filesystem corresponding to one domain in the $DOMAINS list is different from that for a different one, then you would need multiple --webroot-path options (and this is what’s being referred to when it says Using the webroot path /var/www/demo for all unmatched domains).
Clearly it would be more helpful if Certbot did provide a link to explain the meaning and the potential causes of this error.
I don’t believe that --webroot is ever going to directly attempt to analyze what web server configuration people do or don’t have because one of the ideas of --webroot is that it’s relatively independent of what web server you use, and that the user has the responsibility to choose the appropriate --webroot-path when using it. For example, it can work with web servers that we’ve never heard or don’t explicitly support, of as long as --webroot-path is set correctly! (Before we had any explicit nginx support in Certbot at all, we used to encourage people to use --webroot on machines with nginx specifically because it didn’t have a web server dependency.)