Skip to content

Conversation

@dogvisor
Copy link

... populated with the DN from the client-provided certificate. (By way of recreating the functionality of the NewSingleHostReverseProxy handler, and extracting it from the assumed-to-have-been validated client certificate.)

…e client-provided certificate. (By way of recreating the functionality of the NewSingleHostReverseProxy handler.)
@Doctor-love
Copy link
Owner

Lovely - I will have a look at this.
Just wondering how clients who submit multiple client certificates should be handled and what the name of the header should be - I believe there are some standards.

@dogvisor
Copy link
Author

Re: header naming, I consider "X-Certainly.." but that convention is apparently long-deprecated: https://tools.ietf.org/html/rfc6648

And for the rest, the http.Request.TLS object that holds the client cert has an additional member that holds chains of validated certs, which will probably give you what you need to construct a multi-identity header value.
https://golang.org/pkg/crypto/tls/#ConnectionState
https://golang.org/pkg/net/http/#Request

@Doctor-love
Copy link
Owner

I'm gonna steal the custom proxy handler code and include that first - it will be useful for HSTS and other interesting stuff as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants