As mentioned in Tip #1 WebSocket endpoint is plain TLS/SSL port, so it always serves default certificate for Tigase XMPP Server instance. It is ok, if we are hosting single domain and if default certificate matches matches our domain. But If we host multiple domain we cannot use wss://example1.com:5291/ connection URI, if our default certificate is for domain example2.com. In this situation it is recomended use default certificate for domain under which server is accessible from internet. This domain should identify this server, so this domain would not point i.e. on two nodes of a cluster. After we deploy separate certificate for each of cluster nodes, we should follow same tip as Tip #1 for BOSH. Our web-based XMPP client should have knowledge about each node of a cluster and when it needs to connect it should randomly select one node from list of available cluster nodes and try to connect to is using connection URL that would contain name of server under which it can be identified from internet.
Example:
We have servers t1.example1.com and t2.example1.com which are nodes of a cluster hosting domain example2.com. Each of our nodes contains default SSL certificate which domain matches name of cluster node. Web client retrieves list of cluster nodes from web server and then when it needs to connect to XMPP server it picks random host from list of retrieved cluster nodes (i.e. t2.example1.com) and tries to connect using WebSocket encrypted protocol to host t2.example1.com using following connections URL wss://t2.example1.com:5291/. During connection client should still send example2.com as name of server to which it tries to connect (example2.com should be value of to attribute of XMPP stream. This will allow browser to validate certificate as it will be for the same domain to which browser connects, and it will allow XMPP client to connect to domain example2.com, which is one of hosted vhosts.
