Unfortunately I can't check certificates in library code. This is done by CN1 runtime and it is hidden from developer. I have to ask their support if there is a way to add custom CA to application (if it help in this exactly problem).

Explanation of this is similar to application working in browser: your JS code cannot accept or decline server certificate, it is done by browser.

I see that certificate served in WSS connection doesn't match hostname. This is first problem. Second question is if "Amazon Root CA" is trusted in CN1 runtime.

Zrzut ekranu 2020-12-10 o 10.10.16.png

I have response from CN1:

It uses the OS native list of certificate authorities. We don't keep our own keystore.

So in this case problem is certificate issued for different name.

So, how do we solve this? I understand that if we use TLS then a correct certificate is provided by the server. In case of SSL (WSS?, HTTPS?) a default certificate is provided by the server. But we still need to connect to the server. This might be a common case for Kangaroo systems, especially for the shared installation.

Yes: WSS is like HTTPS in this case. Only default certificate is allowed.

I think we should make WSS connection to wss://tigase.cloud and start SASL with JID …@tigase.org. Means: we should provide separate hostname, not only domain name from JID. @andrzej.wojcik, what do you think?

Can we "discover" somehow the correct hostname to use? Asking a user to provide both the JID and hostname is not possible. Besides, in most cases user would not know the hostname.

There are a few things here:

1. Domain from the WSS URI needs to match XMPP domain used in JID
2. That domain needs to have certificate deployed on the Tigase XMPP Server
3. Halcyon needs to connect to Tigase XMPP Server

Points 1 & 2 are OK. But we have an issue with point 3. For some reason WSS on point 5291 is terminated on AWS ELB as a HTTPS endpoint and then forwarded unencrypted on port 5290 of the server.

I suppose that this is done this way as on tigase.org we have our web pages (HTTP/S traffic) and WS/S traffic as well. As web browsers are dummy, they are using always A/AAAA records, so a single DNS name needs to point to a IP (or set of IPs). Due to that and the fact that the same ELB cannot be used as Application ELB and Network ELB (same IPs hosting both LB) we have deployed WSS on the Application ELB and that terminates SSL on the LB instead of the Tigase XMPP Server installation which would serve proper SSL certificate.

There are 2 solutions I can see here:

1. On the Application ELB which we are using deploy tigase.org SSL certificate
2. Change Application ELB to Network ELB (but there are some penalties as it counts traffic differently if I recall correctly).

Screenshot of the ELB about which I'm talking:

Ok, understand, which solution do you recommend @andrzej.wojcik?

If someone would like to use Kangaroo in the similar way (WWW and XMPP hosted on the same domain) then we have in the endpoints specification which I've created for master host host attribute which could be used to "point" Convene to the domain name which should be used as domain for the WSS connection.

I would suggest (in our case) to add tigase.org certificate to WSS ELB endpoint and that would just "fix" the issue which we have right now.

Can we use AWS's certificates for that, with automatic renewal?

I guess, this should also be done for our Kangaroo systems? Both shared and dedicated? @wojtek please take a note about this.

Yes, that is what I was suggesting. Just reconfigure tigase-prod-websites HTTPS:5291 listener to use also tigase.org certificate. I think we have one already.

Can you do this? I am not sure if Wojciech is already available.

He is on vacation until today.

It should work now.

Potwierdzam, przetestowane i dziala, dzieki.