Steve Leach wrote: > > Owen, > > I just followed this thread - thanks for that condensed 'how it works' for > certificates - I picked up two things I did not know, and as they say > knowledge is power :) > > I am wondering at the last statement as to whether the limitation lies in > the ability to produce a certificate that could verify all hosted domains, > or whether Apache (or indeed any HTTPS server) could work with such a > beast?
As I understand it, the trouble is that there are two aspects to SSL: encryption and authentication. If it was only about encryption, you wouldn't have to tie your certificates to the different sites - so you could just serve up a general server-certificate which would contain your public key (which is, after all, just a big long number). The client would use this to send you a session-key and you'd have established the secure channel. Then you could exchange the HTTPS packets in confidence and use the "Host:" fields therein to select virtualhosts. Indeed, this is what happens when people naively set up NBVHs on port 443 - the server just uses the certificate from the first VH for any request it receives. However, we've forgotten about authentication. If you really want a secure connection, it is no use just encrypting the datastream; you have to be sure that the packets are really going to the destination you want. If you send your credit card details to www.amazon.com how can you be sure that the server at the other end really does belong to Amazon Books Inc. and is not a fake server with a copy of their site and that some crook has not hijacked a router somewhere along the way? The answer is that when you get the cert from amazon.com it contains not only the public key but also their site name. Their cert has also been signed by Verisign or somesuch and so can be verified. Now you can't just make a self-signed cert which says you're amazon.com because "the browser does not recognise the authority which signed this certificate". Really, these "problems" are all client-side. The server is only interested in setting up a secure channel so will use any cert that seems appropriate. The trouble only starts when the browser starts checking out the cert and finds that it can't verify it because the signing authority is unknown or that it looks fishy because the site-name on the request doesn't match the site-name in the cert. This is really just the browser manufacturers protecting you from being conned and themselves from being sued. Rgds, Owen Boyle. ______________________________________________________________________ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]