I have an apache2 web server delivering static content and front ending tomcat which delivers dynamic content. It can do this because all static URLs are of a defined form (eg location/*.css or location/*.jpg), and I use JKMount and JKUnmount directives to separate out the content types. I currently use basic authentication soley on apache to limit access to my family to one of the dynamic applications - based on the use of <location> directives. Tomcat does not get involved in any of the security management. I am planning the introduction of a private application (financial management) which I want to put stronger access controls into by limiting access to users (ie only me) who have a certificate directly signed by my ca (which is also me). This will of course run over https as the data returned is also sensitive. (at least on the external web site - I have an intranet within the home where I could use ordinary http - dependent on the answers to the questions below) It seems to me, that I could also minimally improve security on my family only application, by requiring my family also to have (different) certificates also signed by me. But that they would not need https access to the applications I am confused by the manual as to exactly what protocols, and exactly what ports are used to a) verify the client intially when an SSLVerifyClient is within a <location> directive b) whether the ongoing communication once the client is verified uses which protocol and which port. The reason I need to know, is that I currently map port 443 to a completely different space, mapping over an internal virtual host to support webmail. Can someone give me a clear summary of this? -- Alan Chandler http://www.chandlerfamily.org.uk Open Source. It's the difference between trust and antitrust. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|