Securing Your Ignition Gateway

Sep 17

If you visit nearly any website and look at the URL in the browser, you’ll see a lock icon indicating that the site is using https. Basically this means the site is using a certificate to validate itself as authentic and secure. This is important especially for sites that use credit cards or other personal information, as the data on an https connection is encrypted.

Since most of the websites you visit on a daily basis use certificates, why is it unusual to see the lock on an Ignition Gateway, or most SCADA systems for that matter?

A few reasons SCADA systems don’t use certificates:

SCADA software is not always up to modern standards and doesn’t support using certificates
“Security through obscurity” is the norm in manufacturing. You may think that if people can’t see your network then it’s secure…
Instilling security as a cultural norm at a company can be costly in dollars and educational resources

Luckily, we can solve all these problems with Ignition, an SSL certificate from Let’s Encrypt, the info in this post, and Inductive Automation’s online documentation.

What is a Certificate?

At its most basic level, a certificate is a set of keys that let your computer encrypt a message, send it to a server—then the server can decrypt it and read the message. The server can then send data back to you. This example uses the idea of a lock and key to demonstrate this concept. While that example glosses over how the certificate process works in a browser session, essentially you are getting the lock from a website when you access it. Then your browser uses that key to encrypt your message. Next, the server uses its private key to decrypt the message.

In practice, how a certificate works will require more steps as described in this article: How SSL Works. Basically, your browser (the client) accesses a server and sends information to set up the secure connection. Then, the server responds to the client with information including the server’s public key. Next, your browser will authenticate this public key against a Certificate Authority (CA). Assuming all is well, the client creates a session key (encrypted with the server’s public key), and sends the session key to the server along with a message. The server decrypts the message using the session key, and the session key is then used by both client and server to encrypt data back and forth for the session. The process is repeated when a new session or a new client accesses the server.

The main idea is that certificate authorities exist, and they manage the generation of certificates. This ensures that a small group of people/companies are tasked with controlling the certificates themselves. Certificate authorities have a documented and detailed level of scrutiny as well as checks and balances to ensure this system is trusted across the world.

What is Let’s Encrypt?

From their website, Let’s Encrypt is “a free, automated, and open certificate authority (CA), run for the public’s benefit. It is a service provided by the Internet Security Research Group (ISRG).”

Let’s Encrypt can generate certificates, validate them, and act as a CA option. There are many other options available, however Let’s Encrypt is a relatively user friendly and free option to get certificates. Depending on what certificates you need and how you acquire them, this can otherwise be a costly proposition for a manufacturing company.

Most manufacturing companies will only need a few certificates, and they will likely be tied to a domain name. Let’s Encrypt’s limitations are not issues in these cases. Unlike most paid certificates that expire after a year, Let’s Encrypt certificates expire after 90 days, which means you will either need to renew them every 90 days, or set up an automated system to handle this for you. Either way, the benefits of having encrypted traffic at essentially zero cost are well worth a few extra minutes every quarter.

How Do I Set Up Ignition with an SSL Using Let’s Encrypt?

If you are using an Ignition version prior to 8.0.3, read this article. For Ignition 8.0.3 and beyond, reference this article for a more in depth look on everything that’s going on under the hood. We will walk through the 8.0.3+ plus version, and simplify it a bit using a real domain to point to an Ignition gateway in the cloud.

Corso Systems can help you secure your Ignition installation!

Schedule a short 15-minute intro call with Cody Johnson in sales so we can start your project ASAP.

Prerequisites:

Ignition 8.0.3+ is installed on a machine you have access to (in our example, this is an Ubuntu VM running on Linode)
You own a domain (our example uses cbs.corsosystems.com)
Your domain is pointed to your Ignition gateway (ours is configured on our domain provider using an A record to point the cbs subdomain to our gateway)
Install certbot on your machine using the steps detailed here (Digital Ocean example) or here (Linode example).

Step 1: Perform an ACME Challenge.

To perform an ACME Challenge, I will connect to the Ubuntu instance in a terminal window. There I will run the following command, enter the required information, accept the terms, and enter my domain, in this case cbs.corsosystems.com.

certbot certonly --webroot

This will create a token, validate the token is on the server, and generate the keystores we will use to generate our certificate.

The ACME Challenge will automatically create a certificate chain and a private key. In our example, they will be in the following location, but your server may have a different structure, based on the domain name you are using:

Certificate Chain: /etc/letsencrypt/live/cbs.corsosystems.com/fullchain.pem
Private Key: /etc/letsencrypt/live/cbs.corsosystems.com/privkey.pem

Generate the Keystore

We will also need a root CA certificate to generate the keystore. Let’s Encrypt (as of the time of this writing) uses the certificate located here. You will need to copy the certificate into a .pem file on your machine. In our case I saved it under /usr/local/bin/ignition as rootCA.pem.

Build a Full Certificate Bundle

Next, we will build the full certificate bundle using our certificate chain and root CA certificate and store it in a file. I will save it in the /usr/local/bin/ignition folder as certBundle.pem using the following command:

cat /etc/letsencrypt/live/cbs.corsosystems.com/fullchain.pem /usr/local/bin/ignition/rootCA.pem > /usr/local/bin/ignition/certBundle.pem

At this point, you could stop and manually copy the various keys into the fields on the Gateway Configuration page, Web Server, Certificate Wizard, then move onto the next section when it is time to renew. Or you can generate the certificate and load it using the command line as detailed below, the choice is yours.

To generate the keystore, use the following command, again using your domain name where appropriate (all on one line):

openssl pkcs12 -export -out /usr/local/bin/ignition/ssl.pfx -inkey /etc/letsencrypt/live/cbs.corsosystems.com/privkey.pem in /usr/local/bin/ignition/certBundle.pem -passout pass:ignition -name ignition

This will generate the file we will now copy to the server before reloading the keystore.

To copy the new keystore run the following command:

cp /usr/local/bin/ignition/ssl.pfx /usr/local/bin/ignition/webserver/ssl.pfx

Next you can remove the certificate bundle and the temporary key store using the following command:

rm /usr/local/bin/ignition/certBundle.pem /usr/local/bin/ignition/ssl.pfx

Reload the Keystore in Ignition

Finally we will reload the keystore in Ignition to refresh it with the new one, after this you can go into the gateway configuration to enable/require SSL as needed:

/usr/local/bin/ignition/gwcmd.sh --reloadks

What About Renewing the SSL Certificate?

The Let’s Encrypt certificate will expire every 90 days, so you will need to periodically renew it to keep SSL enabled and working on your Ignition gateway.

To renew the certificate you first need to run the certbot command again, using the following format:

certbot certonly --webroot --webroot-path /usr/local/bin/ignition --domains cbs.corsosystems.com --agree-tos --deploy-hook /usr/local/deploy_script.sh

Optional: Creating a Deployment Script

You basically need to go through the process above again to renew the certificate, however this time we can create a deployment script that runs through each step automatically. To do this create a file on your machine called “deploy_script.sh” and put the following text in it, replacing the domain where necessary. This fie will be save in /usr/local/ per the command above, but you can move it anywhere you like:

cat /etc/letsencrypt/live/cbs.corsosystems.com/fullchain.pem /usr/local/bin/ignition/rootCA.pem > /usr/local/bin/ignition/certBundle.pem

openssl pkcs12 -export -out ssl.pfx -inkey /etc/letsencrypt/live/cbs.corsosystems.com/privkey.pem -in /usr/local/bin/ignition/certBundle.pem -passout pass:ignition -name ignition

[[ -f /usr/local/ignition/webserver/ssl.pfx ]] && cp /usr/local/ignition/webserver/ssl.pfx /usr/local/ignition/webserver/ssl.pfx.bk

cp ssl.pfx /usr/local/ignition/webserver/ssl.pfx

rm /usr/local/bin/ignition/certBundle.pem ssl.pfx

/usr/local/ignition/gwcmd.sh --reloadks

You can then set up a cron job to execute this automatically on a daily schedule, or run the certbot command in this section manually as needed.

What’s Next for Securing My SCADA System?

Now, go to your Ignition gateway and enable SSL—and force it to use https over http as needed.

Moving further there are a number of options you can implement to further secure your Ignition server. You can lock it down to require key based authentication for SSH, lock down the firewall rules on the operating system itself, as well as using a hardware layer. Disable any unused network services, use Fail2Ban to protect SSH login, add in intrusion detection, and maybe even enable two factor authentication where applicable.