On 08/18/2011 09:44 AM, Ade Lee wrote:
Hmm, this is unfortunate. I was hoping that this would work.
The port you are using is fine. The first two lines of the debug log
indicate that the filters (which enforce that certain requests go
through certain ports) would have stopped this interaction right here -
had they not been disabled.
Whats happening is the following:
Typically, a user submits a certificate request after selecting a
profile on the end-entity pages. The EE pages are reached through the
non-client-auth SSL port. There are however, some profiles that require
a certificate for authentication. In this case, for example, we expect
the request to be accompanied by an agent's certificate so that the
certificate request is automatically processed.
At this point - and I'm fuzzy about exactly how - we initiate a
renegotiation of the connection and require a client certificate.
When talking to tomcat directly - this happens through tomcatjss/jss.
In this case, when going through the proxy - it appears the
renegotiation is not taking place - and no client cert is being sent.
I have a couple of ideas on how to get around this:
1. It may just be a httpd configuration issue. Change the dogtag.conf
file so that all stanzas contain the following line:
NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate
rather than just the agent one. Hopefully, this will just work.
No such luck. Oh well.
2. When I was trying to address the MITM issues, I ended up adding a
client-auth EE port - so that renegotiations would not take place (to
help non-updated clients).
You can get to that port by changing the URL to ..
'https://ipa-server-3.ayoung.boston.devel.redhat.com:443/ca/eeca/ca/profileSubmitSSLClient'
Note: eeca instead of ee.
Ade
Does this require a change to server.xml for it to work on my system? I
don't think I have the /ca/eeca/ca URL on my tomcate instance right now