Hi, On Thu, 14 Nov 2013 14:41:32 +0100 Roland Koebler <r.koeb...@yahoo.de> wrote: > > My guess is that the two private CAs you configured have a name > > (Issuer/Subject) conflict; in that case openssl probably can't > > figure out which one to use. > that sounds reasonable, since I now figured out that this only happens > with some pemfiles/ca-files. I have now examined the certificates in > my ca-files, and some have the same Issuer, but they all have > different Subjects. > > But I've found a certificate in 2 ca-files, where: > Issuer of certificate in ca-file1 == Subject of certificate in ca-file2 > Subject of certificate in ca-file1 == Issuer of certificate in ca-file2 > > If I remove one of the certificates from one file, I can connect with > SSL again. (But that's certainly no solution, since they are > different certificates, and the validation probably would fail, then.)
Let's name those two certs A and B, then A.Issuer = B.Subject B.Issuer = A.Subject This is a loop. You also claim that the subjects don't overlap, so these two are the top of the (intermediate) chain. 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 (which is usually self-signed, i.e. Subject == Issuer, which A and B are not). I'd say your setup was already broken. > > This should probably be mentioned in debian/NEWS. > Yes, definitely. > But only mentioning this problem does not really help; there should be > (a) some solution or (b) a warning, that this update maybe just broke > the SSL-connections, and that you should immediately test it and > maybe downgrade again. 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 :) (there is nothing wrong about mentioning it ofc) There is no "solution" apart from fixing your CA setup. > And I think this is a *major* problem, since (as it seems) it breaks > SSL on all servers which use SNI and have two or more certificates > from the same issuer (or with a certificate of the same issuer in the > certificate-chain) -- which probably is *extremely* common. 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. 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). regards, Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
