On Wed, 2016-07-13 at 21:22 -0400, Oliver Hernandez wrote: > I'll send you the requested info. > > I'm comparing to v7.06 built for EL6, posted by Nikos > Mavrogiannopoulos to the mailing list in an earlier thread I started. The one which is now released as an official update for EL6, but without PKCS#11 support? That doesn't work for your server either, AFAICT; its behaviour is identical. Your server is misconfigured; it's presenting its own certificate but *not* the supporting intermediate certificate on the wire. So a client which has only the root CA isn't going to work because there's a missing link and it can't tie your server's cert to the root CA. If you supply only the *intermediate* CA to the client as --cafile, that's where it gets interesting. If you are building with GnuTLS (which you aren't on EL6), it works fine. GnuTLS trusts the CA it was told to trust, and allows the server's certificate. OpenSSL doesn't. I have some vague recollection of looking at this quite recently... it refuses to trust a non-self-signed CA in the same way that it would a self-signed one. So supplying the intermediate CA in the --cafile option doesn't help. As a workaround, add *both* CAs to the same file (just append them) and use that. It'll trust the root CA, and it'll *see* the intermediate one (that the server *ought* to have been providing on the wire), and be able to use it to build up the chain to the trusted root. You can reproduce this with ?openssl s_client -connect $server:443 -CAfile foo.pem I think this should probably be considered an OpenSSL bug. It happens with 1.0.2 and 1.1 (HEAD) too, FWIW. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20160714/e5acd50c/attachment-0001.bin>
