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.

1
  • 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 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 6, 2019 at 17:00

1 Answer 1

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.

5
  • I'm curious why you are not mentioning unrecognized_name which you did mention when I asked a similar question in the past.
    – kasperd
    Feb 6, 2019 at 17:04
  • Because it's not relevant? Feb 6, 2019 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, 2019 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. Feb 10, 2019 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, 2019 at 22:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .