When using the auth service, the returning json contains the IP address of the LoadBalancer service of the Stunner gateway (sometimes the LoadBalancer address is a cloud provider specific hostname, but this problem occurs nevertheless).
E.g. curl <auth service address:port>/ice?service=turn results in the following json:
{"iceServers":[{"credential":"xxx","urls":["turn:149.102.144.152:3478?transport=udp","turn:149.102.144.152:3478?transport=tcp","turns:149.102.144.152:5349?transport=tcp","turns:149.102.144.152:5349?transport=udp"],"username":"yyy"}],"iceTransportPolicy":"all"}
In this case the normal turn endpoins work just as fine, but the secure turns endpoints will result in an invalid certification error, since the client will use the IP address as the SNI field for which the TLS cert is not valid. We need to return a valid hostname for turns listeners which is the same as the Common Name (CN) filed of the TLS cert which Stunner uses for the secure listeners.
There are two alternative solutions in my mind:
1: use an ENV variable to config the turns hostnames, and the Auth Service would just use this insted of the raw IP addresses (this is a quick and easy solution, but the users would need to manually add the hostname)
2: the Auth Service could read the same secrets as Stunner uses for the secure listeners, extract the CN and use that in the answer (this would be automatic for users, but might result in errors: e.g. the cert has a wildcard domain, and we don't know which subdomain routes to Stunner)
When using the auth service, the returning
jsoncontains the IP address of theLoadBalancerservice of the Stunner gateway (sometimes theLoadBalanceraddress is a cloud provider specific hostname, but this problem occurs nevertheless).E.g.
curl <auth service address:port>/ice?service=turnresults in the followingjson:In this case the normal
turnendpoins work just as fine, but the secureturnsendpoints will result in an invalid certification error, since the client will use the IP address as the SNI field for which the TLS cert is not valid. We need to return a valid hostname forturnslisteners which is the same as theCommon Name (CN)filed of the TLS cert which Stunner uses for the secure listeners.There are two alternative solutions in my mind:
1: use an
ENVvariable to config theturnshostnames, and the Auth Service would just use this insted of the raw IP addresses (this is a quick and easy solution, but the users would need to manually add the hostname)2: the Auth Service could read the same secrets as Stunner uses for the secure listeners, extract the
CNand use that in the answer (this would be automatic for users, but might result in errors: e.g. the cert has a wildcard domain, and we don't know which subdomain routes to Stunner)