Error message when running certificate creation sh-file

I am trying to run the letsencrypt sh file on my raspberry pi for ownCloud. I receive the following error message:

My domain is: [maudach-cloud.ddns.net]

I ran this command: sudo /etc/letsencrypt/maudach-cloud.sh

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for maudach-cloud.ddns.net
Using the webroot path /var/www/html/owncloud for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Running post-hook command: service nginx reload
Hook command “service nginx reload” returned error code 1
Error output from service:
nginx: unrecognized service

Failed authorization procedure. maudach-cloud.ddns.net (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://maudach-cloud.ddns.net/.well-known/acme-challenge/DRwgE4m4Kwy_UlyNWz2l7PLV-sKO1VvlxYCuL-tLSS0404 Not Found
Not Found

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

Domain: maudach-cloud.ddns.net
Type: unauthorized
Detail: Invalid response from
http://maudach-cloud.ddns.net/.well-known/acme-challenge/DRwgE4m4Kwy_UlyNWz2l7PLV-sKO1VvlxYCuL-tLSS0:

404 Not Found
Not Found

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.

My web server is (include version): Don’t know

The operating system my web server runs on is (include version): Raspbian (latest version)

My hosting provider, if applicable, is: RaspberryPi at Home

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): Don’t know

Let’s Encrypt is trying to reach out to http://maudach-cloud.ddns.net/.well-known/acme-challenge/DRwgE4m4Kwy_UlyNWz2l7PLV-sKO1VvlxYCuL-tLSS0 to retrieve the challenge file, but your server (or something in the way) is returning a 404 error instead. I actually get a timeout when I try that myself, is 91.66.235.116 still the correct IP?

$ curl -v http://maudach-cloud.ddns.net/.well-known/acme-challenge/DRwgE4m4Kwy_UlyNWz2l7PLV-sKO1VvlxYCuL-tLSS0
* About to connect() to maudach-cloud.ddns.net port 80 (#0)
*   Trying 91.66.235.116...
* Connection timed out
* Failed connect to maudach-cloud.ddns.net:80; Connection timed out
* Closing connection 0
curl: (7) Failed connect to maudach-cloud.ddns.net:80; Connection timed out

What are the contents of /etc/letsencrypt/maudach-cloud.sh? if you place a test file in /var/www/html/owncloud/.well-known/acme-challenge, are you able to load that from a connection external to your network, e.g. your phone, not on wifi?

Okay, so I try to answer this best way possible. I think I know the root cause but I don’t know how to solve it.

Basically I have 2 instances of clouds running on 2 PIs. For the first one (https://huberconsulting.ddns.net/) everything works perfect, including certbot. If I type “https://huberconsulting.ddns.net/” it links me directly to the owncloud login page, which is actually located at “https://huberconsulting.ddns.net/owncloud”.

If I do the same for my other cloud by typing “https://maudach-cloud.ddns.net” I receive the Apache2 “It works” page. So it is not redirecting to “https://maudach-cloud.ddns.net/owncloud”, which is the login page. I also can only access a file (e.g. 123456789) at “.well-known/acme-challange”, if I type “https://maudach-cloud.ddns.net/owncloud/.well-known/acme-challange/123456789” in front of it. For the other cloud also “/owncloud” appendix is not required.

So I assume, this redirection is somewhere missing.

Besides, if I compare the two clouds, I am missing the “letsencrypt” folder at “/var/www/”, which is there with lots of contents for the “working” cloud.

Currently, when I run the following command “certbot certonly --webroot -w /var/www/html/owncloud/ -d maudach-cloud.ddns.net”, I receive the following error. (a command like “certbot certonly --webroot -w /var/www/html/owncloud/ -d maudach-cloud.ddns.net/owncloud” is not working,as it is malformatted):

Domain: maudach-cloud.ddns.net
Type: unauthorized
Detail: Invalid response from
http://maudach-cloud.ddns.net/.well-known/acme-challenge/XBKx0NEumz9tcfJ4ftAE87S672Jbvzox_1Bto2WBgfM

404 Not Found
Not Found

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.

Any suggestions? Please help.

Can anyone help, please?

Hi @cyrix_records,

Technically this is not true ;), your owncloud is located at /var/www/html/owncloud but this link doesn't point to it https://huberconsulting.ddns.net/owncloud.

I suppose the DocumentRoot defined for this domain is /var/www/html and it should be /var/www/html/owncloud so you should change this in your VirtualHost definition or in your apache2.conf file (I don't know if you are using Virtual Host or how did you configure your apache web server).

It is not important for the tests but just in case, there is a typo, it is acme-challenge instead of acme-challange.

The command you wrote and the error message doesn't match, I'm guessing you are trying this command:

certbot certonly --webroot -w /var/www/html/owncloud/ -d maudach-cloud.ddns.net/owncloud

and as certbot said, you can't use urls defining the domain name so here the right command should be:

certbot certonly --webroot -w /var/www/html/owncloud/ -d maudach-cloud.ddns.net

So... I think the only problem here is that you should define the right DocumentRoot directive for domain maudach-cloud.ddns.net pointing to /var/www/html/owncloud in your apache conf, where you should change it?... it will depend on how you have configured it but as you have 2 instances and the other one is working fine you should take a look to the conf of the working one.

Cheers,
sahsanu

Blockquote
I suppose the DocumentRoot defined for this domain is /var/www/html and it should be /var/www/html/owncloud so you should change this in your VirtualHost definition or in your apache2.conf file (I don’t know if you are using Virtual Host or how did you configure your apache web server).

Since I did not change anything in my apache2.conf file, I assume it must be the files in "sites-available" folder, right? In there are 3 files, which are 000-default.conf, default-ssl.conf and owncloud.conf. All of those are active with command a2ensite. I adjusted 000-default.conf and default-ssl.conf.
If I now browse to https://maudach-cloud.ddns.net, I am redirected to the owncloud login page. So this works now.

However, I still receive an error if I run the certbot command you mentioned, which is certbot certonly --webroot -w /var/www/html/owncloud/ -d maudach-cloud.ddns.net

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for maudach-cloud.ddns.net
Using the webroot path /var/www/html/owncloud for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Unable to clean up challenge directory /var/www/html/owncloud/.well-known/acme-challenge
Running post-hook command: service apache2 reload
Failed authorization procedure. maudach-cloud.ddns.net (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://maudach-cloud.ddns.net/.well-known/acme-challenge/bHxTnDWRwDGxqhpp3a4-qCMQs36NQTbTG6uid-cFuJE

@sahsanu Can you help me with this as well? Anything more you would need?

Hi @cyrix_records,

So you should not issue more certbot commands till you resolve this issue or you could reach some limits that will prevent to issue a new certificate.

Now you need to know the reason letsencrypt boulder can’t reach the challenge so, lets test it creating a new file:

mkdir -p /var/www/html/owncloud/.well-known/acme-challenge/
echo -n "this is a test" > /var/www/html/owncloud/.well-known/acme-challenge/test

Once done, you should be able to reach it with your browser:

http://maudach-cloud.ddns.net/.well-known/acme-challenge/test

or from command line:

curl -ikL http://maudach-cloud.ddns.net/.well-known/acme-challenge/test

If you can see the text “this is a test” then you should be able to issue the certificate, if you can’t, we need to guess what is the reason.

Also, could you please show the output of the following command?.

grep -ri well-known /etc/apache2/*

Cheers,
sahsanu

Hi @sahsanu

thanks first of all for your help. Really appreciate it.

I did as you told me and I cannot reach the file. Interesting though, that I can access the file if I use the link via https. Then the test content appears.

Output of grep -ri well-known /etc/apache2/* as follows:

/etc/apache2/sites-available/000-default.conf:	Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/
/etc/apache2/sites-available/000-default.conf:	Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/
/etc/apache2/sites-available/000-default.conf: <Directory "/var/www/letsencrypt/.well-known/acme-challenge/">
/etc/apache2/sites-available/000-default.conf:      RedirectMatch 404 "^(?!/\.well-known/acme-challenge/[\w-]{43}$)"

Ok, so seems you are using an Alias, another test:

mkdir -p /var/www/letsencrypt/.well-known/acme-challenge/
echo -n "one more test" > /var/www/letsencrypt/.well-known/acme-challenge/test

Once done, you should be able to reach it with your browser:

http://maudach-cloud.ddns.net/.well-known/acme-challenge/test

or from command line:

curl -ikL http://maudach-cloud.ddns.net/.well-known/acme-challenge/test

If you get the text “one more test” the you should be able to issue a new certificate but this time you should change the webroot parameter.

certbot certonly --webroot -w /var/www/letsencrypt/ -d maudach-cloud.ddns.net

Cheers,
sahsanu

So it is still not working. I still get the same 404 error. However, as I said, with https it is working. Can it be, that I accidentally created some sort of a “https” only linkage or so?
I hope we find the root cause, as I do not plan to install the whole thing again. :slight_smile:

By the way, this is also part of my .htaccess file in the owncloud folder:

<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
  RewriteRule ^\.well-known/host-meta /public.php?service=host-meta [QSA,L]
  RewriteRule ^\.well-known/host-meta\.json /public.php?service=host-meta-json [QSA,L]
  RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L]
  RewriteRule ^\.well-known/caldav /remote.php/dav/ [R=301,L]
  RewriteRule ^remote/(.*) remote.php [QSA,L]
  RewriteRule ^(?:build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
  RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.*
  RewriteRule ^(?:\.|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>

I would need to review your apache conf.

As root:

tar zcvf /root/cyrix_records_etc-apache2.tar.gz /etc/apache2/

And put created file /root/cyrix_records_etc-apache2.tar.gz in your site so we can download it.

Note: I will leave for some hours in a few minutes so if you don’t receive any response from my side is because I’m not here ;).

Cheers,
sahsanu

Done. You can download it here https://maudach-cloud.ddns.net/.well-known/acme-challenge/cyrix_records_etc-apache2.tar.gz

Hi,

The test doesn’t work because you have this RedirectMatch and it expects a file of 43 characters:

RedirectMatch 404 "^(?!/\.well-known/acme-challenge/[\w-]{43}$)"

If you want to test it create a 43 characters test file.

echo -n "43 characters test" > /var/www/letsencrypt/.well-known/acme-challenge/DRwgE4m4Kwy_UlyNWz2l7PLV-sKO1VvlxYCuL-tLSS0

Once done, you should be able to reach it with your browser:

http://maudach-cloud.ddns.net/.well-known/acme-challenge/DRwgE4m4Kwy_UlyNWz2l7PLV-sKO1VvlxYCuL-tLSS0

or from command line:

curl -ikL http://maudach-cloud.ddns.net/.well-known/acme-challenge/DRwgE4m4Kwy_UlyNWz2l7PLV-sKO1VvlxYCuL-tLSS0

Anyway, you should be able to issue a new cert but using this command:

certbot certonly --webroot -w /var/www/letsencrypt/ -d maudach-cloud.ddns.net

Cheers,
sahsanu

Hi @sahsanu

do I need this RedirectMatch? I think I copied this from some German tutorial. Or can we make it work ‚as usual‘ via the .../owncloud/.well-known/acme-challenge folder? Then both clouds and the vertont commands would work the same way.

Now it is me, being on the road, so I haven’t checked it yet. Will do, when at home.

Thanks

Hi @cyrix_records,

That RedirectMatch is only there to return a 404 error if the url requested doesn't contain 43 ascii characters so you can remove it if you want.

If you want that the challenge goes to your document root /var/www/html/owncloud/... then you need to edit your 000-default.conf file and remove a few lines:

Current file:

<VirtualHost *:80>
        ServerName maudach-cloud.ddns.net

        ServerAdmin administrator@huber-consulting.de
        DocumentRoot /var/www/html/owncloud
        Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/
        Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/
 <Directory "/var/www/letsencrypt/.well-known/acme-challenge/">
      Options None
      AllowOverride None
      ForceType text/plain
      RedirectMatch 404 "^(?!/\.well-known/acme-challenge/[\w-]{43}$)"
  </Directory>

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

and you need to remove the Alias and the Directory section:

<VirtualHost *:80>
        ServerName maudach-cloud.ddns.net
        ServerAdmin administrator@huber-consulting.de
        DocumentRoot /var/www/html/owncloud
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

and once you have saved the file, you should reload or restart your apache server.

systemctl reload apache2

or

systemctl restart apache2

Cheers,
sahsanu

2 Likes

Hey @sahsanu

this solved it! You are amazing. Thank you so much for the support. I really appreciate your help and time.

Regards,
Georg

2 Likes

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