On Tue, 2009-05-26 at 11:21 -0400, Victor Duchovni wrote: > The server is unhappy with the client certificate chain, and drops the > connection if the client certificate trust chain does not verify. The > same server is willing to accept clients with no certificates at all. > > The server is lame. Don't use it with client certificates that don't > have a complete trust chain.
That makes a certain amount of sense; thanks. Forgive my ignorance -- is there a way to ensure that the full trust chain is included in the certificate itself, rather than having to provide the -CAfile option to openssl(1) separately? I naïvely tried just appending the contents of a working cafile to the certificate.pem file but that's not sufficient. I found another strange behaviour that I didn't expect -- the _order_ of the certificates in the cafile seems to be important. My original scripts which interact with the company's internal PKI infrastructure would download a bunch of certificates separately and I would shove them all in a single file with a command line like: for a in *.crt ; do cat $a ; echo > company-certchain.crt The resulting file would work, and allow me to connect to the server. So I modified the scripts to create one big file just the same... except that they'd be stored in the order that they were downloaded, instead of alphabetical order by filename as the above shell command gave me. And _that_ cafile doesn't work; I still get summarily disconnected. Does ordering in trustchain files matter? If so, how do I ensure I get the right order? -- dwmw2 ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
