Redirect HTTP to HTTPS by default?

21 posts / 0 new
Last post
#1 Sun, 02/05/2017 - 16:19

Redirect HTTP to HTTPS by default?

Well, just getting into Virtualmin and realized that I did not set 'Redirect HTTP to HTTPS by default?' to 'Yes' so now I have a virtual server that allows for both HTTP and HTTPS connections. I setup Let's Encrypt and have valid SSL certs but would like to have all traffic for the existing virtual server go to HTTPS. Do I have to just create a bunch of redirects or am I missing a setting?

Also, now that I modified 'Redirect HTTP to HTTPS by default?' to 'Yes', is it safe to assume that any new virtual servers will be configured to only accept traffic from HTTPS?

Redirect HTTP to HTTPS by default? ---> was found under 'System Settings' --> 'Virtualmin Configuration' --> 'SSL Settings'

Thanks for any help.

Mon, 02/06/2017 - 04:07
unborn's picture

hi, you can try to load that domain where you forced ssl via to see if it will load as https automatically. Personally I use htaccess for that for each site/domain or folder where it needs to be forced.

Configuring/troubleshooting Debian servers is always great fun

Wed, 02/08/2017 - 10:47

Hello samrich,

It seems to be secure to enable 'System Settings' --> 'Virtualmin Configuration' --> 'SSL Settings' ---> Redirect HTTP to HTTPS by default?

This option will force all traffic of this website to go with HTTPS once you enable this option in VirtualHost. The website will show insecure until you install your SSL Certificate or load Let's Encrypt VirtualMin auto install option.

Thu, 02/09/2017 - 20:06
ftbseobrad's picture

samrich - Were you concerned about 301 redirects vs. the server automatically pointing everything through https vs. http from an SEO standpoint or just not having to go back and tweak virtualmin after the install?

Fri, 02/10/2017 - 05:16
Diabolico's picture

It should not affect redirects from http to https if done with 301 or 302 redirects. You can read more from John Mueller blog on G+:

For what i know if you have really big site the drop could happen but its limited to maybe 5-10%. Not perfect but you must somehow force people who visit over http to switch to https.

- I often come to the conclusion that my brain has too many tabs open. -
Failing at desktop publishing & graphic design since 1994.

Fri, 07/20/2018 - 10:46
Wed, 09/05/2018 - 10:05 (Reply to #6)
Fri, 07/20/2018 - 10:59


Sun, 07/22/2018 - 06:41
Freddy63's picture

If you're on nginx just add following code to virtual host file,

server {
        listen ipaddress:80;
        rewrite ^/(.*)$1 permanent;

Change the domain and ip address ofc

Source: Virtualmin 301 Redirects from http to https

Sat, 08/24/2019 - 01:38 (Reply to #9)

Don't put this above your server block! You will lose features as virtualmin will not be able to parse the Default HTML directory (you won't have your root in the first block --nginx will work it out, but not all of wbm/vm will). You need something like

server {
        listen VIRTUALSERVER_IP:80; # <--remove this line from default server block
        root VIRTUALSERVER_HOME; # etc
        #vm code
        location block  {
           # fcgi socket
        ssl path
        ssl key
}server {
    if ($host = VIRTUALSERVER_DOM) {
        return 301 https://$host$request_uri;
        listen VIRTUALSERVER_IP:80;
        return 404;

I'm working on a post-modification script i.e.

# rewrite VIRTUALSERVER_DOM.conf

I'll post it soon.

Tue, 10/02/2018 - 06:45
unborn's picture

if anyone use apache here you can do .htaccess with following rules

Edit: I was not able to put the code here as this forum seems to have break out markdown code - sorry

Configuring/troubleshooting Debian servers is always great fun

Sat, 11/10/2018 - 13:40

The setting "Redirect HTTP to HTTPS by default?" adds a redirection directive in the apache configuration of the virtual server :80 when it is created. If you created the virtual server before you select the option, you can add this line manually in the apache configuration

In "Webmin -> Servers -> Apache Webserver" select the virtual server "" with port 80. Go to "Edit Directives" and add at the end the following line:

RedirectMatch ^/(?!.well-known)(.*)$$1
Sun, 03/10/2019 - 04:48

just thought i would add an update to this...just wondering, does the following also work?

virtualmin>system settings>virtualmin configuration>SSL settings>redirect HTTP to HTTPS by default = "yes"

AJECreative is the home of $5 webhosting, $15/month VPS servers (1cpu,1gb RAM, 25GB storage)
Centos7, Debian9, or Ubuntu18LTS
Available Control Panels = Centos-Webpanel, Cyberpanel, or Virtualmin

Wed, 03/13/2019 - 10:52

What's the difference between those two lines in essence? Which one should we use?

Sat, 08/24/2019 - 06:02

Please refer to update in the next comment

Here is an automation solution for nginx that works with my configuration. This solution assumes you are using CentOs/Rhel 7, have root access, and have already gone into

Virtualmin>>System Settings>>Features and Plugins>>Nginx website>>configure (in the "actions" column)

and set the

File or directory for new virtual hosts



Logged in as


Navigate to Webmin. Go to

Others>>File Manager>>/root/

then click

File>>Create new directory

Create two. One called


one called


This can also be done in the shell with

mkdir /root/scripts && mkdir /root/sites-deleted

I also have one called


Create a file in


Call it whatever

or you can

nano /root/scripts/

Either way, paste the following code:

Please see update below

What this does:

sed -i -e 's/^/#/' /etc/nginx/conf.d/$VIRTUALSERVER_DOM.conf;

comments out the entire file, thus preserving the original


systemctl restart php-fpm php54-php-fpm nginx;

restarts nginx and php b/c our script is going to run after the post-create restart and our changes won't be realized otherwise pending a restart.


if [ -f "$CONF_FILE_EXISTS" ]; then
    mv /etc/nginx/conf.d/${VIRTUALSERVER_DOM}.conf /root/deleted_domains/${VIRTUALSERVER_DOM}.conf.deleted;

Checks if this is a delete operation and if it is moves the .conf file to our "sites-deleted" directory (Because VM will only delete the one server block, and ignores the code blocks containing our rewrite rules, thus we are left with half a file -- the original commented out code will still be in there as well, which is why I'm preserving it as a record of the state of the config at the time of deletion. It could potentially be used to rebuild the virtual host later).

Finally, navigate to

Virtualmin>>System Settings>>Actions upon server and user creation

Find the line

Command to run after making changes to a server

And input your path


And your done. After you've done some testing and made the necessary edits for your configuration. i.e. if you are running a Debian based system the paths and a few other things will be a little different, but nothing you won't be able to work out on our own. Apologies for any readability issues. First time with the editor. Leave this field blank

Oh, and don't forget to make the file executable

chmod +x /root/scripts/

or in File Manager right click>>properties>Change permissions

Check the Execute box under Owner and Group.

Sat, 08/24/2019 - 17:57

Update. A more elegant solution for /root/scripts/

    #back up original file
    cp -p /etc/nginx/conf.d/${VIRTUALSERVER_DOM}.conf /root/sites-created/${VIRTUALSERVER_DOM}.conf.original;
    #just comment out listen ip lines (And only the ones not containing "ssl")
    sed -i '/ssl/!s/listen/#listen/g' /etc/nginx/conf.d/${VIRTUALSERVER_DOM}.conf;

    #On Debian or similiar configuration replace /etc/nginx ...$VIRTUALSERVER_DOM.conf with path to
    cat >> /etc/nginx/conf.d/$VIRTUALSERVER_DOM.conf <<EOF

server {
    if (\$host = ${VIRTUALSERVER_DOM}) {
        return 301 https://\$host\$request_uri;
    if (\$host = www.${VIRTUALSERVER_DOM}) {
        return 301 https://\$host\$request_uri;

        listen ${VIRTUALSERVER_IP}:80;
        server_name ${VIRTUALSERVER_DOM} www.${VIRTUALSERVER_DOM};
        return 404;
#ln -ns /path/to/sites-available/$VIRTUALSERVER_DOM.conf /etc/nginx/sites-enabled/$VIRTUALSERVER_DOM.conf
systemctl restart php-fpm php54-php-fpm nginx;
if [ -f "$CONF_FILE_EXISTS" ]; then
    mv /etc/nginx/conf.d/${VIRTUALSERVER_DOM}.conf /root/sites-deleted/${VIRTUALSERVER_DOM}.conf.deleted;

Other options (Ubuntu et. al.) Command to run after making changes to a server:

cat /path/to/sudoer's/passwd/file |sudo -S /home/sudo-user/scripts/

Beginner options:

Use Apache

Reference: Pre-Post Domain modification: Template variables: Sed Oneliners:

Known Issues Some CDN's may cause a "Too many redirects" error if you are using them for a proxy and your VPS stack also includes a firewall or router (And you are using NAT). The only solution is to disable the proxy mode with your CDN provider (unless you can enable a transport level--Layer 4--TCP proxy) or not force 301's, and allow plain HTTP traffic. But the problem only typically occurs when you already have a large number of plain HTTP requests in your CDN cache.

Sat, 08/24/2019 - 16:34


If you have users that use LetsEncrypt, I'd suggest adding an additional line regarding the .well-known directory to your server stanza. That will prevent the redirect for that one directory and help prevent request failures. Here are a couple of lines I use (I don't use the if statements you have).

        location /.well-known/acme-challenge/ {
                # put your configuration here, if needed
        location / {
                return 301 https://$server_name$request_uri;
Sat, 08/24/2019 - 16:37 (Reply to #17)

The script above is tested and working as-is with LetsEncrypt (In fact borrows heavily on the typical certbot managed conf). The well-know acme line won't hurt though Acme scripts understand this config and typically place it there temporarily on their own.

Sat, 08/24/2019 - 17:28

@noisemarine It's best to have your [custom] redirect rules outside of the server stanza managed by vm. That way it they won't touched. And other things could start breaking once you start doing things like adding redirects or proxies or website options from within the ui.

Mon, 09/02/2019 - 11:33

Instead of worrying about putting another server block on top, you could easily solve it by putting this piece in the existing server block:

    if ($scheme = http) {
        return 301 https://$host$request_uri;


  • No, using "if" is not necessarily evil (and is not in this case).
  • Use return instead of rewrite, in line with nginx best practice.
  • Using $host instead of $server_name preserves the host, in case you have multiple ones linked to the configuration.

I had no problems with LetsEncrypt until now, so I cannot comment on the discussion by @inman.turbo and @noisemarine.

Topic locked