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?
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?? )
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.
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! You have to get those .conf files written correctly.
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.
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.
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.
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.