|
Artur Hefczyc opened 4 years ago
|
![]() |
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. |
![]() |
I have response from CN1:
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 |
|
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:
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:
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 |
|
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. |
Type |
Bug
|
Priority |
Normal
|
Assignee |
Library fails to connect with error message that certificate is incorrect. However, we know that we have a correct certificate on our server.