10

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>
Arlukin
  • 1,203
  • 6
  • 18
  • 27

2 Answers2

8

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.

bahamat
  • 6,193
  • 23
  • 28
  • So the answer here is to change the `` line to be ``? 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 09: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 https://serverfault.com/questions/578061/rsa-certificate-configured-for-server-does-not-include-an-id-which-matches-the-s?answertab=votes#tab-top 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.

rightstuff
  • 620
  • 1
  • 5
  • 6
  • 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 04 '12 at 06: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 04 '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 04 '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 04 '12 at 19:43
  • 4
    `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 04 '12 at 19:46
  • @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." http://en.gentoo-wiki.com/wiki/Apache2/SSL_and_Name_Based_Virtual_Hosts 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. – rightstuff Oct 04 '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; http://serverfault.com/q/292637 http://serverfault.com/q/330212 – Shane Madden Oct 04 '12 at 22:53
  • You're using an edge case of sub-domains and wild-card certs. I'm talking about the general case. http://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. – rightstuff Oct 05 '12 at 00:20
  • 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: http://pastebin.com/cE5g3eP2 – Shane Madden Oct 05 '12 at 04:25