To answer your question, the central port 80 listener I have described throughout this thread is the equivalent of a secure SSL policy; any request that comes in on port 80 is automatically redirected, via an HTTP 301 Moved Permanently response, to the equivalent HTTPS version of the requested URI. My solution also does not create any sort of duplicated configuration, and leaves the system administrator with a more performant Nginx installation where one virtual host handles all incoming HTTP requests regardless of destination, thus ensuring SSL is enforced across the board with an HTTP 301 redirect to the HTTPS-equivalent request URI.
To further answer your question, I am not reinventing the wheel; rather, Iāam proposing a superior Nginx configuration that any competent system administrator worth their weight in gold would be happy to implement. There is no need for Virtualmin, the way it is currently configured, to set up a listener on port 80 for each virtual host it creates as the aim of the modern Internet is to ensure all Web traffic is secure. Thus, having one central listener on port 80 that accepts any insecure request and redirects it to a secure request fulfills this goal without exception, and would also streamline configuration requirements for system administrators by ensuring all virtual servers are secure. This is in stark contrast to how things are currently done, wherein you have to manually specify that you want Virtualmin to redirect insecure requests on port 80 to secure requests on port 443 for an individual virtual server; this ability is not enabled by default. If Virtualmin were to give administrators the option to configure things such that a virtual host is not required to listen on port 80, then a system administrator could then implement a central listener just as I have. Ideally, however, Virtualmin would take this course of action, setting up the central listener on its own, but at least giving administrators the option of disabling its requirement of a per-virtual-host port 80 listener would be a good first step, and is what I have proposed throughout this thread.
You are right, however this can be set to be enabled by default for all newly created virtual servers using System Settings ā¾ Virtualmin Virtual Servers ā¾ Configuration: SSL settings page and Redirect HTTP to HTTPS by default option.
@Jamie, (by the way, you just need the previous comment 21 to grasp the whole idea of this thread), perhaps, we could really allow to disable optionally the check for SSL website to require non-SSL to be enabled?
@JEMEDIACORP What I am expect to happen, is that normal users will have problems with such configuration. Therefore, this would not become a default, nor could be made easy to enable.
@JEMEDIACORP Also, will Letās Encrypt validation work with redirects that you have setup?
Although, if we had an option in Virtualmin Configuration (put deep down somewhere), which would allow to disable such check, for more advanced users to provide support for more peculiar and fancy configurations, I wouldnāt mind.
We need to see what Jamie thinks about it and if that is easily doable.
But I donāt think such configs to be nor common nor conventionally correct.
Ah, yes, thank you for reminding me of that option in System Settings > Virtualmin Configuration. However, even when enabled, that still adds a port 80 listener to each created Virtualmin virtual host even though none is needed if a central port 80 listener is set up In other words, why add the same exact redirect line to every virtual host configuration, thus duplicating configuration, if only one is required centrally in a port 80 listener that accepts any inbound insecure request and redirects it to a secure request? I am sure you would agree that there is no need to copy the same line of configuration across multiple virtual servers when one is sufficient.
To answer your other question, Iāve actually had no problem with Letās Encrypt SSL certificates using my setup. I am able to request and renew certificates using Web-based validation without any issues, because I am essentially doing the same thing that Virtualmin already does - redirecting HTTP requests to HTTPS - with one line in my configuration file rather than the same line copied to multiple virtual host configuration files.
I believe problems with this configuration could be avoided by normal users if Virtualmin automatically added a server block to /etc/nginx/nginx.conf like the one I defined in a previous message (giving an example of our current port 80 listener configuration). Then, all Virtualmin virtual hosts could be configured to only listen on port 443 and the normal user would be none the wiser.
Ultimately, this new configuration is streamlined and, as already mentioned, does not duplicate any existing lines of configuration while still providing the same level of functionality as individual redirect lines in individual virtual servers that each listen on port 80.
I donāt think Virtualmin redirecting .well-known/acme-challenge requests is extremely relevant here since, as I stated, Iāve had no problems requesting and renewing Letās Encrypt certificates even with my centrally-located port 80 listener, ergo I am essentially centralizing the same functionality Virtualmin is duplicating, or at least enough of that functionality to allow Letās Encrypt to work the same on my system as it does with the standard Virtualmin situation.
As for the hypothetical scenario you posed, a good system administrator would not allow a user on their system to disable SSL support for any given Website (and only serve that site over port 80), and thus Virtualmin, as a product for system administrators to serve Websites on their systems, should not encourage, condone, or support this practice either. The reasons are simple: if you serve a Website over port 80 with no security whatsoever, any Web browser will flag the site with a warning to visitors about its insecurity and the siteās SEO will suffer, but even more importantly, the information of any visitor to that site could be compromised if sent unsecured over the Internet to the server hosting the site. This would open up a massive security hole, and I doubt the Virtualmin developers want their control panel to be known as one that condones or even supports insecure practices. Furthermore, the days of difficult-to-obtain or costly (in the case of non-Extended Validation) security certificates are over thanks to the introduction of Letās Encrypt, making it practically a walk in the park to obtain an SSL certificate if you can prove ownership of the requested hostname, thus reducing the argument for an unsecured Website even further. I am sure there are other reasons against this argument as well but these are the most important.
What if a system administrator himself/herself would want to disable SSL for testing/development purposes? I personally like flexibility, rather than enforcing anything.
This is why Virtualmin is great.
Can you reference any reliable sources that would state that this kind of configuration is becoming a streamline?
Iāve been a system administrator in a professional capacity for 6 years, and using Virtualmin in a personal capacity for over 10, and have also developed Web applications as simple as a WordPress Website and as complex as a custom CRM solution, but never have I had to purposefully disable SSL for ātesting/development purposes.ā Rather, I have a separate environment, usually on my local machine, where development work is completed, and a separate system accessible to the public for testing purposes that mirrors my production environment as closely as possible, and thus has SSL enabled. I canāt think of a scenario where anyone would need to purposefully disable SSL, but if necessary, a local development environment is almost always available to be set up on their local computer.
I like the flexibility of Virtualmin as well, thus why I am advocating for an option that allows an administrator to disable the hard requirement of creating a virtual server that needs to listen on port 80 if it is also to listen on port 443. This should be relatively easy for the Virtualmin developers to accomplish, perhaps with a warning to end users that this setup requires manual configuration of a standalone, central port 80 listener responsible for handling all insecure traffic. Alternatively, Virtualmin developers could implement the port 80 listener block I defined above so administrators wouldnāt have to do this themselves, and remove it when the option is turned off and Virtualmin defaults (or goes back) to requiring port 80 listeners for each created virtual server. In other words, if anything I am advocating for Virtualminās flexibility here. Iāve been hoping Jamie will respond to this thread so he can tell us how simple this would be to implement as an option for administrators.
As for seeking credible sources for the information Iāve suggested, all you need do is look no further than best practices for configuration files regardless of service. Almost any will tell you that duplicating configuration is not advantageous. Sure, it may not go so far as to cause performance depredations, but in some cases it might. A configuration that is not duplicated is also much cleaner and easier to read and understand. Having one port 80 listener for all insecure requests that then redirects those requests to any virtual host on the system only listening on port 443 is simple and easy to understand. It could be thought of as a gateway of sorts, where the insecure request on port 80 gets stopped by the single listener that is the gateway, only to be then allowed through after being converted to an HTTPS request. Itās a single point of entry for insecure HTTP requests, ensuring security is maintained by requiring all requests to eventually end up (and be processed) as secure requests, regardless of origin.
We have quite a few domains we manage in Virtualmin for which DNS is hosted elsewhere and thus for which Web-based validation is the only solution available when requesting or renewing Letās Encrypt certificates. Yet my configuration still works flawlessly.
We certainly could add an option so that all new domains redirect port 80 to port 443. This is possible to enable for existing domains on the Aliases and Redirects page, but thereās no option to set it up by default.
Unfortunately Virtualmin canāt easily be updated to support only creating sites on port 443, as all the exist code assumes that the port 80 site is the primary for each domain, and the SSL site on port 443 is just a copy of itās config. But if all requests are redirected, this shouldnāt matter much in practice.
I suppose we could also update the UI to only show a single āwebsite enabledā option, instead of having separate feature options for ports 80 and 443. I can agree that would be cleanerā¦
I personally like flexibility, rather than enforcing anything.