Discussion:
request.getAttribute("javax.servlet.request.X509Certificate") returns NULL for AJP connector
John Palmer
2014-01-28 17:41:18 UTC
Permalink
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.

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

I suspect that I simply have something not configured properly - but is it
IIS 7.5, Bon Code, or Tomcat?

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

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


---------------------------------------------------------------------------------------
Christopher Schultz
2014-01-28 18:02:09 UTC
Permalink
John,
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).
/** 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>")
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
Konstantin Kolinko
2014-01-28 18:11:13 UTC
Permalink
Post by John Palmer
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
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.
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.
-----------------------------
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...
I suspect that I simply have something not configured properly - but is it
IIS 7.5, Bon Code, or Tomcat?
After multiple attempts to resolve this I'm at a loss..
your help appreciated...
-------------------------------------------------------------------------
<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)
I do not have a real answer, but if you have come this far, maybe you
want to try
running Tomcat under debugger? See

http://wiki.apache.org/tomcat/FAQ/Developing#Debugging

The above configuration of a <Connector> selects either a BIO or an
APR connector (depending on presence of tcnative-1.dll). Which
connector implementation is actually used should be visible from
startup logs.

A place of interest for a breakpoint is
org.apache.coyote.ajp.AbstractAjpProcessor#prepareRequest().
Look for 'case Constants.SC_A_SSL_CERT' there.

Another place is AbstractAjpProcessor#action(...), see
ActionCode.REQ_SSL_ATTRIBUTE there.

Best regards,
Konstantin Kolinko
John Palmer
2014-01-29 02:23:56 UTC
Permalink
Konstantin:
Thanks for the suggestion - I'll hang on to that link.
I was ready to try running Tomcat with a debugger... the instructions I
found were for using Eclipse (which I already had set up, but not with the
TomCat source)... but I was reluctant to deal with another steep learning
curve.

Logging EVERYTHING didn't show me anything useful - except perhaps to tell
me ( by its absence) that the problem is not in Tomcat.

However, (see the other response I'll have here shortly) - I think that
Christopher Schultz has hit the nail on the head.. as you''ll see in my
response to him....
Post by John Palmer
Post by John Palmer
request.getAttribute("javax.servlet.request.X509Certificate")
for several purposes.
These use tomcat behind IIS using the Jakarta connector (aka reverse
proxy)
Post by John Palmer
and have been running since 2006 and 2011 respectively without
significant
Post by John Palmer
issues ... other than perhaps insufficient memory (and sometimes IIS
can't
Post by John Palmer
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
Post by John Palmer
(and related SSL attributes in Tomcat) are now returning NULL in our DEV
environment
IIS 5.0 on WIndows Server 2003 SP2, Jakarta Isapi Redirector 1.2.37,
TomCat
Post by John Palmer
7.0.47
(While researching "how to set up Jakarta Isapi Redirector in IIS 7.5
with
Post by John Palmer
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
Post by John Palmer
cert, and cert info is being sent to IIS.
According to Bon Code logs, request headers are being populated with
plenty
Post by John Palmer
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
Post by John Palmer
I can't see why in the logs, even after turning the logs to ALL and
wading
Post by John Palmer
through the copious output.
After looking through the Tomcat source multiple times, I don't see how
the
Post by John Palmer
AJP connector can populate these request attributes at all - but it is in
our current (32-bit OS) environment.
-----------------------------
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...
I suspect that I simply have something not configured properly - but is
it
Post by John Palmer
IIS 7.5, Bon Code, or Tomcat?
After multiple attempts to resolve this I'm at a loss..
your help appreciated...
-------------------------------------------------------------------------
<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)
I do not have a real answer, but if you have come this far, maybe you
want to try
running Tomcat under debugger? See
http://wiki.apache.org/tomcat/FAQ/Developing#Debugging
The above configuration of a <Connector> selects either a BIO or an
APR connector (depending on presence of tcnative-1.dll). Which
connector implementation is actually used should be visible from
startup logs.
A place of interest for a breakpoint is
org.apache.coyote.ajp.AbstractAjpProcessor#prepareRequest().
Look for 'case Constants.SC_A_SSL_CERT' there.
Another place is AbstractAjpProcessor#action(...), see
ActionCode.REQ_SSL_ATTRIBUTE there.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
John Palmer
2014-01-29 02:39:21 UTC
Permalink
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.
Post by Christopher Schultz
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...
Post by Christopher Schultz
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 <
Post by Christopher Schultz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
John,
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).
/** 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>")
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-----
---------------------------------------------------------------------
Christopher Schultz
2014-01-29 15:15:26 UTC
Permalink
John,
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.
This can probably be solved using a custom Valve which converts those
HTTP headers into request attributes. Honestly, I was surprised
reading-through the Bon Code documentation that such a Valve does not
ship by default with Bon Code... it seems to be entirely necessary.
Post by Christopher Schultz
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...
Post by Christopher Schultz
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.
No problem. Bon Code is relatively new, and I honestly hope it
succeeds. I'm certain Bilal would be willing to investigate this and
either tell you what you've been missing, or fix Bon Code to work with
an out-of-the-box Tomcat configuration.

- -chris
Konstantin Kolinko
2014-01-29 18:33:21 UTC
Permalink
Post by Christopher Schultz
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.
This can probably be solved using a custom Valve which converts those
HTTP headers into request attributes. Honestly, I was surprised
reading-through the Bon Code documentation that such a Valve does not
ship by default with Bon Code... it seems to be entirely necessary.
There exists "SSLValve"
http://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/valves/SSLValve.html
Post by Christopher Schultz
From a quick look it may be what you are looking for.
It is not documented on the usual "config/valve.html" page. :/

Best regards,
Konstantin Kolinko

Loading...