Lighttpd

is someone working on this thing?

not atm.
we dont support gnutls for ssl and openssl needs 0.9.9 afaik to support SNI. 0.9.9 is not released yet. that said... we cant support it atm.

OpenSSL 0.9.8f has been released and supports SNI.

OpenSSL 0.9.8f supports SNI, so should we expect SNI support in 1.4 or 1.5 (or both?)? Thanx!

-- meka

Hi,

after checking out the server name indication patch for apache mod_ssl, I decided to implement TLS server name extension support for lighttpd.

For TLS server name indication to work, OpenSSL 0.9.8f or greater is required and has to be compiled with enable-tlsext, which is not yet done by default with most distributions (at least not with Debian unstable).

With the appropriate patch applied against either lighttpd 1.4.18 or 1.5.0-svn, it is then possible to specify additional certificates within $HTTP!["host"] conditionals, e.g.

$SERVER["socket"] == "10.0.0.1:443" {
  ssl.engine                  = "enable" 
  ssl.pemfile                 = "www.example.org.pem" 

  $HTTP["host"] == "foo.example.org" {
    ssl.pemfile                 = "foo.example.org.pem" 
  }

  $HTTP["host"] =~ "^(bar\.)example.org(:|$)" {
    # certificate with subjectAltName=DNS:example.org,DNS:bar.example.org
    ssl.pemfile                 = "bar.example.org.pem" 
  }
}

$HTTP["host"] == "foo.example.org" {
  document.root               = "/srv/www/foo.example.org" 
}

or, alternatively,

$SERVER["socket"] == "10.0.0.1:443" {
  ssl.engine                  = "enable" 
  ssl.pemfile                 = "www.example.org.pem" 
}

$HTTP["host"] == "foo.example.org" {
  ssl.pemfile                 = "foo.example.org.pem" 
  document.root               = "/srv/www/foo.example.org" 
}

$HTTP["host"] =~ "^(bar\.)example.org(:|$)" {
  # certificate with subjectAltName=DNS:example.org,DNS:bar.example.org
  ssl.pemfile                 = "bar.example.org.pem" 
}

Besides ssl.pemfile, ssl.ca-file and ssl.cipher-list (with lighttpd 1.4.18 only) may also be configured independently for each virtual host.
As TLS extensions are not supported in SSLv2, however, it does not make any sense to set ssl.use-sslv2 within a $HTTP!["host"] conditional.

On the client side, I had success with both Firefox 2.0 and Opera 9 (running on GNU/Linux).

Regards,
Peter

Following up, here are some updated patches for lighttpd trunk and the lighttpd-1.4.x branch.

These include support for $HTTP!["scheme"] conditionals, e.g.

$HTTP["scheme"] == "https" {
  $HTTP["host"] == "foo.example.org" {
    document.root               = "/srv/www/foo.example.org" 
    ssl.pemfile                 = "foo.example.org.pem" 
  }
}

A minor update for lighttpd 1.4.x r2080 or later, especially the 1.4.19~r2118 pre-release.

From changeset 2080 onwards, the cond_cache is reset after invocation of the TLS servername callback function (in response.c instead of connections.c). Therefore, the following lines are also necessary in the network_ssl_servername_callback function:

config_cond_cache_reset(srv, con);
config_setup_connection(srv, con);

Is the SNI Patch in the 1.5 Version of the SVN included? When i make a dry-run of the 1.5 Patch, there are many hunks. I tryed it with 2 different CERTS, but just the main cert will be delivered from the server, no the other cert i wanted.

$SERVER[socket] == "192.168.2.110:443" {
  ssl.engine                  = "enable" 
  ssl.pemfile                 = "/etc/pkis/CA/private/intranet.intra-key-cert.pem" 

  $HTTP[host] == "intranet.intra" {
    ssl.pemfile                 = "/etc/pkis/CA/private/intranet.intra-key-cert.pem";
  }

  $HTTP[host] == "tf.intranet" {
    ssl.pemfile                 = "/etc/pkis/CA/private/tf.intranet-key-cert.pem";
  }
}

he can read the intraner.intra cert, but wont read the other cert. I checked out the newest version of lighttpd at 4pm this day, dont remember the revision. Do i need to use 1.4.x tree?

-- webmaster

Replying to webmaster@lord-pinhead.com:

Is the SNI Patch in the 1.5 Version of the SVN included?

No, it has not yet been integrated into lighttpd trunk.

When i make a dry-run of the 1.5 Patch, there are many hunks. I tryed it with 2 different CERTS, but just the main cert will be delivered from the server, no the other cert i wanted.

I updated the lighttpd-1.5 patch for svn r2171, that should make it work again.

Thanks, the Patch works fine :) Now i can make a quick howto about Lighty and SNI and change my production servers.

-- webmaster

Is anyone have issues with this patch with Firefox and v1.4.23? With Firefox 3.5 RC3 https://sni.velox.ch/ seems to show that SNI is being sent correctly. However, when I try to access two of my sites using SNI (https://liqd.org/wiki/ and https://code.liqd.org/) I get the following error in the log:

####-##-## ##:##:##: (network.c.73) SSL: failed to get TLS server name

Firefox is sent the default certificate. However, when using Internet Explorer 8 and Opera 9.64 no such error occurs and the browsers are sent the correct certificates.

dbb wrote:

Is anyone have issues with this patch with Firefox and v1.4.23? With Firefox 3.5 RC3 https://sni.velox.ch/ seems to show that SNI is being sent correctly. However, when I try to access two of my sites using SNI (https://liqd.org/wiki/ and https://code.liqd.org/) I get the following error in the log:

[...]

Firefox is sent the default certificate. However, when using Internet Explorer 8 and Opera 9.64 no such error occurs and the browsers are sent the correct certificates.

Tested today and it apparently works with no change in configuration, weird.

When I was testing this feature I noticed that:
1) you always must set SSL cert for IP adres (socket), without that it was not working (a little anoying if you don't have cert for eg. primary domain)
2) When you shutdown lighttpd, then call to SSL page with SNI from FireFox - you get info that page is unavailable. You start lighttpd, and reload page - and SNI is not working any longer. Don't know if this is bug in FireFox or lighttpd related thing, but it looks like after reload SNI procedure is not triggered.