En l'instant précis du 27/02/07 15:25, Henderson,Nathan s'exprimait en ces termes: > We have 7 different clients, 14 databases(1 prod and 1 test for each > client), and 14 web sites for accessing information 1 for each live and > test. 1 Web Server running RHEL and tomcat 5.5.2 we also use 7 SSL > certs, on for each institution which has the live name in it, so test > will still be secure you just have to answer a prompt when visited or > install the cert. > Are those client certificates? (identifying client based on a client certificate residing next to internet explorer or firefox) Or are those server certificate (allowing SSL encryption of transmission + authentification of server, but client authentification is still done using a simple user + password method)?
Based on your answer, the interpretation of your main question is totally different :) I will go assuming you speak of server certificates as those are more frequently used than SSLClientAuth So you say you have a different 'entry' in server.xml for each 'servlet' ?! Do you mean different Connector, different Hosts or different Contexts? (A connector can contain several host which in turn can contain several context (webapplications) which each have several servlet) If what you need is to have https://client1.company.com/client1/ https://client1-test.company.com/client1-test/ https://client2.company.com/client2/ https://client2-test.company.com/client2-test/ ... and have client1 and 2 present different certificates but have client1 and client1-test present same certificate, i would recommand. connector 8080 (ssl=true) -> host client1 -> context client1 -> host client1-test -> context client1-test connector 8081 (ssl=true) -> host client2 -> context client2 -> host client2-test -> context client2-test In short, 1 connector per certificate. Why not a single connector for everything? Because, in HTTPS you have to present server certificate to client before client sends you the http header containing the name of virtual host he tries to access. So you only have 2 possibilities to find out which certificate to send to client, either use the server IP of connection (in your case, all the same, so useless information), either use the port number (8080 is certificate 1, 8081 is certificate 2, etc) Note, in another possible configuration: https://client1.company.com/client1/ https://client1.company.com/client1-test/ https://client2.company.com/client2/ https://client2.company.com/client2-test/ connector 8080 (ssl=true) -> host client1 -> context client1 -> context client1-test connector 8081 (ssl=true) -> host client2 -> context client2 -> context client2-test Not sure my information is helpfull, try to help you based on you informations :) Also, if you provide additionnal informations, try to use correct word (or provide us with you server.xml file to make discussion clear) > It has been set up as the Tomcat standalone, the only way our software > vendor will support it. And have set up each servlet as it's own > service in the server.xml. Is this how you guys would have done it. > This is the only way we could apply different certs to the different > servlets. > > This is probably everywhere on the net but, Is there a way to bounce > these services independently from the tomcat app itself? Also is it > possible to script the deployment and reload proccess? I can't seem to > figure that out. > > Not sure what you mean by 'bouncing services' Scripting deployement is possible using ant (see http://tomcat.apache.org/tomcat-5.5-doc/deployer-howto.html#Deploying%20using%20the%20Client%20Deployer%20Package). Also, if you are on a linux machine, you can use curl in scripts to POST the .war at /manager/html/upload to reload tomcat you can simply stop it and then start it using provided scripts in tomcat distribution. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
