Aha... This from http://ietf.org/rfc/rfc3546.txt
"3.1. Server Name Indication [TLS] does not provide a mechanism for a client to tell a server the name of the server it is contacting. It may be desirable for clients to provide this information to facilitate secure connections to servers that host multiple 'virtual' servers at a single underlying network address. In order to provide the server name, clients MAY include an extension of type "server_name" in the (extended) client hello. ... " This rfc is dated June 2003, so I wonder when it will become mainstream?? Martin -----Original Message----- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 31 March 2004 15:25 To: 'Tomcat Users List' Subject: RE: Multiple certificates for multiple virtual hosts (1:1) Hi Doug, I guess my point is that given there may be multiple certificates installed on a web server, and given that certificates authenticate Distinguished Name there should be an effective way to make sure the correct certificate is sent to the user. The certificate isn't just for viewing on the client when there is a name mismatch, or out of date of whatever - it can be used by SSL 3 supported RSA key exchange. Why should the user get the wrong certificate when the correct one is available??? I understand about SSL fitting between TCP/IP and HTTP in the protocol stack. I would expect the host name to transition as part of the SSL session initiation - given that the certificate authenticates the *name* and not the IP address!! It looks like this has already been considered by the gurus (not surprisingly :-) http://ietf.org/internet-drafts/draft-ietf-tls-emailaddr-00.txt I shall do a bit more research... Cheers Martin -----Original Message----- From: Parsons Technical Services [mailto:[EMAIL PROTECTED] Sent: 31 March 2004 14:55 To: Tomcat Users List Subject: Re: Multiple certificates for multiple virtual hosts (1:1) 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] --------------------------------------------------------------------- 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]
