Martin, You missed something fundamental. See the following document for a brief description of the problem. http://jakarta.apache.org/tomcat/tomcat-4.1-doc/ssl-howto.html
For a more detailed description see: http://httpd.apache.org/docs-2.0/ssl/ssl_intro.html Short answer you can't. I have an idea about a work around using non-standard ports: Short version- No connectors on 443. Redirect or link from http page to https nonstandard port. Has anyone tried this or have it working???? Doug www.parsonstechnical.com ----- Original Message ----- From: "Martin Alley" <[EMAIL PROTECTED]> To: "'Tomcat Users List'" <[EMAIL PROTECTED]> Sent: Wednesday, March 31, 2004 8:39 AM Subject: RE: Multiple certificates for multiple virtual hosts (1:1) > Okay, I see that the address attribute of the connector element can be > used to retrict IP/port combinations. > > As I've only got 1 IP this doesn't really affect me. > > Either I've misunderstood something fundamental, or the configuration > capabilities are not optimal. > > Any one? > > Thanks > Martin > > -----Original Message----- > From: Martin Alley [mailto:[EMAIL PROTECTED] > Sent: 31 March 2004 12:10 > To: Tomcat Users List > Subject: Multiple certificates for multiple virtual hosts (1:1) > > Hi, > > I want to have different certificates for different virtual hosts on my > tomcat setup (embedded in JBoss). > I only have 1 IP address. I want to use the default ports (80 & 443) > for each virtual server. > > A certificate doesn't say anything about the IP address - only the > common name (ie the FQDN). It is perfectly possible to change the IP > address of the machine on which the cert is installed, and not have to > update the certificate. Just let DNS update round the world. The key > thing is to keep the private key that is paired with the public key > embedded in the cert (that's been signed by the CA) secured on the same > machine. > > > Tomcat: The Definitive Guide, has this to say about multiple server > certificates: > "Suppose you are an ISP with clients, several of whom want to have their > own certificate. Typically this would involve using Virtual Hosts (as > covered in Chapter 7). Simply add an SSL Factory element to the > appropriate client's Connector, giving the keystore file for that > specific client." > > I don't see how virtual hosts are associated directly with certificates. > From my reading, certificates are associated with keystore, which are > associated with connectors, which are globally shared by one engine. > > In other words it seems you can have different certs for different > *ports*, and you can use any of the virtual host names with any of the > ports declared, but you can't have the appropriate cert selected based > on the host name. This is a shame, because *that* is what has been > certified! > > So, suppose I have 2 pairs of HTTP connectors each with an SSL factory: > Http 80 with SSL 443 (cert common name www.company1.com) > Http 8080 with SSL 8443 (cert common name www.company2.com) > > And I have virtual hosts > www.company1.com and www.company2.com > > It seems to me the certificate I will get presented would depend on the > port number entered, and not the virtual host name. Thus there exists > potential for a name mismatch between the requested url, and the common > name in the certificate - which is a "bad thing". > https://www.company1.com works and gets the right cert > https://www.company1.com:8443 works, but gets a warning because of the > mismatched cert > > Tomcat 5 SSL howto states: > "In order to implement SSL, a web server must have an associated > Certificate for each external interface (IP address) that accepts secure > connections." > > Ignoring my assertions about the irrelevance of IP address above, I > don't understand how a specific IP address is associated with a specific > certificate in server.xml > > Can someone put me right on this? Or provide a example server.xml of > what I want to achieve? > > Thanks > Martin > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
