Project

General

Profile

Bug #2842

Lighttpd Returns Wrong Cert In Multi-cert Set-up

Added by cnguyen 22 days ago. Updated 17 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
TLS
Target version:
Start date:
2017-11-22
Due date:
% Done:

0%

Estimated time:
Missing in 1.5.x:

Description

lighttpd (v. 1.4.45) running on freebsd 11

  • Set up to use multiple SSL certs: a default set, and one used for a particular hostname sent in the SNI extension.
  • Certs set (i.e., pemfile and ca-file) can be RSA, ECC, or a mix of both.
  • All combinations work except for the case of the default set being RSA and the set used for the hostname being ECC.
  • In this case, even though the client sends the right SNI, lighttpd will always return the RSA one. As such, the TLS/SSL handshake fails.
  • Note: RSA/RSA, ECC/ECC and ECC/RSA combination work as expected. The default one is returned for most connections. The one associated with the hostname in the SNI extension is returned if extension is included.

History

#1

Updated by gstrauss 19 days ago

Would you please attach your configs (lighttpd -p -f /etc/lighttpd/lighttpd.conf) and describe the contents of the ssl.pemfile and ssl.ca-file, but please do not share the secure files?

#2

Updated by cnguyen 17 days ago

Unfortunately this happened several months ago and we've decided not to support clients that use SNI extensions. This is partly due to the fact that not all the clients we support can be configured to use SNI extensions. So we no longer have the relevant conf file. We're going through our internal lists of issues for resolution and noticed that this has an external dependency. So we decided to raise this issue so that you are aware of it.

Since it was an experiment, we used a default/stock lighttpd configuration using a socket conditional as well as host conditionals within the socket conditional as described by your documentation. https://redmine.lighttpd.net/projects/1/wiki/docs_ssl#Server-Name-Indication-SNI. We used openssl to generate self-signed CA certs as well as the server cert (signed by these "root" CAs).

As stated previously, when the socket conditional/default certs are ECC type, then the host conditional certs can be ECC type or RSA type. If a client sends an SNI extension that matches the host conditional, then the associated cert will be returned. Otherwise, the socket conditional cert is returned.

But if the socket conditional certs are RSA, then the host conditional certs must also be of RSA type for the SNI extension matching to work correctly. If it is ECC type, then the socket conditional cert (of type RSA) is always returned, even though the client sent an SNI extension that matched the host conditional. Obviously, this would not match the client configuration and will fail.

Note that the socket conditional and host conditional certs always use different "root" CAs (even if they are both RSA types or ECC types).

Also available in: Atom