-----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
