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]