This question already has an answer here:

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

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: SRVROOT=c:/Apache24

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

marked as duplicate by Jenny D, Community Jul 23 at 14:32

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 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 at 20:19
  • @doneal24 no, because then it wouldn't redirect to the fully qualified domain name – zero01alpha Jul 24 at 17:47

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.

  • 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. – zero01alpha Jul 12 at 13:05
  • 3
    Adding myserver as an alternate name in the certificate resolved the issue – zero01alpha Jul 12 at 13:42

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.

  • 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? – zero01alpha Jul 12 at 13:10
  • Yes, that should work in that case. – Sven Jul 12 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 <VirtualHost> is on *.443, and this happens before the redirect. – Oliver Williams Jul 12 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 at 13:14
  • 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 at 14:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.