Accessing SSL client certificate's fields in setenv.add-request-header
Added by dsuch over 14 years ago
Hello,
what's below is a working example of an SSL proxy which does client autentication through SSL certificates,
it's working fine and I have no troubles with it. Well, almost. See the commented out line? What I'm
trying to do is to pass on the various fields from the client certificate to the backend server
but I can't quite get the syntax needed for accessing environment variables from within
a setenv.add-request-header call.
Things that I've tried so far include:
setenv.add-request-header = ("X-SSL_CLIENT_S_DN_CN" => env.SSL_CLIENT_S_DN_CN) setenv.add-request-header = ("X-SSL_CLIENT_S_DN_CN" => ssl.SSL_CLIENT_S_DN_CN) setenv.add-request-header = ("X-SSL_CLIENT_S_DN_CN" => env.ssl.SSL_CLIENT_S_DN_CN)
but it always ended in either "Undefined env variable" or "Undefined config variable" and at first
I thought setenv.add-request-header was limited to static strings only, e.g.
setenv.add-request-header = ("X-SSL_CLIENT_S_DN_CN" => "foobar")
but noticed that I could use (a nonsensical I guess but working)
setenv.add-request-header = ("X-SSL_CLIENT_S_DN_CN" => ssl.ca-file)
which now makes me think setenv.add-request-header may only use variables it's aware of at
the server's startup (static string including), is that correct?
After reading http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs:ConfigurationOptions#SSL
I thought I could access those variables in setenv.add-request-header but maybe it isn't
currently possible?
If it isn't, can you please recommend any other way to achieve what I've described? Many thanks!
Here's my config file, I'm using Ubuntu 9.10 and
lighttpd/1.4.28 (ssl) - a light and fast webserver Build-Date: Sep 12 2010 14:36:50
# ################################################## server.modules = ("mod_proxy", "mod_setenv") server.document-root = "./" server.username = "dsuch" server.groupname = "dsuch" server.bind = "localhost" server.port = "18080" $SERVER["socket"] == "localhost:27443" { ssl.engine = "enable" ssl.use-sslv2 = "disable" ssl.verifyclient.exportcert = "enable" ssl.verifyclient.username = "enable" ssl.pemfile = "./server-pair.pem" proxy.server = ("" => (("host"=>"127.0.0.1", "port"=>17090))) ssl.verifyclient.activate = "enable" ssl.verifyclient.enforce = "enable" ssl.verifyclient.depth = 2 ssl.ca-file = "./cacert.pem" #setenv.add-request-header = ("X-SSL_CLIENT_S_DN_CN" => env.SSL_CLIENT_S_DN_CN) } # ##################################################
Replies (3)
RE: Accessing SSL client certificate's fields in setenv.add-request-header - Added by dsuch over 14 years ago
OK, having read the source code (configparser.y & configparser.c) I can see that the 'env.' variable is being read using the 'getenv' call from stdlib.h so it means that it's confined to what can be found when the server's starting, e.g.
setenv.add-request-header = ("X-SSL_CLIENT_S_DN_CN" => env.SSL_CLIENT_S_DN_CN) # won't work
but
setenv.add-request-header = ("X-HOME" => env.HOME) # works fine
In other words, it can't be used for accessing variables which only appear in the environment in runtime.
RE: Accessing SSL client certificate's fields in setenv.add-request-header - Added by KiBi almost 13 years ago
In case somebody else runs into this kind of needs, the attached patch does the trick.
Please note I only exported the variables a coworker asked for (there are some more), and that it really should be made configurable instead of hardcoding strings. It would be nice to have a clean patch submitted through the bug tracker, but I fear I have little time left to devote to that.
I've got this running on 1.4.28, and the patch applies cleanly on top of 1.4.31. For the latter, I've only checked “make && make check” with the patch applied, though.
Mraw,
KiBi.
RE: Accessing SSL client certificate's fields in setenv.add-request-header - Added by KiBi almost 13 years ago
KiBi wrote:
Please note I only exported the variables a coworker asked for (there are some more), and that it really should be made configurable instead of hardcoding strings. It would be nice to have a clean patch submitted through the bug tracker, but I fear I have little time left to devote to that.
Actually, I found some time to spend on it:
http://redmine.lighttpd.net/issues/2434
Mraw,
KiBi.