Adding dedicated cert for a domain – Nginx and Letsencrypt (certbot)

Real quick and simple certbot commands to create a certificate only for a new domain/subdomain.
Then install and update your preconfigured nginx config for said domain with the newly created certs.

Prerequisites

  • Nginx configured for your target domain eg:
# /etc/nginx/sites-enabled/example.com
server {
    root /var/www/example.com/public;
    index index.php index.html index.htm;

    server_name example.com www.example.com;

    location ~ /.well-known {
        allow all;
    }
    location ~ /\.ht {
        deny all;
    }

    listen 443 ssl;
    listen 80;
}

Creating and Installing New Certificates

# For additional domains to be covered by the same cert you can append with -d <another.com>
$ sudo certbot certonly --cert-name sub01.example.com -d sub01.example.com

# List existing certs
$ sudo certbot certificates

# Configure certs for nginx
$ sudo certbot --nginx

Increasing HTTP post file upload limit for Nginx and PHP (WordPress)

I have found myself time and time again having to configure the file upload limits of most webservers that I have worked on. And a lot of the time I have found it can get a bit confusing and frustrating to find where exactly it is being limited.

For standard PHP and Nginx set ups we need to look at the following settings:
In php.ini you will want to look for:

; Maximum allowed size for uploaded files.
upload_max_filesize = 40M
; Must be greater than or equal to upload_max_filesize
post_max_size = 40M

And for Nginx itself there is the client_max_body_size config variable that needs to be set.

client_max_body_size 20M;

However this is where it can get a bit messy if someone has configured this value previously. I spent a bit of time trying to figure out why this wasn’t working on my set up and discovered that it had been set at the highest level the http context section in /etc/nginx/nginx.conf

This meant that the values I was setting in the lower site specific configs were being ignored as the http block takes precedence over anything set in my site-enabled configs.
For reference, the order of context priorities are as follows:

  1. http
  2. server
  3. location

Some external references:

WordPress plugins page error – X-Frame-Options does not permit framing

firefox
Firefox console error message showing: Load denied by X-Frame-Options

Have you ever had an issue embedding a frame or iframe on your website? Problems like the content not being loaded or displayed at all?

In my case I came across this problem when trying to preview plugins in my WordPress panel.
If you checked the browser console log, you might have seen similar message to:

Load denied by X-Frame-Options: https://yourwebsite.here does not permit framing.

This error message is caused by the web server (in my case Nginx) sending a HTTP header ( X-Frame-Options ) that is telling your browser to not allow loading of embedded frame content. This is security measure to prevent attacks known as clickjacking.

A quick way to see which config file(s) might be setting this header option for Nginx is:

sudo grep -R "X-Frame-Options" /etc/nginx/

which will output the offending files if they exist.

In my case the solution was to simply modify a single value in one of my configs. I changed:

add_header X-Frame-Options DENY

to:

add_header X-Frame-Options SAMEORIGIN

Saving the config edit and restarting Nginx was enough to resolve this issue for me. “SAMEORIGIN” tells the browser to allow loading content in frames as long as the source content is from the same origin as the parent page (current website).

Resources: