apachesslvirtualhosttls1.2mod-ssl

Disable Apache SSL engine for default 443 Virtual Host

I have two domains, example1.com and example2.com, running on the same IP, 12.345.678.90.

Now I want to completely dissable https access via 12.345.678.90.

I tried to do this (compact code without fancy stuff)

<VirtualHost *:443>
    SSLEngine off
</VirtualHost>

<VirtualHost *:443>
    SSLEngine on
    ServerName example1.com
    DocumentRoot /var/www/html/example1
    SSLCertificateFile /etc/.../fullchain.pem
    SSLCertificateKeyFile /etc/.../privkey.pem
</VirtualHost>

<VirtualHost *:443>
    SSLEngine on
    ServerName example2.com
    DocumentRoot /var/www/html/example2
    SSLCertificateFile /etc/.../fullchain.pem
    SSLCertificateKeyFile /etc/.../privkey.pem
</VirtualHost>

Now when I dissable the first block that catches all by default, the two example site work. However, if I enable it, nothing works anymore. Actually, this is just the port 80 solution copied for 443. It seems to be a SSL specific problem (encoded request data).

How can I block "IP access" over https? Or, what is the commonly used way to configure my setup?

Background is: It is not even standardized to create IP-based SSL-certificates, so it makes no sense to allow this kind of request.

Solution

  • It is not even standardized to create IP-based SSL-certificates,

    This is not really true. The standard explicitly defines that certificates for a specific IP address should use the iPAddress type in the subject alternative names section. But public CA will no longer issue certificates for an IP address but only for a hostname.

    Apart from that your server either accepts connections on the SSL port on a specific IP address or it does not. This is because at the TCP level only the IP address is seen and there is no knowledge about the hostname. The hostname gets only known inside the TLS handshake if the client uses the SNI TLS extension which all modern browsers do.

    Thus the most you can do is to make the TLS handshake fail if the client uses an unknown hostname in the SNI extension or does not use the SNI extension at all, i.e. uses https://ip-address/. This can be done by using the SSLStrictSNIVHostCheck directive as documented:

    If set to on in the default name-based virtual host, clients that are SNI unaware will not be allowed to access any virtual host, belonging to this particular IP / port combination.

    With this option set an access to http://ip-address/ will result in a TLS alert to the client and the TLS handshake will fail.