9

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>
7

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.

  • So the answer here is to change the <VirtualHost 10.101.0.135:443> line to be <VirtualHost sub2.domain.com:443>? Potentially? – MichaelJones Nov 19 '14 at 12:21
  • @MichaelJones does this solved the problem? – Fernando Santiago Jun 22 '15 at 20:05
  • @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. – MichaelJones Jun 23 '15 at 9:53
  • 1
    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 – 3bdalla Dec 10 '18 at 12:23
3

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.

  • 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. – Shane Madden Oct 4 '12 at 6:19
  • @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 Oct 4 '12 at 19:25
  • ...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). – rightstuff Oct 4 '12 at 19:31
  • 3
    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. – Shane Madden Oct 4 '12 at 19:46
  • 1
    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 – Shane Madden Oct 4 '12 at 22:53

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.