ThinLinc Web Access is served by the service
default TCP port number for this HTTP service is 300. It can be changed
to some other port such as 443, assuming this port is free. The
configured port must be allowed in any firewalls.
In a cluster setup, the
tlwebaccess service must run on all
machines. The same service port should be used, and all machines must be
accessible from the clients.
/webaccess/login_page will also need to be
configured in a cluster setup. The client first authenticates with the
master. Once the master server has chosen an agent server for the
session, the client will authenticate with that agent server. The
browser will thus present pages from two different servers. First a page
from the master, and then from the agent, unless the agent is on the
same server of course. This parameter is a means for the agent to know
the public hostname of the master server. Thus when it’s properly set,
the user can, when the session has ended, click a button to return from
the agent to the master to login again. The default value, which is
/, will not redirect to another server and is only usable if you are
unning a stand alone ThinLinc server, i.e. not a cluster. If you have
more than one server or are using Network Address Translation (NAT), you
must set this parameter to an address that all clients can connect to.
login_page = https://thinlinc-master.example.com:300/
Please see Parameters in /webaccess/ for details on all possible settings for ThinLinc Web Access.
For best security and user experience, we strongly recommend that you
use valid TLS certificates. The certificates should match the server
host names. For correct behavior, you should set the parameter
/vsmagent/agent_hostname on each of the agents in the
If you can’t obtain a valid TLS certificate but still want to test
ThinLinc Web Access you can use a self-signed certificate. Such a
certificate, created for
localhost, is bundled with Web Access. Any
use of self-signed certificates is insecure and most browsers will
display warnings when they are used. Self signed certificates must be
In Safari, the certificates must match the server hostname, while other browsers might be content with a warning. Firstly, this means that you cannot connect through an IP address. Secondly, you can not use the bundled self-signed certificate. You can create a new self-signed certificate using our shipped helper script make-dummy-cert. OpenSSL is required to be installed for this script. Use it like this:
$ sudo /opt/thinlinc/etc/tlwebaccess/make-dummy-cert `hostname --fqdn`
Manually approving the self-signed certificate requires some additional steps in Safari compared to other browsers. On macOS the user must expand the browser dialog that complains about the certificate and choose to always accept that certificate. If the user already dismissed that dialog, then Safari has to be restarted. A self signed certificate must be manually approved for all machines in a cluster.
If you must test a browser on iOS with a self-signed certificate you have to add the certificate as a trusted certificate authority on the iOS device. Download the certificate on the device and install it in Certificate Trust Settings which can be found at the bottom of the page. See Apple’s instructions here. After using Safari to install the certificate, you can use Web Access in any browser on iOS.. Then you also have to enable the full trust of that root certificate in the
The above steps for iOS are very insecure and are not recommended for production systems. iOS does not have a mechanism for ignoring bad certificates for a single site. This means that following the method above will result in that your device considers the certificate as a generally trusted authority. This can in turn allow whoever has access to that certificate’s private key to generate a certificate that falsely appears valid for any site. For example, an evil website could appear to have a valid certificate for your bank.