forward: feature to forward client certificate infos

[zyclonite]

Added switch to enable forwading of client certificate CommonName and SerialNumber to origin via X-SSL- headers

enables the origin server to check the common name and/or serial number after the proxy validated/terminated the ssl connection

[pquerna]

I wonder if this should be controlled by a template string?

Apache and other webservers do it that way

So it would be something like the forwarder having a map[string]string, of Header names and header format strings, using text/template:

map[string]string{
   "X-SSL-Client-CN": "{{.Request.TLSInfo.Cert.ClientCN}}".
}

[zyclonite]

sounds like a good idea but i am quite new to golang so this could take me a while ...

[beejei]

Please apply this feature to release. I'm looking forward this.

[jgiles]

We're also interested in extracting certificate info and adding it to the forwarded request headers.

@pquerna would the recommended approach be a generic header-addition mechanism of the sort supported by nginx, Apache, etc?

I like that idea, though especially for extracting certificate fields the structs might be complicated enough that extraction with template strings could be a pain (we have arrays, conditionally-present things, etc): https://golang.org/pkg/net/http/#Request

Do you have a sense of how much work that would be to add, and how one might get started?

[jbdoumenjou]

Hi @zyclonite , this feature would be awesome!
IMHO, the simplest way to have a more complete solution would be an X-SSL-Client-Cert header.
In this way, the header with the client certificate contains all the necessary informations and you can keep the actual mechanism.
I did some tests and I would be very happy to help you if you wish.

[zyclonite]

hi @jbdoumenjou,

i tried to have less complexity on the origin, simply trusting the oxy layer to offload the authentication and forwarding just some credentials would be ideal for my use-case. always forwarding the complete certificate is quite some payload to smaller requests
if in understood your approach correctly, this header is sent every request, disabling features that come already with tls, like e.g. session resumption (cert needs to be parsed on the origin every time to identify the user..)

[jbdoumenjou]

Effectively, it is not exactly the same need. I was thinking about one more flag option to pass the certificate and so all the associated data. Indeed, it seems overkill just for one little information about the client certificate. :)

[juliens]

Considering the refactoring #229 this feature should implement as a middleware.