i have two domains
i have setup ssl on domain.com
i have created an alias for domain.com.au
when i browse urls...
domain.com works perfectly with http redirecting to https (so typing http://domain.com redirects to https://domain.com)
however, for domain.com.au,
if user enters http://domain.com.au in browser, they are redirected to https://domain.com as expected.
However, if user enters https://domain.com.au in browser, it returns a "Forbidden you dont have permission to access this resource"
I am not sure if this is a permissions error, because the parent domain is working fine...i am missing something obvious.
So are the specs for redirects and co with ssl done good way
First a redir none ssl have to go to exact the same domain.tld with ssl. ( so you need then a cert for that domain to ofcourse)
Then after that you do the redirect to the other domain also with ssl/https.
So the only right way is:
if user enters http://domain.com.au redirect 1 and first to https://domain.com.au and then after that redirected to https://domain.com
With certs ok for both then also ofcourse this works then also https://domain.com.au redirect to https://domain.com
The same with http://www.domain.com.au 1 first to https://www.domain.com.au then to the https you want example https://(nonwww)domain.com
Domain.com.au is an alias
I have 2 clients who need this because they stupidly went and setup incorrect domain extensions (ie one set .au and the other a .org) and put websites on them and now want to redirect to the correct extension which has an SSL cert.
Is there a dns change I need to consider? (Dns is not hosted in virtualmin btw)
Yea so it works , not so good.
I know this from directadmin where it was also ( then ofcourse stuff on same box) not 100% , they did make some modifications though that it works now , and it is possible to have / put all what needed in "custom" host parts. ( is updated there a while ago as kind of bug fix there you could edit custom virtual host parts for aliases sofar i know)
Here some about that there https://forum.directadmin.com/threads/https-and-hsts-for-redirect-pointe... BUT DA you have to pay more ofcourse , also more developers.
So i am not saying virtualmin is not ok , only the way you do it with virtualmin is not the way to go , how easy it is with alias maybe in forum here i have seen some more discussions about alias and redirect with GUI virtualmin , not sure where and yes or no about this and all solved....
That is why i don't use aliases , then you can handle all important stuff and SSL certs and redirects as they should be , then i can all handle in htaccess or better in the virtual host parts without some control panel or whatever ..........
Don't be sure here but some parts of specs are maybe https://tools.ietf.org/html/rfc6797 and here https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
With testing on compliancy with HSTS specs i and others found out lot of redirecting is done wrong, if from url/domain without certs / ssl directly to other (url/domain) with https /ssl cert , that is not according as the specs say.
Also lot of SEO hihi socalled cracks advise redirect only one direct redirect wich is so wrong. (http://www.domain.tld to https://nonwww.domain.tld)
I do always ( now hihi ;) ) for redirecting domains to other first set everything for that domain that has to be redirect so also a letsencrypt cert , only after that i do in htaccess (public and private directory path) or when having only one path for both (http and https) in virtualhost 80 and 443 the redirects as they should.
Not only for hsts but you can test with these links some: Example is a virtualmin testbox gpl on centos 7.x with codeguruit apache and remi php fpm on a openstack instance, empty site testing...
and this one could be helpful to
You see on (shared host ) ip adres the hsts non https doesn't work
301 Warning: HSTS header sent via http has no effectbut could not hurt also
What is not solved and not good is the virtualmin port 1000 wich i can't solve while then not working.
error checking OCSP stapling
weak Sha1 and RsaKeyX
no http/2 via ALPN
Good: Tls.1.2 and no Tls.1.1 and nono Tls.1.0
CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US
Is maybe oftopic but i think you all get the point that some work must be done with most control panels yourself to have it done the right way , therefore yup serveradmins. ;)