Ben Laurie wrote:
> If they share an IP address (which they must, otherwise there's no
> problem), then they must share a webserver, which means they can share a
> cert, surely?

this is a semantic nit ... certs are typically distributed openly and
freely ... so potentially everybody in the world has free access to the
same cert.

what operations need is the same access to a high-assurance private key.
given that there is access to a high-assurance private key ... then it
is possible to scaffold various other operations. some of the issues
surrounding private key high-assurance may preclude having replicated
private keys, restricting use to a single physical entity.

over ten years ago ... i helped a small isp set up a single server to
host a larger number of different email domains ... which required doing
several hacks/enhancements to sendmail.

the early onset of some of the leading search engines started out with
multiple-A records for load balancing and availability (i.e. dns having
single host/domain name with a list of different ip-addresses) ... where
they rotated the ip-addresses in the list. as their traffic ramped up,
this wasn't sufficient ... in part because the ip-address lists got
cached in a large number of different places ... as static lists. this
resulted in the evolution of boundary routers that responded to the set
of published ip-addresses and internally kept track of activity to
backend servers ... and dynamically spread the load across an
increasing/growing number of backends.

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to