Trouble after installing letsencrypt cert

Hi guys!

I used this guide/script to successfully install Nextcloud: https://www.c-rieger.de/spawn-your-nextcloud-server-using-one-shell-script/

Everything worked as it should, but after I ran the script for installing the ssl certificate I could no longer access the webGUI (the web page is just blank white).

The logs told me that the databse user in config.php had changed and access were denied. I changed the username back to what I entered at the initial installation, but I still can’t access the webGUI and I see no errors in the logs.

Any ideas where to look? Thanks!

any error messages?
did you look at the config files with were change during the run of the script? and compare them with the backuped files?

diff /etc/nginx/conf.d/nextcloud.conf /etc/nginx/conf.d/nextcloud.conf.orig
diff /etc/nginx/ssl.conf /etc/nginx/ssl.conf.orig
diff /var/www/nextcloud/config/config.php /var/www/nextcloud/config/config.php.orig


based on Carstens tutorial. you may try it instead of his scripts.

1 Like

Thank you for taking your time to answer!

I got no errors while running the scripts. Only error I’ve seen was the one about access denied to maria DB. That message stopped when I changed the username in config.php.

Running the diff gave this (substituted mydomain):


diff /etc/nginx/conf.d/nextcloud.conf /etc/nginx/conf.d/nextcloud.conf.orig
2c2
< server_name mydomain;
---
> server_name nextcloud;
13c13
< server_name mydomain;
---
> server_name nextcloud;

diff /etc/nginx/ssl.conf /etc/nginx/ssl.conf.orig
1,3c1,6
< ssl_certificate /etc/letsencrypt/live/mydomain/fullchain.pem;
< ssl_certificate_key /etc/letsencrypt/live/mydomain/privkey.pem;
< ssl_trusted_certificate /etc/letsencrypt/live/mydomain/chain.pem;
---
> ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem;
> ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key;
> ssl_trusted_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem;
> #ssl_certificate /etc/letsencrypt/live/YOUR.DEDYN.IO/fullchain.pem;
> #ssl_certificate_key /etc/letsencrypt/live/YOUR.DEDYN.IO/privkey.pem;
> #ssl_trusted_certificate /etc/letsencrypt/live/YOUR.DEDYN.IO/chain.pem;
12,13c15,16
< ssl_stapling on;
< ssl_stapling_verify on;
---
> #ssl_stapling on;
> #ssl_stapling_verify on;

diff /var/www/nextcloud/config/config.php /var/www/nextcloud/config/config.php.orig
7c7
< 0 => 'mydomain',
---
> 0 => 'nextcloud',
14,15c14,15
< 'overwrite.cli.url' => 'https://mydomain',
< 'dbname' => 'mydomain',
---
> 'overwrite.cli.url' => 'https://nextcloud',
> 'dbname' => 'nextcloud',

the diff looks ok. that’s what should happen. i think.

the files in /etc/letsencrypt/live exist?

your browser receives the certifcate?

to test if your web-server and php is configured ok create a file info.php in /var/www/nextcloud (or put at the top of index.php)

<?php
// Zeigt alle Informationen (Standardwert ist INFO_ALL)
phpinfo();
?>

you should see a php info page.
delete it after the test.

I have a single file in /etc/letsencrypt/live called mydomain.

When accessing the server in my browser, it says that the connection is secure and verified by letsencrypt.

I put the code in at the top of index.php and when I accessed the server I saw a bunch of info.

EDIT: I think I found the problem. The name of the databse was also changed in config.php. Mydomain didn’t exist as a database, so I changed it back to the name of my database and now it seems to work.

Thanks a bunch for teaching me this new awsome tool (diff) !

1 Like

yes. of course. @riegerCLOUD replaces every appearance of $YOURSERVERNAME with $DYNDNSNAME
so if you name your database “$YOURSERVERNAME=nextcloud” that will be replaced as well.

sudo -u www-data sed -in 's/'$YOURSERVERNAME'/'$DYNDNSNAME'/' /var/www/nextcloud/config/config.php
1 Like

That seems a bit backwards. Is it standard procedure to name the database the same as the servername? I mean, there might be more databases hosted on the same machine.

@riegerCLOUD hardcoded the db name into his script.

he didn’t foresee what would happen when someone name the server also nextcloud. that is to say that the sed command will fail.

it would be better to use occ to do the job. example:

php occ config:system:set overwrite.cli.url --value "https://$DYNDNSNAME"

p.s.: neither carstens shell script nor my ansible playbook are indent to run on a server where are already other services installed. you can do this but you have to know exactly how you server is configured before and what the scripts are doing. e.g. both install and configure a web server (nginx) without checking if there is running web server.

Aah, I understand the problem now! Very interesting.

I guess the password of your db is also “nextcloud”. That’s why it was changed after you run the ssl script.

You may change it. In case some how know you is reading here as well. Or your db is accesible from the internet. :wink:

No, fortunetly the password was not affected, haha. Made sure at installation to put in a strong password. Only the user named “nextcloud” changed.

However, the password is stored in plain text in config.php, is that really ok?

PWD <-> this is as designed by Nextcloud!

The script is now more flexible, you will be asked for the databasename and the overwrite-url will be set using occ command.

1 Like