Thanks so much for the response! I think I found the issuer cert needed (unless it's causing the problems below) - and I exported it from the chrome certificate manager as a .pem file. I no longer got a certificate validation failure, and after telling the shill program in ChromeOS to stop destroying my tun0 devices (sudo stop shill followed by sudo start shill BLACKLISTED_DEVICES="tun0,br0"), I got a stable connection! On Mon, Nov 5, 2018 at 3:41 PM David Woodhouse <dwmw2 at infradead.org> wrote: > > On Mon, 2018-11-05 at 14:51 -0500, Adam Allgood wrote: > > I have, however, > > successfully connected to the VPN with my CAC on a Windows test > > machine in the office using the Windows Cisco AnyConnect client, so I > > do not believe the problem is with the certs themselves. > > The problem here is normally that your own cert is signed by an > intermediate CA which isn't known to the server. You have to provide > that intermediate on the wire, in order for the server to complete the > trust chain back to the root CA that it *does* have. > > Can you capture the connection from the Windows box, when it succeeds? > Look how many certificates it presents. > > If you have the correct intermediate CA available to OpenConnect, in a > --cafile argument or the standard system certificate store, it'll > explicitly make sure it includes it. It also looks for it in the > PKCS#11 token, which is why you see the 'no issuer in PKCS#11' message > which is normally harmless. >
