8

First off, I don't want to use rewrites.

I'm trying to redirect any call (HTTP or HTTPS) to myserver to the secured fully qualified domain using https at https://myserver.fullyqualified.com.

Here is my config

# Redirect all http traffic to https
<VirtualHost *:80> # line 545
  Redirect / https://myserver.fullyqualified.com/
</VirtualHost>

<VirtualHost *:443> # line 549
  ServerName myserver.fullyqualified.com
  SSLEngine on
  SSLCertificateFile "conf/mycert.crt"
  SSLCertificateKeyFile "conf/mykey.key"
</VirtualHost>
<VirtualHost *:443> # line 555
  ServerName myserver
  Redirect / https://myserver.fullyqualified.com/
</VirtualHost>

This works fine for HTTP, I can call http://myserver and it redirects to https://myserver.fullyqualified.com just fine.

However when I call https://myserver I get an error about the site not being secure, and it doesn't redirect to https://myserver.fullyqualified.com like I expect it to.

In Chrome, the error says

This server could not prove that it is myserver; its security certificate is from myserver.fullyqualified.com. This may be caused by a misconfiguration or an attacker intercepting your connection.

This is the output of httpd -S

*:80                   MYSERVER.fullyqualified.com (C:/Apache24/conf/httpd.conf:545)
*:443                  is a NameVirtualHost
         default server myserver.fullyqualified.com (C:/Apache24/conf/httpd.conf:549)
         port 443 namevhost myserver.fullyqualified.com (C:/Apache24/conf/httpd.conf:549)
         port 443 namevhost myserver (C:/Apache24/conf/httpd.conf:555)
ServerRoot: "C:/Apache24"
Main DocumentRoot: "C:/Apache24/htdocs"
Main ErrorLog: "C:/Apache24/logs/error.log"
Mutex default: dir="C:/Apache24/logs/" mechanism=default
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex ssl-cache: using_defaults
PidFile: "C:/Apache24/logs/httpd.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
Define: SRVROOT=c:/Apache24

How can I redirect HTTPS traffic to the full qualified domain name?

Giacomo1968
  • 3,542
  • 27
  • 38
secondbreakfast
  • 183
  • 1
  • 5
  • I know that you already have an answer, but could you have added the line `ServerAlias myserver` in the first `virtualhost *:443` block instead of setting up a separate block? – doneal24 Jul 13 '19 at 20:19
  • @doneal24 no, because then it wouldn't redirect to the fully qualified domain name – secondbreakfast Jul 24 '19 at 17:47

2 Answers2

10

Your SSL certificate for HTTPS should have myserver inside it as a alternative name, as it seem a simple ssl error that block the redirect.

If a homemade certificate please be sure to install it into the client store before testing. You can deploy the certificate by GPO if you are into a active directory domain.

yagmoth555
  • 16,758
  • 4
  • 29
  • 50
  • 1
    In this case yes, it is a homemade (self signed) certificate. Thanks for the idea about adding the alternate name though, didn't think of that! And yes, the certificate is installed on the client. – secondbreakfast Jul 12 '19 at 13:05
  • 3
    Adding `myserver` as an alternate name in the certificate resolved the issue – secondbreakfast Jul 12 '19 at 13:42
5

If your cert is for https://example.com, the browser will not accept it to access https://example because the names don't match.

Unless you have self-signed certificates accepted in your browser (and those of all your clients), this can't be prevented, and you won't get any public signed certs (e.g. with Let's encrypt or any regular CA) for a hostname without a TLD.

Sven
  • 98,649
  • 14
  • 180
  • 226
  • Thank you. In my case this is not a public facing web app. Would you agree with yagmoth55's idea to add `myserver` as an alternate name in the cert? – secondbreakfast Jul 12 '19 at 13:10
  • Yes, that should work in that case. – Sven Jul 12 '19 at 13:12
  • The OP is not trying to get the browser to "accept" the domain but simply redirect it. That said I think the problem is that since the original request is on https, the browser/Apache want to resolve the SSL FIRST before handling the redirect since the is on *.443, and this happens before the redirect. – Oliver Williams Jul 12 '19 at 13:12
  • 1
    @OliverWilliams: Redirect or rewrite happens after the connection. At this point, the names in the cert already need to match the hostname. Everything else would make TLS security worthless. – Sven Jul 12 '19 at 13:14
  • Yeah, I coincidentally posted the exact same issue just minutes ago, https://serverfault.com/questions/974994/ssl-and-www-handling-redirect-from-https-mysite-to-https-www-mysite - as long as I have http redirects working, it's highly unlikely a user will manually type in `https://nonqualified.com` in the browser. Preventing a bad/scary UX is my main goal. – Oliver Williams Jul 12 '19 at 13:18
  • fyi @OliverWilliams Adding `myserver` to the alternate names in the certificate resolved the issue, so maybe that will help you as well. – secondbreakfast Jul 12 '19 at 13:41
  • Thanks @zero01alpha, I'm not sure I can do that though with a 3rd-party signed certificate however, I'll look into it though – Oliver Williams Jul 12 '19 at 13:43
  • 1
    @OliverWilliams You can’t do my tip with a 3rd-party signed certificate, I wrote my answer assuming it’s a self signed certificate, as I often see that scenario for like Exchange server, where a public dns name is configured for external access and a private name for internal’s access. – yagmoth555 Jul 12 '19 at 14:04