I installed Let’s Encrypt via these instructions, but it changed my root path from /var/www/html to /usr/share/nginx/html – is there any way to reverse this?
I modified my sites-available default server block to the following (and restarted it), but it didn’t help:
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
# root /usr/share/nginx/html;
root /var/www/html;
index index.html index.htm;
# Make site accessible from http://localhost/
#server_name localhost;
server_name MYDOMAINHERE;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
# Uncomment to enable naxsi on this location
# include /etc/nginx/naxsi.rules
}
}
Any ideas?
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Enter your email to get $200 in credit for your first 60 days with DigitalOcean.
New accounts only. By submitting your email you agree to our Privacy Policy.
Definitely not best practice, but in an effort to get things working, I gave up on trying to change the root and just moved everything to the /usr/share/nginx/html path.
I tried changing the include link in nginx.conf and removing the server block from the file, but I now run into duplication errors (like “[emerg] a duplicate default server for 0.0.0.0:00 in etc/nginx/sites-available/digitalocean:21”) when testing nginx. There’s three .conf files in sites-available: digitalocean, default.bak and default.
I then tried to go back to the sites-enabled include, but noticed that the only .conf file symlinked in sites-enabled is digitalocean. Should I be using that one as my default?
Here’s my nginx.conf includes:
Here’s my sites-available default:
@marketing8b7cf186d951e4e8d
You should have a server block that’s listening on port 443, which is the port that is used for SSL. If each server block is listening on port 80, then SSL will not work.
So the first thing to do would be to check
/etc/nginx/sites-available
to see if there are any other server blocks (configuration files) that contain alisten 443;
directive.The NGINX plugin for CertBot is still in alpha, so there’s a chance it may not work as expected, thus it’s often better to use
certonly
and manually make the chances to your configuration.…
Ideally, all server blocks should be placed within the
./sites-available
directory and symlinked to the./sites-enabled
directory instead of placing them directly in thenginx.conf
file.That being said, I’m not a big fan of symlinking files, so I change the
include
line innginx.conf
to use the./sites-available
directory instead of./sites-enabled
.…
As far as configuration goes, the end result for a properly configured SSL-enabled server block will look something like this:
The above redirects all requests on port 80 to 443 (HTTP => HTTPS), defines a few security headers, and sets the path to your Let’s Encrypt (CertBot) certificate and private key.
In the above, you’d change instances of
domain.com
to your actual domain as well as:You’d replace
/path/to/content
with your actual storage path (where index.html, index.php, etc is).…
This line:
… is commented out, thus inactive, as not all NGINX installations have this file generated by default. It takes a little bit of time to generate, though I recommend it as it’s part of a complete SSL setup.
To create the file, you can run:
then
It could take anywhere from 5-6 minutes up to 10-15 depends on CPU. While it’s generating, you’ll see a series of: