Chad La Joie wrote:
Yeah, I know what mod-ssl says, and for most cases it's probably right,
however the optional_no_ca option is interesting to us because it
provides exactly the functionality that we need; accepting the client
cert, putting it in a standard place, and allowing our application to do
the verification for us.
As you said, PKCS12 wouldn't help us. The problem isn't that the Java
keystore is some how flawed. It's that that's just not a viable
mechanism for us. Our certificates are communicated in SAML2 metadata
files. These files change periodically (when new service or identity
providers come online or old ones go offline). We had discussed a
process whereby we'd extract the certs from the file and create a
keystore but that has and unacceptable drawback, in our opinion. With
the SAML2 metadata files we can get fresh copies of those files and use
them immediately in a running system. With the keystore mechanism
Tomcat would need to be restarted because the keystore, or at least part
of it, is cached in memory and as far as I can tell, the cache is never
refreshed. Given the indeterminate frequency for metadata updates, we
do not see this as a viable solution for a production level system.
I am not sure I got it right...
If you have clients that use client certificates you only need to get them
signed by a CA that is known by Tomcat or do you want to change the server
certificate Tomcat is using?
jean-frederic clere wrote:
Chad La Joie wrote:
Hey guys,
I was wondering if there were any thoughts on this particular
suggestion. I hadn't seen anything on the list.
BTW: mod-ssl says:
+++
In practice only levels none and require are really interesting, because
level optional doesn't work with all browsers and level optional_no_ca
is actually against the idea of authentication (but can be used to
establish SSL test pages, etc.)
+++
And keystoreType= "PKCS12" doesn't help.
Chad La Joie wrote:
Good Morning,
I work on the Internet2 Shibboleth project and we've run in to an
issue with client cert authentication in a stand alone Tomcat
environment (i.e. without Apache HTTPD in front of it). Shibboleth
clients use client cert auth when talking with the Shibboleth server,
however, the certificate chains for the clients are not in a Java
keystore. Instead they are in XML files that contain a large amount of
metadata needed by both the client and the server.
Our current, supported, deployment configuration is to have Apache
HTTPD in front of Tomcat and to use "SSLVerifyClient optional_no_ca"
HTTPD directive. This allows the client to send its certificate, but
instead of HTTPD trying to validate the cert, it just passes the cert on
to the Shibboleth server. This allows us to validate the certificate
against the cert chains in the metadata files within the server code (a
huge support boon for us). What we'd like to request is a similar
option for the SSL connector when client cert auth is used so that we
can support a stand alone Tomcat set up too.
Would this be possible?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
