-
-
Notifications
You must be signed in to change notification settings - Fork 48
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
authentication mode
#318
Comments
tls_client_auth
authentication mode
|
@paulswartz Is there a reason why we wouldn’t set the client cert on everything? (Including the Configuration and JWKs) |
That's a good point; I didn't realize that |
This kind of works. If you don't load anything from the relevant host, everything passes. But, if you have multiple issuers at the same hostname (as we do with the conformance suite), then accessing any provider on that host before the mTLS one causes the issue again. |
@paulswartz Yeah, that’s not great. I’m wondering if it is a bug that httpc is reusing connections with different configurations. In that case we’ll probably have to start net inets profiles for different tls settings or consider a different http client. |
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.
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.
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.
* feat: parse `mtls_endpoint_aliases` * feat: use `mtls_endpoint_aliases` if using `tls_client_auth` method * feat(oidcc_profile): allow tls_client_auth, enforce ciphers * feat: create an httpc profile which disables keep-alive/pipelining As noted in #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. * feat: tell `httpc` to close the connection if we're using client certs 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.` * feat: `httpc_profile` opt and have the client manage the HTTPC profile * fixup! feat: `httpc_profile` opt and have the client manage the HTTPC profile
Description
Defined in RFC 8705
OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens, this is optional for the FAPI 2.0 Message Signing profile.
See #317 and #264.
The text was updated successfully, but these errors were encountered: