Do you have another <VirtualHost *:80> in your conf?, If you don’t have a separate file for your domain, I suppose the rules to redirect the site would be on your default conf file 000-default.conf in sites-enabled. or maybe you have a .htaccess file in your DocumentRoot that is performing the redirect.
Anyway, you need to search for Redirect or RewriteRule directives in your conf files.
If you paste the conf files we can take a look. Also, it is easier to debug if you provide the real domain name.
(I’m not certain Chrome redirects “www to not-www” and “not-www to www”. It definitely does one of the two, but i’m not sure which one.)
(I’m not certain which release Chrome started doing this in. It was definitely recent. It may not be in the current stable release, but i believe it is.)
Hey @sahsanu and @mnordhoff – thanks for your replies! Greatly appreciated <3
So, the conf is literally what’s posted above. I’ve both deleted (and prior to, disabled) 000-default.conf, and no .htaccess files are in any of my directories. The <VirtualHost *:80> was in a separate conf but I’ve even disabled that site to try and better understand why when I type https://www.hfm.to I’m getting redirected to https://hfm.to
I’ll enable that for your testing/help if you wish. Also, the link for the actual domain (hfm.to) is above, sorry for not including it sooner, some places cry if you link to your site so I try to be considerate.
And to speak more directly to @mnordhoff regarding Chrome automatically doing it: good call! This could very well be the problem. I popped open Edge (aka IE) and it seems to not be directing automatically. Before you (or @sahsanu) spend too much time looking at this problem, let me put back in the configuration files that I think works and report back!!
@mnordhoff is right, Chrome detects an issue with your certificate in https://www.hfm.to and it tries the non-www version.
The problem Chrome is detecting is that the certificate served for www.hfm.to is only valid for hfm.to If you want to serve both versions you should use the cert that you issued covering both domains.
CRT ID DOMAIN (CN) VALID FROM VALID TO EXPIRES IN SANs
144418893 hfm.to 2017-May-26 06:01 CEST 2017-Aug-24 06:01 CEST 89 days hfm.to
135682107 hfm.to 2017-May-10 17:50 CEST 2017-Aug-08 17:50 CEST 73 days hfm.to
www.hfm.to
Are all working! 3 of them don’t have DocumentRoot defined, so you’ll see the default red/white Ubuntu page, and on the final destination you’ll find the index.html file with the name displayed.
Assuming you guys don’t see any errors (if you’d be so kind as you check again) I’ll tell everyone else reading what’s up:
So, what was wrong? Long story short, with what I’m trying to accomplish, I didn’t register the certbot certs correctly. I only ended up doing it for one domain, but needed it for both. It worked best for me to start with two separate .conf files for www and non-www. Then run certbot on each one, which generated one certificate for each. I now have four .conf files HTTP www and non-www, HTTPS www and non-www. There’s probably a better, easier way, I could definitely merge some .conf files, but for my process/workflow I’m just gonna leave it.
If things look good to you guys, I’m gonna setup my Redirect rules within <VirtualHost> so they all point to the final destination: https://hfm.to – that way no matter how they get there (typing it with HTTP, HTTPS, www, or non) they end up right where I want 'em.
There is not only one way to do things, so if you trust your conf and it is easier to you, go ahead with that conf.
Go ahead, you only need to add a Redirect rule to the 3 conf files (htttp: wwww and non-www and https: www) pointing to https: non-www
Redirect permanent / https://hfm.to/
Just one more thing, just to be sure that you won't have issues when you try to renew your cert. Could you please show the content of /etc/letsencrypt/renewal/yourdomain.conf ?.
The yourdomain part should be the same as you put on Apache SSL directives pointing to your cert and privatekey.
I'm asking this because you have issued several cerst with the same common name but different subset of domains, so it is possible that your domain ends in something like yourdomain-0001.
Yeah, I noticed that. That was gonna be next on my list to dig into. Somehow, I screwed that up when I originally tried setting this up. Hopefully I'll get it figured out, and now that I think I know how to do it the "right" way, it won't get screwed up on my next domain I'll set up so fingers crossed.
Anyways, I'll check it out and let you know what I find/figure out. Once again, as always, seriously... thank you for the help/advice/support. People like you are the real MVP <3
Well alright @sahsanu - not quite what I was expecting to see. Everything looks okay, I guess? I was kind of expecting to see two setups, one for www.hfm.to and one for just hfm.to. There's only one file in the /etc/letsencrypt/renewal/ folder which is hfm.to.conf. Contents of the file are as follows:
# renew_before_expiry = 30 days
version = 0.14.1
archive_dir = /etc/letsencrypt/archive/hfm.to
cert = /etc/letsencrypt/live/hfm.to/cert.pem
privkey = /etc/letsencrypt/live/hfm.to/privkey.pem
chain = /etc/letsencrypt/live/hfm.to/chain.pem
fullchain = /etc/letsencrypt/live/hfm.to/fullchain.pem
# Options used in the renewal process
[renewalparams]
authenticator = apache
installer = apache
account = 8*************************6
Should I set this up differently? Advice/insight please
.