No idea, but for now, ...

1 name --> 1 certificate --> 1 (TCP port, IP address) pair.

You can't do any better with any implementation I know of.

Yours,


Antonio Fiol


Martin Alley wrote:

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







Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to