Hi, > This is a loop. yes and no: It's not exactly a loop, since the two certificates belong to certificate-chains of two different certificates, in this case:
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 And I don't see why it should be a problem when e.g. two authorities sign each others certificates. So, even Cert1 <- A <- B Cert2 <- B <- A shouldn't cause *any* problem. If this makes SSL of lighttpd break, it's a serious lighttpd-bug. And the wget/OpenSSL-error-message "OpenSSL: error:1408E098:SSL routines:SSL3_GET_MESSAGE:excessive message size" looks like lighttpd tries to send A and B multiple times... (By the way: Why does lighttpd even detect such loops? The lighttpd-config- file *exactly* defines ca-files for every SNI-domain, which lighttpd should simply send to the client. I don't see why lighttpd wants to be "smart" and analyzes these ca-files...) > This means that you > have subject names that overlap with "public" subject names (as you > assume those are already present in clients) of a root certificate Yes, there are names which *may* overlap with public subject names; but this depends on the client. Maybe one of the certificate-chain- certificates is not necessary for some clients, but it may be necessary for other clients. > I'd say your setup was already broken. No, it's not. Except you want to forbid cross-signing (which obviously exists, and is used even by root authorities). But see below. > If you care about your system you should always check it after updating > and have a monitoring solution that helps you, and probably a test > setup in your deployment :) Yeah, that's how I found this bug. But I don't think everyone has an identical test-system, and tests a "urgency=high" security-update before. > There is no "solution" apart from fixing your CA setup. The CA setup isn't broken. The only thing I could do here, is to remove "UTN - DATACorp SGC signed by AddTrust External CA Root" from the chain, but then: What about clients which know "AddTrust External CA Root" but don't know "UTN - DATACorp SGC"? (And even if this works in this case, it may very well fail in others.) > No; usually your ca-files can be merged without problems; if you have > certificates from the same issuer (as in "same certificate") they are > even identical. No! There are *lots* of certificates which have the same issuer and subject; without this, you wouldn't be able to update certificates! Issuer + Subject + Validity is probably be unique, but Issuer + Subject is certainly not! And setups like Cert1 <- A(2008-2018) <- B Cert2 <- A(2012-2022) <- B are really really common. > We have been discussing this upstream, but still found no other "good" > solution. Theoretically we could allocate a SSL_CTX for each > combination of server socket and "sni block" (with a ssl.pemfile), > which *might* work, but would be a rather big change, and might break > even more, and also is not what we would want to have in the end > (wasting resources). 1.4.31-4 worked fine here. I hope that I've misunderstood parts of your mail; but if you really treat Issuer+Subject as unique, SNI in lighttpd is terribly broken. I don't know the inner workings for lighttpd and the details of the https-protocol, but why does lighttpd analyze the ca-files at all? Couldn't it simply look into its config-file, and send out the ca-file which belongs to the current pemfile? regards, Roland -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
