On Dec 20, 2010, at 2:43 AM, Felix Frank wrote:
> Sorry for the late answer, my provider had a downtime this weekend.
>
>>> Tough call. There is no such thing as a "transparent SSL proxy" afaik,
>>> because without decrypting requests, the proxy cannot make any header
>>> based decisions.
>>>
>>> This may well be a dead end then.
>>
>> Ah. See below for a different idea then.
>>
>>> If such an approach is at all possible, the complete implementation
>>> would include giving the proxy the means to recognize valid client
>>> certificates.
>>
>> The proxy can and is recognizing valid certificates. The problem is passing
>> that information on to the puppetmaster because I really don't know how to
>> do that. I also don't know exactly which headers the puppetmaster uses.
>>
>> I'm thinking that if I do this, I need to remove the SSL from the file
>> server VirtualHost and just pass the information directly through.
>
> Hm, no good. This is just the "transparent SSL proxying I'm afraid is
> not at all possible (at least while still making use of the request URI
> to decide on the backend HTTP server).
>
>>> Even if this should work - is it work all that hassle?
>>
>> This is a much better question. I'm going to work on it a little more
>> though.
>
> The weird thing is: This might as well work, because you proxy pass to
> https://localhost...
> That means that your proxy actually reencrypts the requests (or should
> do that, at least).
>
> Are you seeing requests at the backend Apache now?
> Does puppet show any reaction to that?
>
> Are you performing basic tests using wget on distinct URLs that should
> be served by this setup?
Actually I've gotten a lot farther. At first, I spent a lot of time fumbling
around until I finally gave up because I didn't have enough information to
debug the problems. Here's what I did as a hack to give me more information:
Added this to config.ru:
# if you want debugging:
ARGV << "--debug"
# Log to a file in addition to syslog
ARGV << "--logdest" << "/var/log/puppet/puppetpassenger.log"
Added this to near the end of
/usr/lib/ruby/1.8/puppet/network/http/rack/rest.rb. Make sure you know where
to add this. Do not blindly add this at the end of the file:
if dn.nil?
dn="nil"
end
status = request.env[Puppet[:ssl_client_verify_header]]
if status.nil?
status = "nil"
end
Puppet.debug "Custom: client_name=\""+dn+"\" status=\""+status+"\""
#Print out all headers
request.env.each { |elem|
Puppet.debug "#{elem[1]}, #{elem[0]}"
}
After this I found out that apache was adding a prefix of "HTTP_" to the
beginning of all custom headers.
So, I was able to get the puppet client to connect if I added:
RequestHeader set SSL_CLIENT_S_DN "/CN=Simba.Outer"
RequestHeader set SSL_CLIENT_VERIFY "SUCCESS"
to the apache config and add:
ssl_client_header = HTTP_SSL_CLIENT_S_DN
ssl_client_verify_header = HTTP_SSL_CLIENT_VERIFY
to the "[master]" section of puppet.conf.
Obviously, this is not suitable in a production environment.
Now I'm trying to get the second apache instance to resend the header it
receives from the first instance. I haven't actually started on this yet.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
