Understanding and Resolving Apache’s SNI Warning for Name-Based SSL Virtual Hosts


4 views

When you see the warning message [warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366) in your Apache logs, it's indicating an important technical limitation rather than an error in your configuration.

Traditionally, SSL/TLS handshakes occur before any HTTP communication, which means the server can't see the Host header before choosing which certificate to present. This created problems for hosting multiple SSL sites on a single IP address.

Before SNI, there were two workarounds:

  1. Using separate IP addresses for each SSL site
  2. Using wildcard or multi-domain (SAN) certificates

Your setup works because you're using wildcard certificates (wild.fareoffice.com.crt) for multiple subdomains. This technically doesn't require SNI since the same certificate validates all subdomains. However, Apache still issues the warning because:

# Your current VirtualHost configuration

  ServerName sub1.domain.com
  SSLEngine on
  SSLCertificateFile /path/to/wildcard.crt
  # ... other SSL directives

Newer Apache versions (since 2.2.12) are more vocal about potential compatibility issues. They warn about this scenario because:

  • Non-SNI clients (like IE on Windows XP) would fail if you used different certificates
  • Modern best practices strongly recommend SNI support
  • The warning helps administrators understand potential client compatibility issues

While your current setup works, here are ways to address the warning:

Option 1: Suppress the Warning (Not Recommended)

You could modify your logging level, but this hides potentially useful information:

LogLevel warn ssl:warn

Option 2: Modernize Your Configuration

Update your SSL configuration to explicitly handle SNI and non-SNI cases:


  ServerName default.domain.com
  # Default certificate for non-SNI clients
  SSLEngine on
  SSLCertificateFile /path/to/default.crt
  # ... other SSL directives



  ServerName sub1.domain.com
  SSLEngine on
  SSLCertificateFile /path/to/specific.crt
  # SNI-aware configuration
  SSLStrictSNIVHostCheck on

According to caniuse.com, SNI is supported by:

  • All modern browsers (Chrome, Firefox, Safari, Edge)
  • IE7+ on Windows Vista or later
  • Not supported in IE on Windows XP

For new deployments, consider:

# Modern cipher suite example
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder on

When you see this log message in Apache:

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

It's not a false positive - it's a legitimate warning about a fundamental limitation in HTTPS protocol behavior that becomes apparent when using name-based virtual hosts with SSL.

The core issue stems from the SSL/TLS handshake sequence:

  1. Client establishes TCP connection
  2. SSL handshake begins before any HTTP communication
  3. Server must present the correct certificate before knowing the Host header

Without SNI, Apache can't determine which virtual host's certificate to present because the hostname is only transmitted in the HTTP headers (after SSL is already established).

Your current configuration will work for:

  • Modern browsers (Chrome, Firefox, Safari, Edge) as they all support SNI
  • Most mobile devices

But will fail for:

  • Windows XP with IE 8 or earlier
  • Android 2.x browsers
  • Some corporate proxy servers

Option 1: Dedicated IP per host (traditional approach)


  ServerName sub1.domain.com
  # SSL config...



  ServerName sub2.domain.com
  # SSL config...

Option 2: Unified certificate with Subject Alternative Names (SAN)


  ServerName sub1.domain.com
  ServerAlias sub2.domain.com
  SSLCertificateFile /path/to/unified.crt
  # Other SSL config...

Use OpenSSL to verify SNI support:

openssl s_client -connect yourserver:443 -servername sub1.domain.com
openssl s_client -connect yourserver:443 -servername sub2.domain.com

Check the certificate details in each case to ensure the correct cert is being served.

While SNI is the modern solution, be aware:

  • Each SNI request adds ~100-200 bytes to the handshake
  • Older hardware SSL accelerators may not support SNI
  • Some CDN configurations have special SNI requirements

For maximum compatibility with legacy clients while using SNI:


  # Fallback for non-SNI clients
  ServerName legacy.domain.com
  DocumentRoot /var/www/legacy
  SSLCertificateFile /path/to/legacy.crt



  # Primary SNI-enabled host
  ServerName sub1.domain.com
  DocumentRoot /var/www/sub1
  SSLCertificateFile /path/to/sni.crt