You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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)
The text was updated successfully, but these errors were encountered:
When using the auth service, the returning
json
contains the IP address of theLoadBalancer
service of the Stunner gateway (sometimes theLoadBalancer
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 followingjson
:In this case the normal
turn
endpoins work just as fine, but the secureturns
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 forturns
listeners 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
ENV
variable to config theturns
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)The text was updated successfully, but these errors were encountered: