First published on MSDN on Aug 21, 2017
This article walks you through the steps for encrypting the traffic between web nodes and compute nodes in Linux using self-signed certificates. If a compute node is inside the web node's trust boundary, then encryption of this piece isn't needed. However, if the compute node resides outside of the trust boundary, consider using the compute node certificate to encrypt the traffic between the web node and compute node. As a prerequisite, you can spin a 1-webnode-1-computenode enterprise configuration using ARM Template from here .
For Single Compute Node, use IP Address as Certificate Subject Name.
For multiple compute nodes, use DNS Suffix as Certificate Subject Name.
Example: say you have 2 compute nodes CN1.contoso.microsoft.com, CN2.contoso.microsoft.com, certificate subject name will be CN=contoso.microsoft.com.
cd /etc/ssl/certs
openssl genrsa -out privateKey.pem 2048
openssl req -new -x509 -key privateKey.pem -out publicCert.pem -days 3650 -nodes -subj "/CN=10.0.1.4"
openssl x509 -noout -hash -in publicCert.pem
ln -s publicCert.pem 0c73457b.0
Ubuntu:
apt-get install -y nginx
RedHat:
yum clean all
yum makecache fast
yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
yum install -y nginx
CentOS:
yum install -y epel-release
yum install -y nginx
Location of nginx.conf
Ubuntu : /etc/nginx/sites-enabled/default
RedHat and CentOS : /etc/nginx/nginx.conf
Modify the file in above location to the following contents :
server {
listen 443 ssl;
ssl_certificate /etc/ssl/certs/publicCert.pem;
ssl_certificate_key /etc/ssl/private/privateKey.pem;
server_name _;
location / {
proxy_pass http://127.0.0.1:12805/;
}
}
Ubuntu:
service nginx start
update-rc.d nginx defaults
RedHat:
systemctl start nginx
systemctl enable nginx
iptables –flush
CentOS:
systemctl start nginx
systemctl enable nginx
Launch the administrator's utility and restart the compute node
curl https://10.0.1.4/status
Should give a response like this:
{
"statusCode": 0,
"components": null,
"details": {
"rMaxPoolSize": 500,
"rActiveShellCount": 0,
"rCurrentPoolSize": 5,
"rCanOpenShell": "True",
"apiVersion": "1.0",
"logPath": "/usr/lib64/microsoft-r/rserver/o16n/9.1.0/Microsoft.RServer.ComputeNode/logs"
}
}
Copy paste the publicCert.pem and certificate authority into /etc/ssl/certs
scp root@10.0.1.4:/etc/ssl/certs/publicCert.pem /etc/ssl/certs
scp root@10.0.1.4:/etc/ssl/certs/0c73457b.0 /etc/ssl/certs
Open appsettings.json and modify the URIs :
"Uris": {
"Values": [ "https://10.0.1.4" ]
}
NOTE: If you have multiple compute nodes, make sure to enter all compute nodes information in the URI values. For example:
"Uris": {
"Values": [ "https://CN1.contoso.microsoft.com", "https://CN2.contoso.microsoft.com" ]
}
Launch the administrator's utility and restart the web node .
Verify the configuration by running diagnostic test on the web node.
NOTE: Self-Signed Certificates are NOT recommended for production usage. Please obtain certificate from Trusted Certificate Authorities for production usage.
This article walks you through the steps for encrypting the traffic between web nodes and compute nodes in Linux using self-signed certificates. If a compute node is inside the web node's trust boundary, then encryption of this piece isn't needed. However, if the compute node resides outside of the trust boundary, consider using the compute node certificate to encrypt the traffic between the web node and compute node. As a prerequisite, you can spin a 1-webnode-1-computenode enterprise configuration using ARM Template from here .
On each Linux machine hosting a compute node:
Generate and Install self-signed certificates using the following commands:
For Single Compute Node, use IP Address as Certificate Subject Name.
For multiple compute nodes, use DNS Suffix as Certificate Subject Name.
Example: say you have 2 compute nodes CN1.contoso.microsoft.com, CN2.contoso.microsoft.com, certificate subject name will be CN=contoso.microsoft.com.
cd /etc/ssl/certs
openssl genrsa -out privateKey.pem 2048
openssl req -new -x509 -key privateKey.pem -out publicCert.pem -days 3650 -nodes -subj "/CN=10.0.1.4"
openssl x509 -noout -hash -in publicCert.pem
ln -s publicCert.pem 0c73457b.0
Install nginx
Ubuntu:
apt-get install -y nginx
RedHat:
yum clean all
yum makecache fast
yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
yum install -y nginx
CentOS:
yum install -y epel-release
yum install -y nginx
Modify nginx.conf
Location of nginx.conf
Ubuntu : /etc/nginx/sites-enabled/default
RedHat and CentOS : /etc/nginx/nginx.conf
Modify the file in above location to the following contents :
server {
listen 443 ssl;
ssl_certificate /etc/ssl/certs/publicCert.pem;
ssl_certificate_key /etc/ssl/private/privateKey.pem;
server_name _;
location / {
proxy_pass http://127.0.0.1:12805/;
}
}
Restart nginx
Ubuntu:
service nginx start
update-rc.d nginx defaults
RedHat:
systemctl start nginx
systemctl enable nginx
iptables –flush
CentOS:
systemctl start nginx
systemctl enable nginx
Launch the administrator's utility and restart the compute node
Check Compute Node status using curl
curl https://10.0.1.4/status
Should give a response like this:
{
"statusCode": 0,
"components": null,
"details": {
"rMaxPoolSize": 500,
"rActiveShellCount": 0,
"rCurrentPoolSize": 5,
"rCanOpenShell": "True",
"apiVersion": "1.0",
"logPath": "/usr/lib64/microsoft-r/rserver/o16n/9.1.0/Microsoft.RServer.ComputeNode/logs"
}
}
On each Linux machine hosting a web node:
Copy paste the publicCert.pem and certificate authority into /etc/ssl/certs
scp root@10.0.1.4:/etc/ssl/certs/publicCert.pem /etc/ssl/certs
scp root@10.0.1.4:/etc/ssl/certs/0c73457b.0 /etc/ssl/certs
Open appsettings.json and modify the URIs :
"Uris": {
"Values": [ "https://10.0.1.4" ]
}
NOTE: If you have multiple compute nodes, make sure to enter all compute nodes information in the URI values. For example:
"Uris": {
"Values": [ "https://CN1.contoso.microsoft.com", "https://CN2.contoso.microsoft.com" ]
}
Launch the administrator's utility and restart the web node .
Verify the configuration by running diagnostic test on the web node.
NOTE: Self-Signed Certificates are NOT recommended for production usage. Please obtain certificate from Trusted Certificate Authorities for production usage.
Updated Mar 23, 2019
Version 2.0SQL-Server-Team
Microsoft
Joined March 23, 2019
SQL Server Blog
Follow this blog board to get notified when there's new activity