Kudos to the LetsEncrypt tool dev(s) for very good security score!

As soon as I got my site on the web with HTTPS I hit it from the Qualsys SSL Labs test page and here’s the very pleasing result::

As a complete n00b to ErpNext as of a week ago, seeing this test result further convinces me that ErpNext has been a good choice.

However, there’s a warning there that’s worth noting:

This server supports TLS 1.0 and TLS 1.1. Grade will be capped to B from January 2020

If you are OCD and cannot abide the thought of having less than an A+ rating here are some easy tweaks I used to upgrade my site:

Generate a fat Diffie Hellman file:

    cd /tmp
    openssl dhparam -out dhparams_4096.pem 4096
    sudo mkdir -p /etc/ssl/private
    sudo mv dhparams_4096.pem /etc/ssl/private

Deprecate the obsolete SSL protocols and link to the dhparams file

Replace the line …

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

… with …

	ssl_protocols TLSv1.2 TLSv1.3;
	ssl_dhparam /etc/ssl/private/dhparams_4096.pem;

Disallow HTTP; Accept only HTTPS

Below the line add_header X-Frame-Options "SAMEORIGIN"; add a new line as follows

Instead of …

    add_header X-Frame-Options "SAMEORIGIN";

… you want …

    add_header X-Frame-Options "SAMEORIGIN";
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";

Then …

    sudo service nginx restart;

… and get …

There are a bunch of other tricks, including helping NGinx process SSL much more quickly than the current settings support, which you can find easily by searching “A+ SSL Labs Nginx”;


Hello Martin,

I was trying to follow along with your post to upgrade my SSL security scores to “A” or better and I am not sure what file to edit in order to deprecate the old TLS protocols. Your instructions indicate that lines need to be both edited and added to a file, but the file name and location is not indicated here.

Can you elaborate just a bit?

I thought at first that it might be the nginx.conf file from the ~/frappe-bench/config directory, but I could not find the line regarding X-Frame-Options, and using the first edit about the TLS protocols broke nginx, so I reversed them.

Or maybe could the difference be because I am trying to update a v10 site versus whatever version site you were using?

Any pointers would be greatly appreciated. :grin:


Hi @bkm

ErpNext’s developers decided on something I disapprove of: not using the standard sites_available and site_enabled directories to store, or hyperlink to, server block files. Instead they use the conf.d directory which should used for global settings that affect all virtual hosts. It’s not a big deal really, it’s certainly not bad enough to require correction. (It bugs me anyway though, and why is the site’s NGinx virtual host definition not kept in the site’s directory?? )

As usual, Digital Ocean explains this much better than I could :: How To Set Up Nginx Server Blocks (Virtual Hosts)

To your question…

At the foot of the file /etc/nginx/nginx.conf you’ll find a directive:

include /etc/nginx/conf.d/*.conf;

In the directory /etc/nginx/conf.d, you’ll find a symlink

lrwxrwxrwx 1 root root   44 Feb  7 09:11 frappe-bench.conf -> /home/erpnext/frappe-bench/config/nginx.conf

In other words, your site is defined in /home/erpnext/frappe-bench/config/nginx.conf.

The second server block definition in that file begins :

server {        
        listen 443 ssl;        

That’s where you will make the modifications I mention.

Yeah, I kinda figured that part out, however the v10 installations do not have the series of “add_header” lines. Those only seem to appear in the erpnext v12 installs.

I am not sure how to get this to work with v10. The first part of creating the Diffie Hellman file and then altering the ssl protocols, adding the .pem file reference to the nginx.conf file causes nginx to fail to restart. I had to clear the edits to get it to work again.

So there must be some configuration difference between the v10 nginx configs and the v12 version.

BTW… I just setup a v12 site then ran the bench lets encrypt script and it passes the test site with a score of A+ without any edits. This tells me the developers were impressed enough with your details that they probably fixed nginx configs to support your findings. :wink:

Has anyone else had success getting an “A” rating with a v10 site?


The sites_available and sites_enabled are actually Apache standards. A clean installation of Nginx doesn’t use them.

However. When Nginx was brand-new, 99% of the web community was accustomed to the Apache directory structure. And so many of the major Linux distributions (Ubuntu), decided to be compatible. So when you install Nginx using Ubuntu (apt install nginx), the Ubuntu Package automatically creates these 2 directories, and configures them as the default.

On other distributions (Alpine, Arch),when you install Nginx you won’t get that structure. So it’s not really an ERPNext/Frappe convention here, so much as an Nginx one.

I actually don’t use either ‘sites enabled’ or ‘conf.d’. I run my Nginx inside a Docker container, and store the configuration files in a custom ‘/erpnext_support’ directory.

But as you noted, it’s what’s inside that counts! :slight_smile: You have to get those .conf files written correctly.

1 Like

Yeah, the problem is that the “correct” lines in the files seems to be different between v10 installs and v12.


@bkm, is your Nginx version the same in both scenarios?

nginx -v

The add_headersections are important, and can absolutely impact security ratings. They do things like preventing Cross Domain Origin violations, etc.

Yeah, they both come up as:

nginx version: nginx/1.15.5 (Ubuntu)


The add_header lines do not exist in the nginx.conf files on any of my v10 installs. They all have lets encrypt certs and they al get “B” scores due mostly to the older TLS protocols.


This is a complex topic for our forums. And I’d only rate myself “intermediate” when speaking about this.

To achieve that A+ rating, you’ll need to make many changes. Last year, I read a nice blog about this. I’m unable to find it right now.

In the meantime, these may help:


Yup, I figured that would be true. The problem is the complex redirects that are included in the erpnext implementation of nginx. There are multiple config files and they do not all agree. I don’t even pretend to understand how this is even possible.

I can understand the edits and what should be added based on the reference article you posted.

What I cannot understand is how many different config files have to be changed in a standard erpnext configuration in order to make such edits/additions workable.

At this point I will have to be stuck with a “B” score until I can figure out the inter-connectivity of all of these stupid config files.



Thanks for that.

I knew of the Apache directories and thinking from within my own happy little Ubuntu mental box, just assumed Nginx had adopted it too.

I have development, staging and production copies of a server that already publishes several Nginx based virtual hosts.

When I installed ErpNext on the development copy it stomped all over my existing Nginx config.

I have scripts that completely rebuild that server as needed, so my new scripts just let ErpNext wreak havoc and then patch its files to include mine.

This is all for v12. Being knew to ErpNext I have never looked at v10.

Well, it appears that ERPNext “stomps” all over the production versions as well. On a v12 production server, if you make the required changes to the nginx.conf file and restart the nginx service it does just fine. However, if you do anything that requires erpnext to want to add anything else to the config file, it completely rebuilds the file to the old default and essentially “stomps” out all of the custom changes you may have made. In some cases it even breaks the nginx service.

I have been playing with this now for about 2 full days of making edits and restarting services or even rebooting servers. I can recover if I replace the the broken config files with the originals and start the process again. Ultimately there are very few scenarios that will stay working (even in v12) for very long. Even simple changes to the website part of the application then force the nginx configs to be smashed again.

It appears from my testing that sometime after v12.1.0 ( I am not sure when exactly) the configuration of nginx was changed on the ERPNext / bench handling of the service so that Lets Encrypt certs would produce a grade of A+ and I would bet this was due to the devs noticing the efforts of @MartinHBramwell and making those changes.

My early v12 sites (12.0.8) all work as @MartinHBramwell described in the original post. All of my later v12 sites (v12.2.2 and later) all work without any additional edits and maintain A+ scores.

My v10 and v11 sites cannot handle the editing of the nginx.conf file without crashing the service.

My Observations:

  • All nginx services across all sites from ERPNext v10 to v12 are all using the exact same version of the nginx service as discovered by using the command: nginx -v

  • How “bench” interacts with the nginx config file appears to be different in each version of ERPNext.

  • Since the way ERPNext/Frappe have implemented nginx differs from the the standard and is not very clearly documented, it is nearly impossible to figure out how to get a consistent high score when using Lets Encrypt.

  • There also appears to be several differences in how Lets Encrypt is deployed between the v10 and v12 servers. This only adds to the complexity of getting better scores consistently.


Fresh v12 installs appear to have no problems and will likely always enjoy great scoring for their certs (provided the devs don’t break it with some other update). All prior versions will have a great deal of work to do in order to achieve the same high scores. I do not yet know how to achieve the better scoring in the older systems.


I’m guessing this is not new to you, but just in case it is new to you or someone else…

Have you ever used diff and patch? HowTo: Create Patch Using Diff Command – Linux

The procedure would be:

  1. backup each conf file
  2. edit all conf files as needed
  3. generate patches and backup copies and store them in ./sites/${site}/private/files/NginxConfBK
  4. run an ErpNext update
  5. backup the new conf files
  6. run all the patches against the new conf files.

It doesn’t help figure out what works and what doesn’t, but ought to help, (even if only as a kind of documentation) with future issues.

1 Like

Yup, I used that very method to handle the v12.0.8 server so that I could get an A+ score on it. I have both the original files and my edited files setup as .orig and .BKM with a shell script to automatically move them into place as needed.

While that fixes my two older v12 sites, it is not yet useful for my v10 and v11 sites as I am as of yet unable to get them to a running state with anything better than a default B score. So far all of my tweaks and edits crash the nginx service every time. Need more research time to try to get to the bottom of it.


1 Like