redirecting traffic via .htaccess or VirtualHost .conf fails with https on centos 7 multisite server

Question

I have a Centos 7 server configured for multisite web hosting. One of the things I'm trying to do with this server is redirect traffic to old subdomains to subdirectories on our primary website. The primary site is NOT on this same server.

I have tried a ton of configurations using pure VirtualHost config as well as .htaccess. I can always get it working with HTTP but never with HTTPS as this VirtualHost has no SSL cert and I can't buy one for it only to redirect traffic.

So, http://bort.example.com redirects to https://www.example.com/bort just fine, but https://bort.example.com gives a security error about an invalid cert always.

My current theory is that without a cert on the redirect server, apache is refusing to even process the .htaccess file, so I've gotten rid of it completely and tried to distill the VirtualHost configuration down to the simplest possible method. This is what I have right now.

<VirtualHost *:80>
    ServerName bort.example.com
    Redirect / https://www.example.com/bort
</VirtualHost>

<VirtualHost *:443>
    ServerName bort.example.com
    Redirect / https://www.example.com/bort
</VirtualHost>

This still works fine with HTTP traffic. What am I missing to get this working with https://bort.example.com?

Edit: It looks like another site on this server, lisa.example.com, that does have an SSL cert may be a contributing factor. The actual error received when trying to reach https://bort.example.com is this:

bort.example.com uses an invalid security certificate.

The certificate is only valid for the following names:
lisa.example.com
Error code: SSL_ERROR_BAD_CERT_DOMAIN

Answer 1

In HTTPS, the order of operations at the beginning of a connection is... less than ideal. This is because HTTP was initially designed separate from SSL/TLS, and the two technologies did not fit perfectly together.

When the server accepts any incoming HTTPS connection, the first step is the SSL/TLS negotiation. This happens before any other data is passed over the connection - in particular, before the client has a chance to send the HTTP(s) header specifying the name of the server the client is asking for.

As a result, if the server has multiple certificates for different sites, it may need to blindly choose one and hope it's the certificate for the site the client is asking for. If the wrong certificate was presented, the client will refuse to believe anything the server sends on that connection, and so redirecting the client will be impossible. "Wait, I wanted bort and now your certificate proves your name is lisa instead? This is a mistake or something worse, I don't want to talk to you." The client won't even give the server the chance to offer the redirect information.

As name-based virtual hosting became common, two technologies were developed to fix this issue: Server Name Indication (SNI) and Server Alternative Names (SAN).

Server Name Indication is a SSL/TLS extension that allows the client to tell the name of the server in the early phase of SSL/TLS negotiation, instead of only in the HTTP(s) request headers. If the server supports SNI, it can then choose the correct certificate to present to the client. Of course, each VirtualHost must then have its own certificate: with Apache it means SSLCertificateFile and SSLCertificateKeyFile parameters for each virtual host, pointing to a certificate that matches the ServerName of that virtual host. And if you don't already have a certificate for bort, you'll need to get one.

The other alternative would be to have a certificate that is good for more than one virtual host. That's where the Server Alternate Names technology comes in. It is a certificate extension that allows the certificate to list multiple host names it's good for. You could get a new certificate for your server that uses SAN to list both lisa.example.com and bort.example.com as valid DNS names for the certificate. Of course, getting a new certificate can be a hassle.

Unfortunately, since both SNI and SAN are later additions to the SSL/TLS standards, the oldest browsers won't necessarily support them. But basically any browser that was released on this decade should support them just fine.