"Jack" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Server certificate: > > The certificate for the engine with alias "tomcat" > > The certificate for a specific host > > The certificate for a specific web-app > > > > If a web-app doesn't have a certificate, it can be configured to use the > certificate of the host. Similarly, if a host doesn't have a certificate, > it can be configured to use the certificate of the engine. However, when a > web-app has a certificate, then this one should be used rather than always > using "tomcat". >
Pretty much a pipe-dream, since the SSL protocol requires that the server send it's cert before it even knows the Host, much less the webapp :). There is pretty much no other place it can go other than with the Connector. > > > clientAuth of https connector is not relevant, at this level (engine), ask > for a client's certificate, what is it for? It should be like this: If the > client is requesting a server resource that requires client > authentication, the server requests the client's certificate. If we don't > ask for certificate, then truststore config is irrelevant. "clientAuth" > should be a property of a web-app. Since web.xml doesn't specify it, it > can be include into the web-app context, context.xml. > > The 'clientAuth' on the Connector is a sledgehammer that some people find useful in a limited number of cases. <auth-method>CLIENT-CERT</auth-method> in your web.xml does pretty much what you want. JSSE (which is what actually handles the SSL protocol stuff) wants to validate the client-cert up to a trusted root CA, so it needs the union of the webapp's root CAs in its truststore to function. You can always use a Filter to check that the cert is signed by the correct CA for the webapp. > > At the host level, we have the same question, too. > > > > At the web-app level, it is reasonable. This web-app asks for a client > certificate. And the UserManager will consult the usercontext of this > web-app for keystore & truststore information. > > > > At present, what component does the verification of a client's > certificate? The connector/sslsupport should call the UserManager to do > so. > > There are parts to this. JSSE verifies that the certificate is valid (e.g. not expired), and that the chain can be traced to a trusted root CA. If this fails, none of the Tomcat code gets a chance to intervene: The connection is simply closed. Later your configured Realm attempt to map the cert to an actual user, and resolves the roles. However, currently all of the Realms that ship with Tomcat only work on the actual client-cert subject (so a cert signed by trusted CA1 is the same as a cert signed by trusted CA2). You would need your own custom Realm if you needed to differentiate certs based on the signer chain. > > Here, I don't know the reason why many people say the design of SSL > doesn't allow several domain name based certificates on the single IP. Not strictly true, but practically no browser supports the protocol extension that allows this, so it's currently not worth the effort of trying to support it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
