It's possible to use an SSL certificate with the launcher in Posit Workbench. This may seem appealing, but what does this mean and how does it affect the interactions with Posit Workbench?
Can I use the same SSL for my Posit Workbench server, for the launcher?
Yes, however, it is strongly recommended & a best practice to ensure that the Launcher certificates are different from those used for Posit Server.
Launcher with SSL Explained
Consider the following diagram:
(a) (b)
Browser (User) <------> RSP <------> Launcher
^
| (c)
v
R Session
- (a) represents the communication between the Browser and Posit Server itself.
- (b) represents the communication between Posit Server and the RStudio Job Launcher.
- (c) represents the communication between the RSession and the Posit Job Launcher. (Note: The Launcher starts the session in the backend, such as Slurm or Kubernetes, but does not communicate with the session directly.)
All three lines of communication are over HTTP/S. The R Session communicates with Posit Server (c) the same way that a browser communicates with RStudio Server (a). The R Session discovers the address with which to communicate with the server via the launcher-sessions-callback-address setting, which is why the setting needs to be exactly the same as what you would enter into the browser.
The settings that pertain to the encryption of (a) and (c) are as follows, that is, enabling HTTPS for communication with Posit Server:
/etc/rstudio/rserver.conf:
ssl-enabled=1
ssl-certificate=</path/to/server/cert.pem>
ssl-certificate-key=</path/to/server/key.pem>
Additionally, the following settings are relevant to the configuration of HTTPS for (a) and (c), but not strictly required for enabling it:
/etc/rstudio/rserver.conf:
www-address=<my-org.rsp-hostname.com>
www-port=<port#, default 443 if ssl-enabled=1>
launcher-sessions-callback-address=<https://my-org.rsp-hostname.com[:port#]>
In addition to the requirement that certificates defined in rserver.conf are added to the trusted certificate store of the host, they must have been generated with the correct Common Name (or CN) matching the hostname of RSP (most likely the same value as the www-address), and the files must have restrictive permissions (root:root 400). Additionally, the CA root must be trusted by any machines within your network that will access RSW. For example, a user's machines as well as Slurm compute nodes that will run R sessions.
The settings that pertain to the encryption of (b) are as follows (i.e. to enable HTTPS for communication between Posit Server and the Launcher):
/etc/rstudio/rserver.conf:
launcher-use-ssl=1
launcher-address=<launcher hostname or IP>
launcher-port=<port#>
/etc/rstudio/launcher.conf:
enable-ssl=[0|1]
certificate-file=</path/to/launcher/cert.pem>
certificate-key-file=</path/to/launcher/key.pem>
address=<launcher hostname or IP>
port=<port#>
Note that the values of launcher-use-ssl, launcher-address, and launcher-port in rserver.conf should match the values of enable-ssl, address, and port in launcher.conf respectively. Also, note the lack of http:// or https:// in front of the launcher-address value. The protocol for communication is determined by the value of launcher-use-ssl.
The Launcher certificates must be different certificates from those used for Posit Server. The correct CNfor the Launcher's certificates is the value of address in launcher.conf. If Posit Server and the Launcher will be running on the same machine, localhost may be used. Another difference from the Posit Server certificates is that the Launcher certificates should be owned by the server-user and admin-groupand defined in launcher.conf. For example, if those values were left as they are on installation (both rstudio-server) then the certificate files for the Launcher should have the permissions rstudio-server:rstudio-server 400.
More information on SSL configuration options can be found here:
https://docs.posit.co/ide/server-pro/access_and_security/secure_sockets.html
Skipping the SSL check
You can skip the SSL check for both the server and launcher by modifying your /etc/rstudio/rserver.conf and /etc/rstudio/launcher.conf with the directives below:
/etc/rstudio/rserver.conf:
#Indicates whether or not to verify the Launcher certificate(s) when using an SSL connection
launcher-verify-ssl-certs=0
#Indicates whether or not to enforce SSL certificate verification of the server when Launcher sessions communicate back via the callback address.
launcher-sessions-callback-verify-ssl-certs=0
/etc/rstudio/launcher.conf:
#Whether or not to verify SSL certificates when connecting to other Launcher instances. Only applicable if connecting over HTTPS and load balancing is in use
verify-ssl-certs=0
Support Ticket
If you still have issues after completing the above, you can always lodge a support ticket, where our group of friendly, and incredibly knowledgeable staff can assist with any issues that you may be having. You can submit a ticket here:
Comments
2 comments
The document doesn't detail why you would need seperate certificates for the launcher vs server. This is not intuitive to me. Would it be possible to develop on why it is not the case?
Hi Bruno,
That's a good question and I'm glad you brought this up. The Common Name(CN) for an SSL certificate will usually be specific to the name of the server that you're using the certificate for (disregarding wildcard certificates and SAN certificates here). Typically, RStudio Workbench will be available externally to the machine itself and can have an external-facing DNS name unique to your organization. For example, my-org.rsw-hostname.com. In this scenario, the server will likely be running on my-org.rsw-hostname.com, however, the launcher will be running on localhost. In this case, your server certificates CN will be my-org.rsw-hostname.com, and your Launcher certificates CN will be localhost.
You can use both the server and launcher on the same domain name so that they can share certificates, however, we wouldn't recommend this as best practice.
I hope this helps! Let me know if you have any follow-up questions
Article is closed for comments.