Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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>
share|improve this question

2 Answers 2

up vote 3 down vote accepted

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.

share|improve this answer
    
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 at 12:21

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.

share|improve this answer
    
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
    
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. –  Shane Madden Oct 4 '12 at 19:43
1  
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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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