Redirect HTTP to HTTPS by default?

21 posts / 0 new

Topic locked

#1 Sun, 02/05/2017 - 16:19

samrich

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.

#2 Mon, 02/06/2017 - 04:07

unborn

hi, you can try to load that domain where you forced ssl via http://domain.com 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

#3 Wed, 02/08/2017 - 10:47

Masplus

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.

#4 Thu, 02/09/2017 - 20:06

ftbseobrad

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?

#5 Fri, 02/10/2017 - 05:16

Diabolico

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+: https://plus.google.com/+JohnMueller/posts/PY1xCWbeDVC.

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.

#6 Fri, 07/20/2018 - 10:46

dendy

how to change http://secondsfix.com to https://secondsfix.com

#7 Wed, 09/05/2018 - 10:05 (Reply to #6)

dendy

this same https://www.itstimeexout.com/

#8 Fri, 07/20/2018 - 10:59

Gaio2018

#9 Sun, 07/22/2018 - 06:41

Freddy63

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

server {
        server_name domain.com www.domain.com;
        listen ipaddress:80;
        rewrite ^/(.*) https://domain.com/$1 permanent;
}

Change the domain and ip address ofc

Source: Virtualmin 301 Redirects from http to https

I provide FREE Server Management Services in exchange of money

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

inman.turbo

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 {
 server_name VIRTUALSERVER_DOM www.VIRTUALSERVER_DOM;
        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;
        server_name VIRTUALSERVER_DOM www.VIRTUALSERVER_DOM;
        return 404;
}

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

if [ "$VIRTUALSERVER_ACTION" = "CREATE_DOMAIN" ]; then
 # rewrite VIRTUALSERVER_DOM.conf
fi

I'll post it soon.

#11 Tue, 10/02/2018 - 06:45

unborn

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

#12 Sat, 11/10/2018 - 13:40

axo

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 "example.com" with port 80. Go to "Edit Directives" and add at the end the following line:

RedirectMatch ^/(?!.well-known)(.*)$ https://example.com/$1

#13 Sun, 03/10/2019 - 04:48

adamjedgar

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

https://ajecreative.com.au

#14 Wed, 03/13/2019 - 10:52

AntonioD

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

#15 Sat, 08/24/2019 - 06:02

inman.turbo

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

/etc/nginx/conf.d/

Logged in as

root

Navigate to Webmin. Go to

Others>>File Manager>>/root/

then click

File>>Create new directory

Create two. One called

scripts

one called

sites-deleted

This can also be done in the shell with

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

I also have one called

sites-created

Create a file in

scripts

Call it whatever

myscrypt.sh

or you can

nano /root/scripts/myscript.sh

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

this

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.

This

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

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

/root/scripts/myscript.sh

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/myscript.sh

or in File Manager right click

myscript.sh>>properties>Change permissions

Check the Execute box under Owner and Group.

#16 Sat, 08/24/2019 - 17:57

inman.turbo

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

#!/bin/bash
if [ "$VIRTUALSERVER_ACTION" = "CREATE_DOMAIN" ]; then
    
    #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")
    #http://sed.sourceforge.net/sed1line.txt
    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
    #sites-available/$VIRTUALSERVER_DOM.conf
    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;
}
EOF
#ln -ns /path/to/sites-available/$VIRTUALSERVER_DOM.conf /etc/nginx/sites-enabled/$VIRTUALSERVER_DOM.conf
systemctl restart php-fpm php54-php-fpm nginx;
fi
if [ "$VIRTUALSERVER_ACTION" = "DELETE_DOMAIN" ]; then
   CONF_FILE_EXISTS="/etc/nginx/conf.d/${VIRTUALSERVER_DOM}.conf";
 if [ -f "$CONF_FILE_EXISTS" ]; then
      mv /etc/nginx/conf.d/${VIRTUALSERVER_DOM}.conf /root/sites-deleted/${VIRTUALSERVER_DOM}.conf.deleted;
    fi
fi

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/myscript.sh

Beginner options:

Use Apache

Reference: Pre-Post Domain modification: https://www.virtualmin.com/documentation/developer/prepost Template variables: https://www.virtualmin.com/documentation/system/template_variables Sed Oneliners: http://sed.sourceforge.net/sed1line.txt

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.

#17 Sat, 08/24/2019 - 16:34

noisemarine

@inman.turbo

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;
       }

#18 Sat, 08/24/2019 - 16:37 (Reply to #17)

inman.turbo

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.

#19 Sat, 08/24/2019 - 17:28

inman.turbo

@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.

#20 Mon, 09/02/2019 - 11:33

serverwithoutsoul

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