3

We have a web server with a couple of internet IPs.

I have successfully set up SNI name based virtualhosts, it's working great. What I'd like to do though is have our main site NOT use SNI and use one of the unique IP addresses alone so that our browser support for that site is improved (XP/IE combinations..)

We run a very popular site which has a significant amount of users running badly outdated browsers so it's quite important to us.

Running Apache 2.2 (2.2.15-47.el6_7) on CentOS 6.

  • 2
    You shouldn't think of it in terms of disabling. Either the client sends SNI data or it does not, and the server has no control over that. All you can really do on the server side is decide which certificate to send to the client. If the client has no SNI support the default (frist) vhost for that IP is supposed to be the one being used. – kasperd Sep 8 '15 at 15:21
  • 1
    I think I understand. By just having one vhost on the non-SNI IP address it'll solve the problem. – John Hunt Sep 8 '15 at 15:25
  • 1
    I think it will. You can use s_client to verify it, if you invoke it with the proper arguments. In principle on each IP there should always be one vhost, which works for clients without SNI support. And if properly configured, all vhosts will work for clients with IPv6 even if they don't support SNI. – kasperd Sep 8 '15 at 15:32
5

As others have stated just put the first site as the first virtual host and it will work whether SNI is enabled or not:

<VirtualHost *:443>

   ServerName www.site1.com

   DocumentRoot /site1/

   SSLCertificateKeyFile /ssl/server1.key
   SSLCertificateFile /ssl/server1.crt

</VirtualHost>

<VirtualHost *:443>

   ServerName www.site2.com

   DocumentRoot /site2/

   SSLCertificateKeyFile /ssl/server2.key
   SSLCertificateFile /ssl/server2.crt

</VirtualHost>

However non-SNI browsers to site 2 will be served the certificate for site1 and so will error (and the users might wonder why they've got a certificate for a different site, though if still on non-SNI browsers they are probably not that tech savvy).

However, it is possible to provide access to all users for all your sites, despite the apparent SNI issue, if you have a single certificate that covers all the sites subject alternative name field.

You can then have two virtual hosts using the same key and cert:

<VirtualHost *:443>

   ServerName www.site1.com

   DocumentRoot /site1/

   SSLCertificateKeyFile /ssl/server.key
   SSLCertificateFile /ssl/server.crt

</VirtualHost>

<VirtualHost *:443>

   ServerName www.site2.com

   DocumentRoot /site2/

   SSLCertificateKeyFile /ssl/server.key
   SSLCertificateFile /ssl/server.crt

</VirtualHost>

So you have the same key and certificate for two sites (or three, or more if you want).

So www.site1.com always works as, even without SNI support it's the default host.

For www.site2.com it gets more interesting:

  • For browsers that support SNI, they provide the server name and go straight to the site2 virtual host config and that works.
  • For browsers which do not support SNI, they default to the site1 config, which returns it's certificate, but as the certificate works for both sites, that's actually OK. After SSL negotiation is complete the first web request comes in, but as this time the server is given the server name, it can correctly serve the document from /site2/ directory.

So this works because a https connection involves two distinct and unrelated steps: 1) do SSL negotiation and 2) request document using that SSL connection, and these two steps do not have to be from the same virtual host (though most people assume it does).

The main downside with this option is that, depending how closely related the websites are, it may look unprofessional to have two different URLs on the same certificate. However, presumably if they are sharing a host, they are somewhat related businesses (unless the server is owned by a hosting company) so this may not be an issue.

I find this a handy little workaround, especially for dev servers where I might want to host several sites on one IP address, where I use self-signed cents with multiple URL in the subject alternative name field.

2

You don't "disable" SNI on the server-side -- you can't even control whether or not the client sends the extension. All you can do is define how your server responds to the presence (or absence) of SNI information.

Typically, when a server receives a request which lacks SNI information, it will select one of the certificates that are available to present to the client. For Apache, it will be the first vhost for the address/port pair that is being listened on.

As to whether or not to have a separate "non-SNI" address for the site you wish to make securely accessable without SNI, I don't think it's important. You may as well save a valuable IPv4 address and just put them all on the same IP. Anyone accessing an SNI-only site from a non-SNI browser is going to get the same certificate warnings anyway, whether or not its the same address as the non-SNI site or not. The only consideration is whether or not you want the certificate for the site which supports non-SNI clients being presented to non-SNI clients when they access an SNI-only site.

I've now typed "SNI" so many times, it's starting to lose all meaning...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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