Project

General

Profile

Bug #2562

SSL + SNI with cyclic CAs/not unique issuers? broken

Added by rk about 3 years ago. Updated 9 months ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
TLS
Target version:
Start date:
2014-03-13
Due date:
% Done:

0%

Missing in 1.5.x:
No

Description

Since a "security update" (at least in the Debian version) of lighttpd in November 2013, SSL doesn't correclty work with SNI, anymore.

The problem is probably, that all ca-files now end up in the same SSL_CTX, which breaks some very common certificate-setups (and silently broke my previously perfectly-working setup):

  1. Cross-signed certificates don't work anymore:
    Several root-authorities (and intermediate certificates) cross-sign each other. This shouldn't cause any problem. But after the update, this can break SSL with lighttpd, since certificate-chains like:
     Cert1 <- C <- A <- B
     Cert2 <- D <- B <- A

    don't work anymore. And such certificate-chains are quite common.
    Real-world-example with 2 SNI-hosts/certificates:

     Cert1                           signed by PositiveSSL CA 2
     PositiveSSL CA 2                signed by AddTrust External CA Root
     AddTrust External CA Root       signed by UTN - DATACorp SGC
    
     Cert2                           signed by EssentialSSL CA
     EssentialSSL CA                 signed by COMODO Certification Authority
     COMODO Certification Authority  signed by UTN - DATACorp SGC
     UTN - DATACorp SGC              signed by AddTrust External CA Root

    The only way to work around this problem, is to remove one of the intermediate- certificates -- which isn't a solution and has serious drawbacks:

    • Browsers have different built-in root-certificates, so if you remove a intermediate-certificate, the certificate-verification may fail in some browsers.
    • When you buy a SSL-certificate, you usually receive a certificate and all intermediate certificates. Before the update, you could simply create pem- and ca-files for each SNI-host separately, and add them to lighttpd.
      Now, after the update, this isn't possible anymore; instead, every time an SSL-certificate is added/updated, you have to examine all certificate-chains for cross-signed certificates, and try to detect and eliminate any cross-signings.
  2. Different versions of intermediate-certificates don't work anymore.
    As far as I understood, lighttpd now requires that each certificate has an unique Issuer-Subject-combination. If this is the case, SSL in lighttpd is seriously broken!!

    Usually, certificate authorities update their (intermediate-)certificates from time to time, and the validity-time of these certificates overlap. So, at the same time, there are e.g. 2 certificates with the same Issuer-Subject-combination but a different Validity. This is absolutely necessary to update certificates, and results in certificate-chains like:

     Cert1 <- A(2008-2018) <- B
     Cert2 <- A(2012-2022) <- B 

    So, if lighttpd really requires that each Issuer-Subject-combination is unique, such chains aren't possible anymore, and SSL+SNI isn't usable at all with lighttpd.
    If lighttpd only requires that each Issuer-Subject-Validity-combination is unique, this is probably not a problem.

    So, does lighttpd require Issuer+Subject or Issuer+Subject+Validity to be unique?

Workarounds:
  • Examine all certificate-chains every time a certificate is added/updated, and try to eliminate cross-signings, hope that this doesn't break any certificate-validations and hope that there will be no certificate-updates.
  • Downgrade to the lighttpd-version before the update, and live with the security-holes.
  • Don't use SNI.
  • Switch to a different webserver.
Proposed solution:
  • Add some notes about this behavior and its problems to the lighttpd-documentation.
  • Modify ligttpd, so that it doesn't try to merge the ca-files.
    (or better: modify lighttpd or OpenSSL, so it simply sends out the given ca-files, withouth trying to be "smart" by analyzing them.

More details: see Debian Bug#729555, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729555


Related issues

Related to Feature #2692: [PATCH] allow setting explicit SSL server certificate chain New 2015-12-03

History

#1 Updated by stbuehler about 3 years ago

  • Subject changed from SSL + SNI broken to SSL + SNI with cyclic CAs/not unique issuers? broken
  • Priority changed from High to Low

I've already made my position very clear; I consider cyclic CAs broken, merging all certificates into one file is expected to work - whether this needs unique Issuer: fields or whether other ways of identifying a certificate are used depends on openssl and the CA. Similar openssl could support cycles in such merged files.

#2 Updated by rk about 3 years ago

Cyclic CAs certainly shouldn't appear in a certificate-chain of a single certificate.

But: There are certificates from different certificate authorities, which use intermediate-certificates in different orders, or use cross-signed root-certificates e.g.:

  • Authority 1: Cert1 <- A <- B <- root
  • Authority 2: Cert2 <- B <- A <- root

or

  • Authority 1: Cert1 <- A <- root1 <- root2
  • Authority 2: Cert2 <- B <- root2 <- root1

And such chains certainly aren't broken, and shouldn't cause any problems; but they unfortunately do with lighttpd.

#3 Updated by darix about 3 years ago

How would you get your scenario without cross signing?

#4 Updated by gstrauss 11 months ago

  • Category set to TLS

#5 Updated by gstrauss 9 months ago

@rk: hoping you still receive updates for this (2+ year old) issue.

A pull request has been submitted in https://github.com/lighttpd/lighttpd1.4/pull/62 which permits specifying the server cert chain. Does that patch provide a solution to your issue?

#6 Updated by gstrauss 3 months ago

  • Related to Feature #2692: [PATCH] allow setting explicit SSL server certificate chain added

Also available in: Atom