openconnect with Belgian EID

[David Woodhouse]

On Thu, 2013-11-07 at 17:08 +0100, Nikos Mavrogiannopoulos wrote:
> On Tue, Nov 5, 2013 at 4:14 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
> 
> > If either of them are responsible for signing your personal cert, then
> > OpenConnect will include them in its SSL negotiation, and that can often
> > 'help' the server to realise that it actually *does* trust the cert in
> > question.
> > If that's the issue, then perhaps OpenConnect needs to be taught to go
> > looking for these 'supporting' certs in the PKCS#11 store, as well as
> > the --cafile. But then again, perhaps GnuTLS ought to do that for
> > itself.
> > Nikos?
> 
> Indeed, that's a nice feature and not too difficult to be implemented
> as PKCS #11 allows searching stored certificates using a DN. It is on
> my todo-list for quite some time but never found the time for that.
> Patches are (of course) more than welcome!

Ick, please not by name! It should be done by key ID.

If we have to do it by DN, is there at least a way to say "that wasn't
the one I wanted. Please give me the *next* cert with the same name"? 

This code would slot in at about line 1642 of OpenConnect's gnutls.c, if
gnutls_certificate_get_issuer() fails to find an appropriate issuer in
the system CA file. (Hey, if we want to make
gnutls_certificate_get_issuer() just *work* in this situation and find
it in the PKCS#11 token, that's great too!)

For the benefit of the peanut gallery and the the archives, this *is*
the solution to Christof's problem. The supporting CA 'Citizen CA' is
also present on the token, and the client needs to explicitly include
that in the SSL negotiations on the wire because the server can't find
it for itself.

-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20131107/ce6f56b3/attachment.bin>