Closed jethrogb closed 4 years ago
I think CI is using too old a version of GnuTLS (it was introduced in some 3.5)
This repository is obsolete, since all of its functionality exists in upstream OpenConnect 8.x now.
Is OpenConnect v8.05 affected?
However, we generally always have a specific certificate specified, so we just want to send that regardless.
Hmmm… What problem does this solve? What is the problem with not sending the client cert unless it matches the expected issuer?
And how does GnuTLS's forcing option behave if no client cert is specified?
Oh oops, this showed up somewhere high up on Google when searching for OpenConnect git.
What is the problem with not sending the client cert unless it matches the expected issuer?
Sometimes servers are misconfigured in that they don't advertise DNs that they do accept.
And how does GnuTLS's forcing option behave if no client cert is specified?
I haven't tested this but my assumption is that it will just proceed without a client cert.
You may want to move this upstream to https://gitlab.com/openconnect/openconnect/merge_requests.
I suspect there may be some pushback against sending a mismatched certificate to the server, since this could leak information about the client's identity (e.g. I'm connecting to vpn.bigcorp.com
but I accidentally specify my certificate for vpn.othercorp.com
).
TLS servers may request a certificate from the client. This request includes a list of 0 or more acceptable issuer DNs. The client may use this list to determine which certificate to send. GnuTLS's default behavior is to not send a client certificate if there is no match. However, we generally always have a specific certificate specified, so we just want to send that regardless.