Why does apache httpd tell me that my name-based virtualhosts only works with SNI enabled browers (RFC 4366)

Question

Why does apache give me this error message in my logs? Is it a false positive?

[warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)

I have recently upgraded from Centos 5.7 to 6.3, and by that to a newer httpd version. I have always made my ssl virtualhost configurations like below. Where all domains that share the same certificate (mostly/always wildcard certs) share the same ip. But never got this error message before (or have I, maybe I haven't looked to enough in my logs?) From what I have learned this should work without SNI (Server Name Indication)

Here is relevant parts of my httpd.conf file. Without this VirtualHost I don't get the error message.

NameVirtualHost 10.101.0.135:443

<VirtualHost 10.101.0.135:443>
  ServerName sub1.domain.com

  SSLEngine on
  SSLProtocol -all +SSLv3 +TLSv1
  SSLCipherSuite ALL:!aNull:!EDH:!DH:!ADH:!eNull:!LOW:!EXP:RC4+RSA+SHA1:+HIGH:+MEDIUM
  SSLCertificateFile /opt/RootLive/etc/ssl/ssl.crt/wild.fareoffice.com.crt
  SSLCertificateKeyFile /opt/RootLive/etc/ssl/ssl.key/wild.fareoffice.com.key
  SSLCertificateChainFile /opt/RootLive/etc/ssl/ca/geotrust-ca.pem
</VirtualHost>

<VirtualHost 10.101.0.135:443>
  ServerName sub2.domain.com

  SSLEngine on
  SSLProtocol -all +SSLv3 +TLSv1
  SSLCipherSuite ALL:!aNull:!EDH:!DH:!ADH:!eNull:!LOW:!EXP:RC4+RSA+SHA1:+HIGH:+MEDIUM
  SSLCertificateFile /opt/RootLive/etc/ssl/ssl.crt/wild.fareoffice.com.crt
  SSLCertificateKeyFile /opt/RootLive/etc/ssl/ssl.key/wild.fareoffice.com.key
  SSLCertificateChainFile /opt/RootLive/etc/ssl/ca/geotrust-ca.pem
</VirtualHost>

Solution 1

It's because your VirtualHost directive doesn't match your ServerName directive and/or the CN of the certificate. All three need to be identical, unless you have a wildcard certificate where the non-wild portions must be identical.

Solution 2

It's not an error, it's a warning message.

And you're getting it because 1) you've updated your Apache version and 2) you have 2 SSL VirtualHosts using the same exact IP address (as opposed to using 2 IPs).

Since you're sharing the IP, browsers without SNI support will just get the first website and never the second.

Comments

[ravi yarlagadda]

Browsers without SNI will get the certificate configured for the first website - but to actually map them to a vhost for serving the request, the Host header is checked normally.

[rightstuff]

@ShaneMadden, I don't belive that's correct as the Host: header is NOT checked BEFORE the SSL connection is established. And that's the entire point of having SNI support. Or needing 1 IP per SSL VH otherwise. So without SNI, Apache will default to the first VH found with that IP address, the Host: header is practically ignored.

[rightstuff]

...Otherwise you could do 100s of SSL NameBasedVirtualHosts on 1 single IP address, and we know that's not true (without SNI support by server and client).

[ravi yarlagadda]

mod_ssl's selection of a cert to use for the connection (which depends on what order the vhosts are defined in, and whether the client sends SNI) is not involved in Apache's core selecting which vhost to serve content from based on the Host header that's sent in the HTTP request.

[ravi yarlagadda]

Otherwise you could do 100s of SSL NameBasedVirtualHosts on 1 single IP address, and we know that's not true (without SNI support by server and client) You can. The normal use of this is when all have the same cert, a wildcard or an alternate name certificate usually. But say you have two vhosts with their own SSL certs - domain1.com and domain2.com, with domain1.com configured first. A non-SNI capable browser requests domain2.com - they get a certificate domain mismatch error, because they got sent the domain1 cert - but if they click through it, they do get the domain2 content.

[rightstuff]

@ShaneMadden, read it for yourself: "Historically, if you wanted to host multiple SSL enabled Web sites, you had to have a globally unique IP address for each site. With the advent of SNI, however, this is no longer necessary." en.gentoo-wiki.com/wiki/Apache2/… Again, the SSL connection is established to a VH 1st, not AFTER the reading of a Host: header. The Host header is ignored... Without SNI.

[ravi yarlagadda]

If the host header were ignored, even the simple and widely deployed case of "a wildcard cert with multiple name-based vhosts" would break. Anyway, here's a couple examples of questions that I've answered here where that behavior has been displayed; serverfault.com/q/292637 serverfault.com/q/330212

[rightstuff]

You're using an edge case of sub-domains and wild-card certs. I'm talking about the general case. wiki.apache.org/httpd/NameBasedSSLVHosts Before SNI it was required to have a unique IP address per SSL VH. You keep ignoring this fact. You also keep ignoring that the Host: header is encrypted and not sent in plain-text in an HTTPS request. And that Apache must match that request to a VirtualHost BEFORE it begings to de-crypt it. That's where SNI comes it.

[ravi yarlagadda]

I'm not sure how the case of wildcard or SAN certs is different from the general case? What I'm saying is that being served the default SSL cert because you sent no SNI doesn't tie you to a vhost, it waits until it gets that Host header through the SSL connection. It does seem to restrict you from sending SNI for one domain then sending a host header for a different domain, which is interesting but not relevant to this discussion. I much prefer testing to outdated wiki articles; follow along on anything debian-shaped: pastebin.com/cE5g3eP2

[MichaelJones]

So the answer here is to change the <VirtualHost 10.101.0.135:443> line to be <VirtualHost sub2.domain.com:443>? Potentially?

[Fernando Santiago]

@MichaelJones does this solved the problem?

[MichaelJones]

@FernandoSantiago I now pay for different IP addresses for my virtual hosts now as I found SNI to be insufficiently reliable. And I have those ip address in my VirtualHost declarations.

[3bdalla]

This perfectly solved my problem. I was using a VirtualHost wild card but the ServerName directive match the certificate CN. All 3 matched and viola! P.S.: This answer serverfault.com/questions/578061/… tells you how to get the CN you put in your RSA certificate