Let's Encrypt - Redirect/Rewrite Rules with Apache

Using Apache2 on Ubuntu 16.04 LTS, I only have one site available and enabled. For testing purposes, my virtualhost file is very basic:

<IfModule mod_ssl.c>
  <VirtualHost *:443>
    ServerName www.example.com
    ServerAlias example.com
    SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf
  </VirtualHost>
</IfModule>

Even when I clear my browser cache (and even using Chrome’s incognito), it seems that https://www.example.com gets re-directed to https://example.com

Does anyone know why this is? Is there a place to edit/change this? Thanks in advance! :slight_smile:

Hi @iversun,

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.

Cheers,
sahsanu

1 Like

Also, Chrome may automagically synthesize a redirect if the site has certain configuration issues.

If https://www.example.com/ has a certificate that covers the name “example.com” but not “www.example.com”, i believe it will send you to https://example.com/ automatically. (Instead of just displaying an error page, as most clients will.)

This will be logged in the console.

(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.)

2 Likes

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.

In advance, thank you!

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!!

Sit tight!

Hi @iversun,

@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

Cheers,
sahsanu

Well, now I feel like an idiot. Haha, awesome!! Let me fix it and I’ll report back. Thanks!!

Alright @sahsanu and @mnordhoff – I think I got it!




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.

@iversun, I'm glad seeing you've done it :clap:

I see all ok, all domains work fine.

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.

SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain/privkey.pem

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.

Cheers,
sahsanu

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 :slight_smile:

It is normal, I see no problem, all is working as expected :+1:.

Thank you so much for the kind words :wink:

Have a great day.
sahsanu

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.