0

On a shared server, we have some sites that only run on port 80. However, there are other sites that run on both port 80 and 443.

For example:

<VirtualHost *:80>
  ServerName unsecure.com
</VirtualHost>

<VirtualHost *:80>
  ServerName secure.com
  RedirectPermanent / https://secure.com
</VirtualHost>

<VirtualHost *:443>
  ServerName secure.com
</VirtualHost>

Requests to https://unsecure.com will be presented the certificate for secure.com. Is there any way to avoid this other than separating out the interfaces (i.e. foo:80 and bar:443 which isn't possible in this situation). Many of these sites on port 80 are legacy sites, and setting them up to use SSL isn't as straightforward as we had hoped.

Nick
  • 103
  • 3
  • Sending an `ERR_SSL_UNRECOGNIZED_NAME_ALERT` error code will avoid the user seeing a warning about an invalid certificate. In Chromium the [error page](https://static.213.1.202.116.clients.your-server.de/) produced by `ERR_SSL_UNRECOGNIZED_NAME_ALERT` looks similar to the one produced in case of a RST packet which is what they'd see if you simply weren't listening on port 443. I don't know if this is something Apache can do, which is why I am posting this as a comment rather than an answer. – kasperd Feb 06 '19 at 17:00

1 Answers1

1

You don't need separate network interfaces, just separate IP addresses. Sites which are deployed with https get one IP address, while sites with http only get the other IP address. When a site is migrated to https, its DNS address records also get chnaged to the other IP address.

In Apache, you will change the Listen directives to correspond to those IP addresses. For example:

Listen 198.51.100.37 80
Listen 203.0.113.252 80
Listen 203.0.113.252 443

This is the only way to do it reliably.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • I'm curious why you are not mentioning `unrecognized_name` which you did [mention](https://serverfault.com/a/894439/214507) when I asked a similar question in the past. – kasperd Feb 06 '19 at 17:04
  • Because it's not relevant? – Michael Hampton Feb 06 '19 at 17:24
  • As far as I can tell `unrecognized_name` would both be an answer to what seems to be the problem to be solved as well as to what the question is literally asking for. The question asks how to avoid clients being presented with a wrong certificate. If the server sends `unrecognized_name` the client is not presented with any certificate at all as asked for. I believe the desired result is to provide a response which the client will treat the same as it would have treated a RST. As far as I can tell at least Chromium does treat `unrecognized_name` the same way as it would treat RST. – kasperd Feb 10 '19 at 13:34
  • @kasperd That also depends on the server actually terminating the handshake with `unrecognized_name`, which is not something it's required to do. And I don't even know if Apache does. – Michael Hampton Feb 10 '19 at 15:49
  • I don't know if Apache can even be configured to sent `unrecognized_name` when it doesn't have a certificate for the name. That's why I haven't posted an answer myself. What I do know is that sending that message in case of an unrecognized name and then closing the connection has worked excellent for me when implemented in my own software. The exact message I have been using looks like this: `const char reply[7] = {0x15, 0x03, 0x03, 0x00, 0x02, 0x02, 0x70};` – kasperd Feb 10 '19 at 22:50