Daniel Mikusa wrote:
On Nov 28, 2012, at 11:56 AM, Will Nordmeyer wrote:

On Wed, Nov 28, 2012 at 9:03 AM, Will Nordmeyer <quark...@gmail.com> wrote:
On Wed, Nov 28, 2012 at 8:45 AM, Daniel Mikusa <dmik...@vmware.com> wrote:
On Nov 28, 2012, at 8:35 AM, Will Nordmeyer wrote:

On Tue, Nov 27, 2012 at 5:12 PM, Daniel Mikusa <dmik...@vmware.com> wrote:
On Nov 27, 2012, at 12:56 PM, Will Nordmeyer wrote:

On Tue, Nov 27, 2012 at 12:24 PM, Daniel Mikusa <dmik...@vmware.com> wrote:
On Nov 27, 2012, at 9:55 AM, Will Nordmeyer wrote:

Does that give you a clear(er) picture?  :)
Definitely.  A couple suggestions…

1.) You may want to take a look at org.apache.tomcat.util.net.jsse.JSSESocketFactory.  
Search for "crlFile" and you can see how this is being configured and utilized.

https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_36/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java

2.) Maybe try using Tomcat native and the APR connector.  This would offload 
SSL to openssl which may handle things more efficiently.

Dan

OK - I enabled Tomcat native & the APR, but now it doesn't prompt me
for the Client Certificate.

The log file has:

Nov 28, 2012 8:10:36 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting
property 'clientAuth' to 'true' did not find a matching property.
clientAuth only works for the BIO / NIO connectors.  I think you want 
"SSLVerifyClient" with the APR connector.

https://tomcat.apache.org/tomcat-7.0-doc/config/http.html#SSL_Support_-_APR/Native

Dan

OK... thanks.  That was purely me and literacy this morning.  I looked
RIGHT at that line and decided, nope...must not apply to me.  I
changed everything ELSE.
I've got the tomcat-native & APR configured, but when I add the SSL
Certificate Revocation options, it prompts me for my cert and then
gives a page cannot be displayed.

You might want to try and capture some traces with Wireshark.  This could give 
you some more insight into what is happening as the request is made.


You may also try with Firefox as a browser, with the HttpFox plugin.
I just ran a quick test with a HTTPS website, and it seems to show a good portion of the SSL exchanges. It will not be as telling, but is a lot easier to use than Wireshark.

One problem with IE is the "friendly error messages" option, which hides the real server responses and displays some built-in page instead, which tells you nothing really about the problem.



  <Connector port="8443"
              protocol="org.apache.coyote.http11.Http11AprProtocol"
              SSLEnabled="true"
              scheme="https"
              maxHttpHeaderSize="8192"
              maxThreads="150"
              minSpareThreads="25"
              maxSpareThreads="75"
              enableLookups="false"
              acceptCount="100"
              disableUploadTimeout="true"
              compression="on"
              compressableMimeType="text/html,text/xml,text/plain,text/css,text/
              
javascript,application/xml,application/x-javascript,application/javascript"
              connectionTimeout="20000"
              secure="true"
              SSLCertificateFile="/etc/ssl/certs/mycert01.crt"
              SSLCertificateKeyFile="/etc/ssl/certs/mykey01.pem"
              SSLPassword="dmapsdev"
              SSLCACertificateFile="/etc/ssl/certs/root-certs.pem"
              SSLVerifyClient="require"
              SSLCARevocationFile="/etc/ssl/certs/CRL-bundle.crl"
              sslProtocol="TLS"  />

Without the SSLCARevocationFile, it prompts for my certificate, gets
the PIN and goes to the app.

How can I test/trace the Revocation File issues.  The CRL-bundle.crl
file has 39 different X509 formatted CRLs, totaling 271 MB of data.

Couple thoughts…

1.) Check that your certificates and CRL file are all valid and functioning properly.  
I'm not an expert with openssl, but I think "openssl verify" can be used to 
test this from the command line.
2.) Perhaps start with a smaller CRL file or create a set of testing certs that 
you can use to verify behavior.

Dan


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to