> > This generates most of the problems, due to the simplistic
> > last-century idea baked into HTTPS, that the server should know the
> > name the client will talk to it as, and present a certificate for that
> > name in the SSL handshake. It breaks because, for example, the client
> > can say "foo", and it gets expanded to "foo.parc.com" implicitly, or
> > the server can have multiple names for the same IP address.
>
> Could you please explain why you couldn't use wildcard certificates or
> multiple hostnames in subject alt name, which are standard solutions to
> the problem you presented above?
Good ideas, both, but both have problems.
Let's take multiple hostnames first. The sad fact is that, from a
host, there's no way to automatically enumerate the set of names a
client on a different host may use to connect to it. So there's no
good way to include all the right names in a single cert. In limited
environments without DHCP, this may be possible, though.
Wildcard certs (which basically say, I'm some server at this domain or
subdomain) are OK for browsers, but not for other clients which are
looking for more specificity in the server-side cert.
I think the best solution is dynamic DNS, so that the server can
control what name it's known by.
Bill
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
