Expose client certificate in env

[HoneyryderChuck]

I didn't see this documented anywhere, so I assume it is a missing feature: How does a rack server expose the TLS client certificate from the connection to the application server?

[jeremyevans]

Correct, this is undocumented as far as I know. We could specify a key like rack.request.certificate. The big problem here is what the value should be. Requiring openssl-specific objects is limiting, and using a duck-typing approach like most of the rack SPEC uses is unlikely to be feasible with as large an API as certificates tend to have.

[ioquatix]

Does any server implement this? If so, what's the current "defacto" interface?

[HoneyryderChuck]

I don't think any server does, although most of them handle tls just fine. I also don't know how this can be handled in the reverse-proxy scenario.

[HoneyryderChuck]

Could this be the way to handle it? Given that rack is essentially "cgi with sprinkles", perhaps it makes sense to follow what cgi defines?

[ioquatix]

This seems like a agnostic way forward, but I'm hesitant to introduce all those keys.

I'm assuming not every request has a client certificate. Maybe we can define a subset of the OpenSSL interface. There is a cost to decoding and expanding all the keys into env.

[HoneyryderChuck]

I think that this can work as an optional extension, just like mod_ssl, and it should be up to the servers to implement it. The spec could define something like "application servers interested in exposing TLS connection details should do so via the SSL_* family of keys" and so on.

rack itself wouldn't change. Rack::Request could provide some helpers, but to be fair, the need is so infrequent (seems I'm the first one to ask for it? :) ), that I would forego it. A nice "reference implementation" could be provided, such as building this into webrick.

In my case, I'm only interested in the SSL_CLIENT_* group. It's where I'll be starting from at least.

[ioquatix]

Okay, that seems like a fair starting point.