Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Symptoms

An SSL certificate is necessary for more than just distributing the public key: if it is signed by a trusted third party, it verifies the identity of the server so clients know they aren’t sending their information (encrypted or not) to the wrong person. So what is a self-signed certificate? It is a certificate that is signed by itself rather than a trusted third party. This is not a good idea for most business use cases. You will rarely want to use a self-signed certificate on a public Web server that requires anonymous visitors to connect to your site because they could easily become a victim of a man-in-the-middle attack. There are a limited number of situations in which a self-signed certificate may prove adequate:

...

In other words, when deploying your SoftNAS server into an enterprise use case, it may be required (or at least strongly recommended) that you switch the default self-signed certifications for your own enterprise certifications.

Purpose

This article provides the steps required to provide your own certifications to your SoftNAS instance.

Resolution

If you want to send or receive messages signed by root authorities and these authorities are not installed on the server, you must add a trusted root certificate manually.

...

First, take a backup of the existing certificate and key files.

Panel
borderColorblack
titleBGColor#f0f0f0
borderStylesolid
# mv /etc/pki/tls/certs/ca.crt /etc/pki/tls/certs/ca.crt-old

# mv /etc/pki/tls/private/ca.key /etc/pki/tls/private/ca.key-old




Next, upload the SSL certificate and key file using any preferred SSH client to the Softnas node and copy the newly uploaded certificates and keys files to the right path.

Panel
borderColorblack
titleBGColor#f0f0f0
borderStylesolid
# cp new.crt /etc/pki/tls/certs/ca.crt

# cp new.key /etc/pki/tls/private/ca.key



After that make sure "ca.crt" file has the 644 file permission and "ca.key" has the 600 file permission with root user ownership. Otherwise, fix using the below commands.


Panel
borderColorblack
titleBGColor#f0f0f0
borderStylesolid

# chown root:root /etc/pki/tls/certs/ca.crt

# chown root:root /etc/pki/tls/private/ca.key

# chmod 644 /etc/pki/tls/certs/ca.crt

# chmo 600 /etc/pki/tls/private/ca.key


Once the new certificates and keys are in right place, check the Nginx config file and restart the service.


Panel
borderColorsolid
borderWidthblack
titleBGColor#f0f0f0

# nginx -t

# systemctl restart nginx


Notes/Additional Info:

  • It is HIGHLY recommended to add the certificates before configuring replication to avoid any SnapReplicate™ interruption, as changing the keys will deactivate replication.
  • In case there is a need to change the keys after configuring SnapReplicate™:

Execute the following command on both the target and source node and erase the ssh fingerprints:


Panel
borderColorblack
titleBGColor#f0f0f0
borderStylesolid
# sed -i '/OTHER-NODE-IP-ADDRESS/d' .ssh/known_hosts


Next, to add a new set of fingerprints, type the following command:


Panel
borderColorblack
titleBGColor#f0f0f0f0
borderStylesolid
# ssh-keyscan   OTHER-NODE-IP-ADDRESS   >> .ssh/known_hosts


Log into the Web UI (StorageCenter) on both instances and try to activate HA again. The problem should be resolved. Contact support if you have further issues.

...