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]

Reply via email to