Re: request.getAttribute(javax.servlet.request.X509Certificate) returns NULL for AJP connector (possible Bon Code issue?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 John, On 1/28/14, 9:39 PM, John Palmer wrote: 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. 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. 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS6RsOAAoJEBzwKT+lPKRYfVEP/2lZzfQO/fZr/9c7nmybBaEI dqTVWYN1cUU+bl7mfRrLBRqsd8KGtMzYEd7G8PRuPQjMo/W7y1sJy0u5qjY2GGx5 ncQ5Zy7zV9gnF7AalnGctmFZ1B6M/ER4bWRSY4/JmX+WYU26pNmREQY0AgYfPO/W hr4brQM5x7Tvtddb17PQXLG4DyxpHZbvkHpsstShy9Syop/V0RIrJiKfMwWaWUBP dPbjfaFWVYPQ4Bn54cPg2IaPu5hF+39UICpMDhX+KseqfnlTXy/509h9EJMIxNc4 fvWG6ITT5/AX/EtIXzPmqJ55ALJCK7xPrzdyGrK6f0VO3/E+gGTeEFWh4S0c3kXW wYodt335eqzo39YRPBtrnUTw0qDUtQSo8neX+0YzXrnprz33cW0xRF76xR963W6f 8LFOWsrpcr35tC708tkwqBJbbEEJF7tYWHHtLOvwuju1WyCqOL3FzfrQ9eeZbf29 lww4XJMoiuBHi4MxJIC/mUIv3ayDg6y0/bTQP9kYsxaZbIm0qspUJBlMnZ7ZVWIF tw9tToAFCmyF4dJWJuRKgsgO4/yVr0EX2YTGmqhN++ckf/TcKUmOU2QbtYFY7FxO kIu1IxB/mWz4xiCC42QhCFDdIdXTX+igQtHYsFSodzd1KGLVAKjuG9nTwWAptdSJ yvz/QrZg67SPLBdueZDZ =nTlu -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: request.getAttribute(javax.servlet.request.X509Certificate) returns NULL for AJP connector (possible Bon Code issue?)
2014-01-29 Christopher Schultz ch...@christopherschultz.net: On 1/28/14, 9:39 PM, John Palmer wrote: 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 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
request.getAttribute(javax.servlet.request.X509Certificate) returns NULL for AJP connector
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
Serverlocalhost/Server
Port8029/Port
EnableRemoteAdminFalse/EnableRemoteAdmin
EnableHeaderDataSupportTrue/EnableHeaderDataSupport
ForceSecureSessionFalse/ForceSecureSession
AllowEmptyHeadersFalse/AllowEmptyHeaders
LogLevel4/LogLevel
LogDirc:\temp/LogDir
/Settings
(Added ForceSecureSessionTrue/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 (brbrRequest Headers: br);
EnumerationString 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(brbrSSL 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
---
Re: request.getAttribute(javax.servlet.request.X509Certificate) returns NULL for AJP connector (possible Bon Code issue?)
-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 Serverlocalhost/Server
Port8029/Port EnableRemoteAdminFalse/EnableRemoteAdmin
EnableHeaderDataSupportTrue/EnableHeaderDataSupport
ForceSecureSessionFalse/ForceSecureSession
AllowEmptyHeadersFalse/AllowEmptyHeaders
LogLevel4/LogLevel LogDirc:\temp/LogDir /Settings
(Added ForceSecureSessionTrue/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
(brbrRequest Headers: br); EnumerationString 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(brbrSSL 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) +
Re: request.getAttribute(javax.servlet.request.X509Certificate) returns NULL for AJP connector (possible Bon Code issue?)
2014-01-28 John Palmer johnpalm...@gmail.com: 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) 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: request.getAttribute(javax.servlet.request.X509Certificate) returns NULL for AJP connector (possible Bon Code issue?)
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 On Tue, Jan 28, 2014 at 12:11 PM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2014-01-28 John Palmer johnpalm...@gmail.com: 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) 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: request.getAttribute(javax.servlet.request.X509Certificate) returns NULL for AJP connector (possible Bon Code issue?)
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...
