Lighttpd

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?

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).

Thanks for the response. If I have some free cycles I'll try to reproduce the relevant certs and attach them here. However, I want to make clear that my lightttpd setup can accept both types of certs (RSA and ECC) without issues.

The problem occurs if I have an RSA one (with its RSA root CA) as the default. And an ECC one (with its ECC root CA) for a specific hostname (say, foobar). The RSA one is always returned even if a client specifies "foobar" in the SNI. So authentication fails because the "foobar" client is expecting ECC certs.

If I reverse the order: ECC one (with ECC root CA) for default, and RSA one (with RSA root CA) for host "barfoo", then an SNI with "barfoo" will return the ECC, and no SNI returns RSA, as expected. So correct certs are always returned and authentication proceeds.

FYI: I did a quick review of the code in mod_openssl. When SNI is provided, the callback set by SSL_CTX_set_tlsext_servername_callback() is called. This sets the URI authority to that provided in SNI and re-runs configuration to select certs. The code then calls SSL_use_certificate() and SSL_use_PrivateKey() using the values obtained from ssl.pemfile configured for the SNI host. There is nothing special here to distinguish RSA or ECC certificates. I do not think that anything special needs to be done beyond this, but please correct me if I am mistaken in my understanding on how to use the openssl API here.

(Aside: I think you reversed what you meant to say in "If I reverse the order...")

I am hoping that #2692, with patch part of lighttpd 1.4.48 and allows setting explicit SSL server certificate chain already provides a means to address the issue you were seeing.

Same result with 1.4.55:

lighttpd/1.4.55 (ssl) - a light and fast webserver

Event Handlers:

        + select (generic)
        + poll (Unix)
        + epoll (Linux)
        - /dev/poll (Solaris)
        - eventports (Solaris)
        - kqueue (FreeBSD)
        - libev (generic)

Network handler:

        + linux-sendfile
        - freebsd-sendfile
        - darwin-sendfile
        - solaris-sendfilev
        + writev
        + write
        - mmap support

Features:

        + IPv6 support
        + zlib support
        - bzip2 support
        + crypt support
        + SSL support
        + PCRE support
        - MySQL support
        - PgSQL support
        - DBI support
        - Kerberos support
        - LDAP support
        - PAM support
        - memcached support
        - FAM support
        - LUA support
        - xml support
        - SQLite support
        - GDBM support

I've confirmed the same behavior with lighttpd 1.4.55 and openssl 1.0.2u. Sorry, I'm not able to upgrade to openssl 1.1.x to test on this system but at least they're the most current releases on their respective branches.

I agree that Bug #3009 is a duplicate. I'm not using vhosts, the RSA and EC private keys I'm using are both in the same format (----- BEGIN PRIVATE KEY -----) and s_client can establish a secure connection (compatible cipher) using either certificate/key, so the other concerns raised in that issue don't apply here.

I can supply copies of my test certificates and keys on request.

I can supply copies of my test certificates and keys on request.

Yes, please. That would help get me going on setting up a test environment more quickly. (Sorry that I didn't get to it today.)

I was not able to reproduce with my initial attempt, using tip of my development branch and OpenSSL 1.1.1g, nor after building the lighttpd-1.4.55 tag.

I took your test certs (thank you) and put them in /dev/shm/certs/*. Here is the config I used:

server.document-root = "/dev/shm/www" 
server.bind = "127.0.0.1" 
server.port = 8080
mimetype.assign = (".txt" => "text/plain", ".html" => "text/html" )

server.modules += ("mod_openssl")

$SERVER["socket"] == "127.0.0.1:8443" {
    ssl.engine = "enable" 
    # default: self-signed RSA certificate
    ssl.pemfile = "/dev/shm/certs/rsa.pem" 
    ssl.privkey = "/dev/shm/certs/rsa.key" 
}

$HTTP["host"] == "server1" {
    # self-signed RSA certificate
    ssl.pemfile = "/dev/shm/certs/rsa.pem" 
    ssl.privkey = "/dev/shm/certs/rsa.key" 
}

$HTTP["host"] == "server2" {
    # self-signed EC certificate
    ssl.pemfile = "/dev/shm/certs/ec.pem" 
    ssl.privkey = "/dev/shm/certs/ec.key" 
}

I executed lighttpd in the foreground in one terminal, from the src/ directory of my source tree, running under a test account:

./lighttpd -D -f ttt.conf -m $PWD/.libs

I do not have the root CA you used for your self-signed cert, so I executed the following openssl s_client commands in another terminal, without -CAfile lighttpd.d/certs/root.pem

openssl s_client -connect 127.0.0.1:8443 -showcerts -servername "server1"  # expected RSA cert; got RSA cert
openssl s_client -connect 127.0.0.1:8443 -showcerts -servername "server2"  # expected EC cert;  got EC cert
openssl s_client -connect 127.0.0.1:8443 -showcerts -servername "default"  # expected RSA cert; got RSA cert

When I got the RSA cert:

Server certificate
subject=C = US, ST = Oregon, O = Biamp, CN = rsa-server

When I got the EC cert:

Server certificate
subject=C = US, ST = Oregon, O = Biamp, CN = ec-server

Would you please try to reproduce on your system using the same steps I used above? I suspect that you will be able to reproduce it on your system. Then, we get to go look to see if openssl was built and packaged differently between our systems. My system is x86_64 and running Fedora 32.

I noticed that your logs indicated TLSv1.2 was negotiated.

I also ran the commands with openssl s_client -no_tls1_3 with the same result, the EC cert was correctly returned for "server2"

I can reproduce the issue if I define the cipher preference order like so:

    ssl.cipher-list = "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384" 

but the default output of openssl ciphers on my system lists them in this order:

    ssl.cipher-list = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384" 

I am curious. What curve did you use when you created the EC cert?

I used the following commands to create new test certs:

openssl req -x509 -newkey rsa:4096 -keyout rsa.key -out rsa.pem -days 365 -subj '/CN=rsa-server' -nodes
openssl genpkey -out ec.key -algorithm ec -pkeyopt ec_paramgen_curve:P-256
openssl req -x509 -key ec.key -out ec.pem -days 365 -subj '/CN=ec-server' -nodes

On my development branch, I was able to experiment with mbedTLS and GnuTLS replacing openssl. Both mbedTLS and GnuTLS worked as expected.

Re-ordering the cipher list solves the problem on my target when using the self-signed certificates. However, I'm concerned by your statement that "lighttpd mod_openssl currently does not load a separate certificate chain when installing the certificate chosen for SNI." In my case, the real certificates will be generated by different organizations so they won't have the same certificate chain. Is there some way that I can get both certificate chains into the SSL_CTX? For example, if I included both sets of CAs in the file with the default certificate, would that cause them all to be loaded into the context?

For example, if I included both sets of CAs in the file with the default certificate, would that cause them all to be loaded into the context?

I believe so, but have not tested.

I'll address the limitation in the next version of lighttpd, but I do not yet know when that will be.

@starr please report to your upstream package maintainer(s) that openssl 1.0.2 reached end-of-life on 31 Dec 2019, and there will be no more security patches.
https://www.openssl.org/policies/releasestrat.html
https://www.openssl.org/blog/blog/2019/11/07/3.0-update/
Your upstream package maintainers really, really ought to migrate to openssl 1.1.1.

Similarly, lighttpd 1.4.55 was released 31 Jan 2020 and there are numerous important fixes since 1.4.51 (released 14 Oct 2018). Please upgrade.

I might be misunderstanding, but there appears to be a mis-feature in openssl which re-uses the trusted CA certificate list (lighttpd ssl.ca-file) from the openssl (SSL_CTX *) to complete the server certificate chain, if the chain has not been set for the openssl (SSL *). In other words, even though the CA list is intended for client certificate verification, it is also used for the server certificate if a chain has not been set for the server certificate.

If my understanding is correct, then your default server certificate can contain the full chain in the ssl.pemfile and be different from that of your SNI hosts. The chain of intermediate CAs for your SNI hosts could be in ssl.ca-file