No, the client cert from the browser is not sent to WAS, the plugin
extracts the DN from the cert and passes that as an HTTP header. It
really wouldn't make any sense to have end user certificates in the WAS
truststore anyway. It would be a huge maintenance issue and extremely
inflexible. SSL mutual authentication happens from IIS to WAS, and the
only signer cert that WAS needs in its truststore is the one for IIS.
Oliver Schoenhaar <oliver.s...@de.bosch.com> wrote in
news:781279901.1164812142...@ltsgwas010.sby.ibm.com:
It doesn't pass the actual certificate. By the time you get to WAS
you're not validating the client certificate (i.e you're not comparing
signers with trust stores), all you're doing is validating that the user
identified by the DN is in your registry. That's a totally different
operation and has nothing to do with PKI.
WAS 6.1 supports OCSP, but not for client certs passed via the plugin;
it supports it for certs validated by the WAS trust manager. So for
example if you have an SSL connection from your web server to your app
server, WAS can do CRL checking on the web server's client cert (which
has nothing to do with the client certs of any browsers that access WAS
via the webserver)