Chris:
Thanks for the response.
I think we can end this discussion - you have pretty much nailed it, I
think.
The great thing about having to pull together all the information I've
gathered over that last month to make this post, is that it lets me see
what I've been too close to see, in this case, that the differences are IIS
5 vs 7.5 and Jakarta vs Bon Code.
I took another look at the request headers returned by Jakarta (no certs,
no SSL info, only about 5 request headers) as opposed to that returned by
Bon Code (about 2 dozen request headers, most ignored by Tomcat), to
realize that the request headers probably weren't the information source
from Jakarta.
Re-reading the Tomcat Connector docs and pages for the 1,000th or so time,
the phrase
"SSL attributes of the client connection are passed via the AJP protocol"
jumped out at me, finally, as meaning that this wasn't sent by request
headers, but as ATTRIBUTES.
Sure enough, reading through the source (NOT my strong point) of the
"Jakarta Isapi Redirector 1.2.37" reveals that it IS putting the SSL info
into the request forwarded to the AJP connector (TomCat) as Attributes,
and by contrast, the Bon Code source is NOT.
I'll recommend/ask that Bilal look into this (I'm not prepared to attempt
this myself, yet)... I may be all wrong still...
and try to use the Jakarta for now, instead.
> If it turns out that Bon Code is the problem, I believe that Bilal
> lurks on the list. I've added "Bon Code" to the subject to get his
> attention.
Thanks - I meant to do that, and forgot...
> Why not try configuring mod_jk ISAPI redirector in your new
> environment to see if Bon Code is the problem?
I will...
Thanks for the encouragement, and making me feel that I'm not alone in this.
On Tue, Jan 28, 2014 at 12:02 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> John,
>
> On 1/28/14, 12:41 PM, John Palmer wrote:
> > We have two similar production environments which use:
> > request.getAttribute("javax.servlet.request.X509Certificate") for
> > several purposes.
> >
> > These use tomcat behind IIS using the Jakarta connector (aka
> > reverse proxy) and have been running since 2006 and 2011
> > respectively without significant issues ... other than perhaps
> > insufficient memory (and sometimes IIS can't talk to Tomcat and
> > everything has to be restarted, multiple times, to resolve).
> >
> > We're trying to upgrade/replace these servers with 64-bit Windows
> > OS due to memory constraints caused by the use of 32-bit OS, and
> > these attributes (and related SSL attributes in Tomcat) are now
> > returning NULL in our DEV environment
> >
> > Old environment: IIS 5.0 on WIndows Server 2003 SP2, Jakarta Isapi
> > Redirector 1.2.37, TomCat 7.0.47
> >
> > (While researching "how to set up Jakarta Isapi Redirector in IIS
> > 7.5 with a 64-bit Windows 2008" I saw multiple people reporting
> > issues with poor performance, lockups etc, and decided we would try
> > Bon Code instead.)
> >
> > New Environment IIS 7.5 on Win Server 2008 R2, Bon Code 1.0.17,
> > TomCat 7.0.47
> >
> >
> > IIS is configured with Client Cert Required; browser is being
> > prompted for cert, and cert info is being sent to IIS.
>
> So, the "old" production setup uses mod_jk ISAPI redirector and it
> works. The "new" production setup uses Bon Code and doesn't work. I
> may have a suggestion as to the difference between setups, and a
> possible reason why this isn't working.
>
> > According to Bon Code logs, request headers are being populated
> > with plenty of information, including client cert and client issuer
> > cert information.
> >
> > It looks like Tomcat is receiving these request headers, but is
> > not populating the request attributes related to SSL and Cert
> > information, but I can't see why in the logs, even after turning
> > the logs to ALL and wading through the copious output.
> >
> > After looking through the Tomcat source multiple times, I don't see
> > how the AJP connector can populate these request attributes at all
> > - but it is in our current (32-bit OS) environment.
>
> It looks like it happens in AbstractAjpProcessor.action().
>
> > ----------------------------- I understand that Tomcat is NOT doing
> > the SSL connection itself - IIS is, just as Apache Web Server can
> > be made to do, but my understanding is that Tomcat should be able
> > to populate these attributes from information sent with the request
> > throught the AJP connector (eg, in the Request Headers), That seems
> > to be working wonderfully in our current environment.
>
> mod_jk does not use HTTP headers to send SSL information. Those data
> are sent using a different mechanism. Bon Code should be using the
> same mechanism.
>
> > I suspect that I simply have something not configured properly -
> > but is it IIS 7.5, Bon Code, or Tomcat?
>
> Why not try configuring mod_jk ISAPI redirector in your new
> environment to see if Bon Code is the problem?
>
> >
> > After multiple attempts to resolve this I'm at a loss.. your help
> > appreciated...
> > -------------------------------------------------------------------------
> >
> > Tomcat Server.xml (AJP connector): <Connector
> > URIEncoding="*UTF-8*" enableLookups=" *false*" port="*8029*"
> > protocol="*AJP/1.3*" redirectPort="*8443*" /> (added
> > tomcatAuthentication=" *false*", scheme="https" secure="true"
> > without making any difference)
> >
> > Bon Code config: <Settings> <Server>localhost</Server>
> > <Port>8029</Port> <EnableRemoteAdmin>False</EnableRemoteAdmin>
> > <EnableHeaderDataSupport>True</EnableHeaderDataSupport>
> > <ForceSecureSession>False</ForceSecureSession>
> > <AllowEmptyHeaders>False</AllowEmptyHeaders>
> > <LogLevel>4</LogLevel> <LogDir>c:\temp</LogDir> </Settings>
> >
> > (Added <ForceSecureSession>True</ForceSecureSession> -- this caused
> > SSL session ID: *getAttribute(javax.servlet.request.ssl_session)
> > *to populate. No other difference).
> >
> > ----------------------- code in jsp file to show these attributes:
> >
> >
> > /** prints the request headers being passed in.... */ out.println
> > ("<br><br>Request Headers: <br>"); Enumeration<String> headerNames
> > = request.getHeaderNames(); while (headerNames.hasMoreElements())
> > { String headerName = headerNames.nextElement(); String headerValue
> > = request.getHeader(headerName); out.println(headerName + " = " +
> > headerValue + "<br>"); }
> >
> > /** returns plenty of stuff for Bon Code, very little for Jakarta
> > */
>
> http://boncode.net/connector/webdocs/Tomcat_Connector.htm#_Toc349117783
>
> > */** *not** reported by request.getAttributeNames() ! */
> >
> > out.println("<br><br>SSL Attributes: <br>");
> >
> > out.println("javax.servlet.request.cipher_suite: " +
> > request.getAttribute("javax.servlet.request.cipher_suite") +
> > "<BR>"); out.println("javax.servlet.request.key_size: " +
> > request.getAttribute("javax.servlet.request.key_size") + "<BR>");
> > out.println("javax.servlet.request.X509Certificate: " +
> > request.getAttribute("javax.servlet.request.X509Certificate") +
> > "<BR>"); out.println("javax.servlet.request.ssl_session: " +
> > request.getAttribute("javax.servlet.request.ssl_session") +
> > "<BR>"); out.println("SSL_PROTOCOL: " +
> > request.getAttribute("SSL_PROTOCOL") + "<BR>")
> > ----------------------- result:
> >
> > SSL Attributes: javax.servlet.request.cipher_suite: null
> > javax.servlet.request.key_size: 2048
> > javax.servlet.request.X509Certificate: null
> > javax.servlet.request.ssl_session: on SSL_PROTOCOL: null
> >
>
> If it turns out that Bon Code is the problem, I believe that Bilal
> lurks on the list. I've added "Bon Code" to the subject to get his
> attention.
>
> I think you need to take some time to determine which component is
> causing the problem by making smaller changes to your deployment and
> re-testing. I would start by rolling-back to mod_jk ISAPI redirector
> to see if that makes things work. If it still does not work, try
> rolling-back to IIS 5. Everything else seems to be the same and/or
> compatible.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJS5/CeAAoJEBzwKT+lPKRY4CoQAKdwmDkROUZ8HNp5FA3U5uHd
> GIMzAGhmtM5dMYAWsH0E386jJAmXaD0oz0+Hk2xpfjrh/UxSOwBEk5ZRfMV3IN5e
> lp1go3IZoJTy9YL7b5q6jQdlb89zN13ewq3w1XEox4urNEG10glNINt92ZwEy89P
> Hiaw07/E+HI4Em7hGhkfp0ew5NOdXT9pKayYTYpuiNU8kIBkjJtCm8THh0zLy7qN
> fT7W+8QZPdVuYXbZEWYZ452sDdBq5Ns1V18ef+GVoYfds+m6ESJjNGLK4K6a8t78
> mv/zn4QiCLj/8r4RyeoaDk3sprQwAAJeYG0XPDTKN77ZHHfUlO1U8EsQMe9k9jSd
> 13wiBp/DLoeZoqZKGxLnuuEQmC8nPfOJENx/wFrEzk7LUWzhgNp9BU+Xbd1qGYbD
> EtUURC701wFS9PR60G45XUQe5CHiOA+taP7mV4J1eFdk0wpRvPkTmUO5NJukgQpR
> OOSshtLUPSj2cuhmuqAm0Eb02zCWsJt6YqoTGD89tymmiCtakr7F8sFBcun6kg2r
> GIeweLjgg3D+3PT1JrMqNhH4iymai9wdvckyAjucHjzeGq2RyLmhR7E02cFbvLo2
> JS/Ft9HawMobVRPPRhAS6uBvvU4aB4J4X+LAXlBvi7RHdLhKHEbrDv+q+KZB/+aP
> 2NJ48dH9U25QDsoEFjkn
> =wfJ8
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
