SSL + SNI with cyclic CAs/not unique issuers? broken
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):
- 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.
- 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.
- 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
#1 Updated by stbuehler over 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 over 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
- 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.
Also available in: Atom