Configuring nginx virtual hosts with sites-available / sites-enabled

I recently ran into an issue with how /etc/nginx/sites-enabled is used (or not) depending what nginx version you’re running on, or more likely according to this post, whether you’re running nginx on Debian/Ubuntu or the official nginx package.

The difference (which is pretty significant if you’re not expecting it), is that:

  • Debian/Ubuntu versions for nginx have sites-enabled included in nginx.conf by default
  • The official upstream nginx package does not

What this means is on Debian/Ubuntu, in /etc/nginx/nginx.conf you’ll have this include:

include /etc/nginx/sites-enabled/*;

but it’s missing if you run the upstream nginx package, like what seems to be included in the Docker image nginx:latest.

In my case running the Docker image nginx:latest every GET request was getting a 404 and the only clue was in my error.log each request was attempting to serve files from a default /usr/share/nginx/html folder, which is definitely not what was configured as my root in the config in /etc/nginx/sites-enabled:

open() "/usr/share/nginx/html/[url-request-here] HTTP/1.1" failed (2: No such file or directory)

Once I worked out what the issue was I just added the include line for sites-enabled.

Creating a single SSL certificate bundle from CA root and intermediate certificates

When you purchase an SSL certificate for a domain, e.g. to secure HTTPS usage with your web server, your certificate download may provide you several files like this:

youdomain.com.crt : this is your domain certificate

Files that look this are the root and intermediate certificates:

USERTrust_RSA_Certification_Authority.crt

Sectigo_RSA_Domain_Validation_Secure_Server_CA.crt

Depending how your SSL vendor supplies these files, the second two files may be provided already bundled in one file or two separate files.

To combine them together into one bundle file, use cat to concat the files:

cat yourdomain_com.crt USERTrustRSAAddTrustCA.crt AddTrustExternalCARoot.crt > domain_com.ca-bundle.crt

Open the file and check that each start and end comment for each cert are on their own line and not on the same line (see here).

WordPress 5.6 image upload error: not a valid JSON response

For larger image file uploads I’ve been getting this error recently:

Reducing the image file size and then retrying avoids the issue, but this adds additional steps.

Multiple posts online like this one suggest this is an error with the permalinks and resaving the current settings on that page in the Admin panel will fix the error, but this didn’t fix it for me.

Looking around in my server logs, I found this error in my /var/log/nginx/error.log:

2020/12/23 00:36:45 [error] 36#36: *311 client intended to send too large body: 4132609 bytes

This post suggests adding a client_max_body_size param in nginx.conf (or increasing the value already there). I added a larger value than the size in the error and this fixed the issue.

SSL certs upgraded, Docker images upgraded, ready to go!

I had to renew my SSL certs for this site, so while doing so I upgraded and addressed a few other issues.

First, apparently when I deployed the SSL certs last time I missed out some of the root certs in the chain. The vendor I used gives you each of the root certs individually and you need to manually concatenate them together yourself. More in another post on the steps I too to do this.

Since certs are part of my nginx Docker image, I rebuilt my image upgrading everything to latest versions. Since it was a also a couple of years since I last did this, I also had to go back through my posts here to work out the steps I took to deploy last time. I’ll post another update on the steps I took for this also later.