-
-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tls_client_auth
#328
tls_client_auth
#328
Conversation
a2fa80f
to
d3da95b
Compare
As noted in erlef#318 (comment), `httpc` by default will re-use existing connections. This is great if you're using normal HTTPS, but if you're using client authentication then you need to make sure that every time `httpc` connects to a host, it's using the client authentication, which is impossible in practice. This works around that, by creating a new profile which disables that functionality. Using that profile for requests which provide SSL overrides will ensure that each of those requests will use the client certificate.
d3da95b
to
014e374
Compare
In addition to the separate profile, this header serves as a note to both the remote server and `httpc` that we're not keeping the connection open after the request.`
I was thinking to go more of a dynamic supervisor approach instead of the short keepalive one:
|
A slightly simpler option is to just delegate this to the user. In normal circumstances it is enough to provide the tls client certificate to all For cases like our tests and also for users that use multiple issuers on the same domain, we can just tell them to create |
Love that simpler option, and it works for the conformance tests.
|
Fixes: #318 #327
I think even this attempt with the profile is still a bit flaky. I need to figure out if the errors I'm seeing with the conformance suite are due to race conditions here, or something else.