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. 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] > -- Chad La Joie 315Q St. Mary's Hall Project Sentinel 202.687.0124 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
