Using Certificates in R Server Operationalization for Linux

In this article, we will look into how to generate a self-signed certificate in Linux and use it for access token signing in R Server Operationalization Web Node. You must use a certificate for access token signing whenever you have multiple web nodes so that the tokens are signed consistently by every web node in your configuration. A certificate with a private key is required to sign the user access tokens between the web node and the LDAP server. Tokens are particularly useful to the application developer who can use them to identify and authenticate the user who is sending the API call within her or his application.

To try this out, you can spin up one of the R Server Linux images that are available in the Azure Portal:

Microsoft R Server (version 9.1.0) for Linux (Ubuntu version 16.04)
Microsoft R Server (version 9.1.0) for Linux (CentOS version 7.2)
Microsoft R Server (version 9.1.0) for Linux (RedHat version 7.2)

Here are the list of steps:

1. Switch to root user and navigate to home directory /root

sudo su
cd /root

If you already have a certificate from Trusted Certificate Authority , skip step 2 and move to step 3.

2. Generate Self-Signed Certificate (.pfx file)

We are limited to using pfx files since dotnet core can read private keys only from pfx files. Using subjectName CN=LOCALHOST here, you can replace with a subject name of your choice.

openssl genrsa -out privateKey.pem 2048
openssl req -new -x509 -key privateKey.pem -out publicCert.pem -days 3650 -nodes -subj "/CN=LOCALHOST"
openssl pkcs12 -export -out merged.pfx -inkey privateKey.pem -in publicCert.pem -passout pass:

3. Install Certificate using dotnet code

Only Root and CertificateAuthority are supported for StoreName in Linux. We will use Root as StoreName since we start the WebNode as root user. On Linux, we don’t have any notion of machine-owned private keys, because Linux doesn’t have a machine-level private key store, and the LocalMachine\Root is loaded with that knowledge (it loads only X.509 PEM, X.509 DER, and X.509 PEM-series files). Hence, we will use CurrentUser as StoreLocation.

dotnet new console -o InstallCert
cd InstallCert
vi Program.cs
dotnet restore
dotnet run

If the program ran successfully without any errors, certificate will be installed in the following path with its thumbprint as file name:


4. Modify /usr/lib64/microsoft-r/rserver/o16n/9.1.0/Microsoft.RServer.WebNode/appsettings.json with the following JWTSigningCertificate information:

"JWTSigningCertificate": {
 "Enabled": true,
 "Description": "Enable this section if you want to sign the access token with a certificate instead of a randomly generated key",
 "StoreName": "Root",
 "StoreLocation": "CurrentUser",
 "SubjectName": "CN=LOCALHOST"

At this point, you will see that JWTKey has a ‘not set’ value in appsettings.json file :

"JWTKey": "not set"

5. Start the web node using the administration utility so that the changes can take effect.

6. Once the webnode starts successfully, check /usr/lib64/microsoft-r/rserver/o16n/9.1.0/Microsoft.RServer.WebNode/appsettings.json to see if the JWTKey has been generated :

"JWTKey": "eyJEIjoiSkp..........WdTRJZ009In0="

If you have multiple web nodes, Copy paste the certificate to all other webnodes and perform step 3 to 6.

Share the connection details with any users who authenticates with R Server either to make API calls directly or indirectly in R using remoteLogin() function in the mrsdeploy package.

NOTE: Self-Signed Certificates are NOT recommended for production usage. Please obtain certificate from Trusted Certificate Authorities for production usage.

This method of using Self-Signed Certificates for JWTSigningCertificate is automated in Linux Enterprise ARM Template.


Authentication options for R Server when operationalizing analytics

Access Token Management for API Requests

Connection Security (SSL/TLS)

Comments (0)

Skip to main content