*What steps will reproduce the problem?*
1. Configure a virtual host
2. Configure and generate separate SSL certificates for the 'global' configuration and the vhost configuration
3. Enable mod_websocket
4. Observe the certificate served by mod_websocket when connecting to the vhost
*What is the expected output? What do you see instead?*
The expected output is to be served the vhost-specific certificate, like happens for a regular XMPP connection. Instead, the 'global' certificate is served.
*What version of the product are you using? On what operating system?*
Prosody 0.9.4, Debian 7, installed from official repository
*Please provide any additional information below.*
Serving the global certificate rather than the vhost-specific certificate, will inevitably lead to common name mismatches on multi-vhost setups. This is a serious problem.
Hi, thanks for the report.
The underlying issue is that the websocket protocol does not support starttls like XMPP connections do. Therefore we do not know which certificate to serve before we start the SSL handshake. LuaSec does not support SNI, which was the solution that HTTPS uses for this issue.
I should note though that in the case of websockets, the websocket host that you connect to has zero effect on the XMPP hosts you can log into. E.g. you can create 'websocket.example.com', anything that has a valid cert, and use it to log into all your XMPP hosts.
In any case, SNI support is desirable. Work has begun on adding it to LuaSec, but when this will be released I cannot say.
LuaSec does have SNI support but I'm not sure if it's in a release yet.
I've got a working implementation for net.server_select
It changes various net.server methods by adding a 'sni' argument. Baking this into the existing context argument would have been nicer but how would you do this with a cdata?
We should settle what API we want for this, in net.server, portmanager