SSL with metuxmpm (was Re: Metuxmpm test failed)

-                                                 [email protected]
---------------------------------------------------------------------

> <snip>
>> The SSL handshake is done before any HTTP requests including the vhost's
>> name come through. Therefore multiple vhosts with different SSL
>> certificates are not possible.
> GRRMMPPF!
>
>> Possible workarounds could be i) wildcards in the Common Name of the
>> certificate (SF does this: "*.sourceforge.net"), ii) IPs as the Common
> This is suboptimal. Normally we dont have evryone in an own subdomain
> and we also want evryone has its own certificate.
>
> Hmm, another workaround would be having the processors accessible over
> different ports. How could we solve this ?

This is indeed a chicken and egg problem. Normal tcp/ip requests are not
made to hostnames, but to ip-adresses. The hostname is first availiable
after the ssl-decryption when we have the raw http.

I think the most common way to solve this is to have a different
ip-address for each vhost that have an ssl-certificate, of course a
different port will work, but the visitors would then have to specify the
port because it is non-standard, aka https://www.example.org:4430/ ,
wouldn't they?

Anyway, If I have understood the concepts right, we need a way for the
multiplexer to differensiate between ssl and non-ssl ip/ports. For ssl
ip/ports we could probably forward the connection right away to the right
ssl-processor, whereas we'll have to do the normal peeking in the
http-header in order to decide which non-ssl-processor that should serve
the request.

Would this lead us in the right direction?

All the best,
Christian