Bug #2562


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

Added by rk about 9 years ago. Updated over 5 years ago.

Missing Feedback
Target version:


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?

  • 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,

Related issues 1 (0 open1 closed)

Related to Feature #2692: [PATCH] allow setting explicit SSL server certificate chainFixed2015-12-03Actions
Actions #1

Updated by stbuehler about 9 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.

Actions #2

Updated by rk about 9 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


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

Actions #3

Updated by darix about 9 years ago

How would you get your scenario without cross signing?

Actions #4

Updated by gstrauss about 7 years ago

  • Category set to TLS
Actions #5

Updated by gstrauss almost 7 years ago

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

A pull request has been submitted in which permits specifying the server cert chain. Does that patch provide a solution to your issue?

Actions #6

Updated by gstrauss over 6 years ago

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

Updated by gstrauss over 5 years ago

  • Status changed from New to Missing Feedback

@rk: was updated over a year ago by Michael Gilbert:

This only affects wheezy, which is now past end of life. notes that (as of this comment), versions of openssl earlier than openssl 1.0.2 are no longer supported.

If this is still an issue for you in lighttpd 1.4.47 using openssl 1.0.2 or later, please comment here and reopen this ticket and I will endeavor to fix the issue. If not, then it is not worth the effort looking into this further, if for no other reason than that Debian wheezy would not even accept a fix to a terribly old release that has reached and passed end-of-life.


Also available in: Atom