NEW Web Server Config Page and SSL / TLS Setup Wizard

Ignition Early Access
1

The last 8.0.3 early access build includes a new config page titled “Web Server” under the “Networking” section along with significant changes to how SSL / TLS is managed. Following are the details:

Gateway Properties

The following properties may now be configured from the Gateway config web interface:

  • HTTP Port
  • HTTPS Port
  • Force Secure Redirect
  • Included Cipher Suites
  • Excluded Cipher Suites

Changes to these properties take effect to the running Gateway immediately (no restart required). This is important to be aware of since this will affect any existing connections to the Gateway.

HTTP and HTTPS ports continue to be persisted in gateway.xml with properties gateway.port and gateway.sslport respectively.

The force secure redirect flag is persisted in gateway.xml with property gateway.forceSecureRedirect and defaults to false. When set to true, the Gateway will redirect all HTTP traffic to HTTPS if HTTPS is set up (more on this below). This option deprecates the “Use SSL” option which used to exist in the “Gateway Settings” page but is now removed.

User included and excluded cipher suites are now persisted as a JSON-encoded array of Strings in gateway.xml with properties gateway.includedCipherSuites and gateway.excludedCipherSuites respectively. When the gateway starts up, if these properties are not set in gateway.xml, it will pull any values from system properties ciphers and excludedCiphers (where they used to be set) and set them accordingly in gateway.xml.

Note: changing these properties directly in the gateway.xml file on the filesystem will not affect the running Gateway until it is restarted. Only changes through the Gateway web interface take immediate effect without a restart.

SSL / TLS Setup

Prior to 8.0.3, setting up a genuine SSL certificate was a major pain point. We aim to improve that experience by introducing an SSL / TLS setup wizard in the new Web Server config page. The wizard will guide you through the process of generating a CSR and uploading the necessary server and CA certificates in the right order.

On upgrade, if SSL was already set up, it will continue to work. However, on fresh installs, SSL / TLS will not be setup by default. You must go through the SSL / TLS setup wizard to install an SSL certificate in order to enable HTTPS.

Note that it is also possible to delete the SSL certificate installed on the Gateway, which will disable SSL / TLS.

The Gateway’s SSL key store is now persisted in $IGNITION/webserver/ssl.pfx formatted as a PKCS12 key store, an open standard supported by tools such as openssl. The alias of the certificate chain and private key can be set using system property ignition.ssl.keystore.alias (defaults to ignition) and the password can be set using system property ignition.ssl.keystore.password (also defaults to ignition).

Note: changing the key store file directly on the filesystem will not affect a running Gateway until it is restarted. Only changes though the Gateway web interface will take immediate effect without requiring a restart.

Stronger Default Cipher Suites

The following cipher suites have been excluded by default in order to increase the strength of the default SSL / TLS profile of the Gateway:

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384

If you experience any issues connecting to the SSL port of the Gateway using the launchers, download the latest launchers from the Gateway, as we added support for stronger ciphers. As an alternative workaround, you could weaken your cipher suites by including one of the above, but that is not recommend.

Hope you all enjoy these new features!

9 Likes
3

I haven’t yet upgraded to 8.0.3, but does it allow you to import an existing .pfx or a set of PEM files/paste? Or should I count on just replacing ssl.pfx? Most importantly, since pfx is password-encrypted, how does that work? Just blank password?

My current plan is to use Let’s Encrypt via Certify, and use a post-renewal action to build and copy the pfx cert and restart the gateway, but I’d like to be able to manually import to get it working and verify initially.

4

Hi @silverbacknet -

You could create the PKCS12 key store and copy into $IGNITION/webserver/ssl.pfx. You will need to restart the gateway to apply the change.

You could also take the .pem certs from Let’s Encrypt and drag / drop into the new web config interface or paste the PEM’s text into the web config interface. The interface is a wizard which guides you through setting up the private key, server certificate, any intermediary CA certificates, and the root CA certificate.

We are also getting real close to enabling hot-reload of the key store but it has not yet been merged in. This would allow better support for Let’s Encrypt. We will provide more detail when this feature is available.

For the key store password: the Gateway uses whatever password is in system prop ignition.ssl.keystore.password (default is ignition).

1 Like
5

This will be awesome! We had semi-automated this through some scripting (it is a very tedious process), but this will make things work so much easier! Look forward to migrating to 8.

6

Thanks! This will make life so much simpler once I upgrade! :heart:

7

I'm pushing my client toward upgrading to a fully released version (they're on an early nightly of 8.0.2 right now), so if that gets in, it'll be a total killer feature. No downtime at all! It's every administrator's dream and every engineer's headache.

8

Hi @jspecht
I just tried this and failed.
I put the ssl.pfx file (PKCS12 key store) in the webserver folder and restarted. The logs displayed the error below.
Does this mean Ignition found the file, but the format was different to what it expected?
Any ideas what I need to do to fix this?
Thanks

image
image898×313 52.2 KB

9

Hi @DavidWisely -

Ignition looks for the entry in the key store with whatever alias is specified in system prop ignition.ssl.keystore.alias. If you have no value specified in the system prop, the default alias is ignition.

Looks like it could not find an entry with the target alias. To get it working, either change the entry’s alias to ignition in the key store or set the system prop to the alias set in the key store.

10

This is great, LE support will be awesome. Currently, we run a reverse proxy in front of Ignition servers just for the ability to use LE certificates without needing downtime to swap them every few months.

11

Thanks @jspecht,
How do I check and update the system property?
When I run system.util.getProperty('ignition.ssl.keystore.password') on the gateway I get null.
How do I set it?

12

The proper place would be in ignition.conf under a wrapper.java.additional parameter

13

The latest nightly build includes better support for Let’s Encrypt and will also be in 8.0.3.

In order to better support Let’s Encrypt, the Gateway now checks to see if $IGNITION/webserver/ssl.pfx has changed every 15 minutes by default (configurable with system prop ignition.ssl.refresh - set to 0 to disable automatic refresh). If the key store on disk differs from the current SSL key store in memory, the in memory key store is replaced with the one on disk. The SSL connector is hot-reloaded with the new key store.

Also added a GCU command to hot-reload the SSL key store with the current one on disk on-demand:

-g, --reloadks : Reloads the gateway's SSL key store from disk. The gateway's SSL / TLS connector will not be interrupted. Existing connections will use the previous certificate while new connections will be served the new certificate.

Those who wish to use Let’s Encrypt certs with the Gateway may now automatically rotate certs by leveraging a script which builds the PKCS12 key store and writes it to $IGNITION/webserver/ssl.pfx. You can then wait for the automatic refresh to pick up the change or manually invoke the change by calling the above GCU command as a part of a script.

3 Likes
14

So with the latest 8.0.4 I get the following in the logs every 15 minutes. I do not have ssl enabled.

java.lang.Exception: PKIX certificate path validation failed

at com.inductiveautomation.ignition.gateway.ssl.CertificateValidationUtil.verifyTrustChain(CertificateValidationUtil.java:288)

at com.inductiveautomation.ignition.gateway.ssl.CertificateValidationUtil.verifyTrustChain(CertificateValidationUtil.java:105)

at com.inductiveautomation.ignition.gateway.ssl.SslManager.validateKeyStore(SslManager.java:259)

at com.inductiveautomation.ignition.gateway.ssl.SslManager$AbstractStateReader.readState(SslManager.java:296)

at com.inductiveautomation.ignition.gateway.ssl.SslManager.refreshInternal(SslManager.java:435)

at com.inductiveautomation.ignition.gateway.ssl.SslManager.refresh(SslManager.java:398)

at com.inductiveautomation.ignition.gateway.ssl.SslManager.lambda$scheduleNextRefresh$1(SslManager.java:385)

at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)

at java.base/java.util.concurrent.FutureTask.run(Unknown Source)

at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

at java.base/java.lang.Thread.run(Unknown Source)

Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

at java.base/java.security.cert.PKIXParameters.setTrustAnchors(Unknown Source)

at java.base/java.security.cert.PKIXParameters.(Unknown Source)

at java.base/java.security.cert.PKIXBuilderParameters.(Unknown Source)

at com.inductiveautomation.ignition.gateway.ssl.CertificateValidationUtil.verifyTrustChain(CertificateValidationUtil.java:226)

… 11 common frames omitted

15

Hi @jpark -

Looks like you are upgrading from an older version which uses a java key store at $IGNITION/webserver/ssl.key. Do you have a root CA cert in the SSL key store’s cert chain?

16

Hi,
I have SSL installed and have the ports open for firewall. it doesn’t work with my URL masking.
https://ip:port works but loads up as not secure connection.
What might be the reason for this?

Thank you.

17

SSL checks the DNS server names used to make the connection against the name or names in the certificate. You will have to fix your URL “masking”.

1 Like
18

As pturmel suggested, modern browsers have started changing how they validate the site you are communicating with. When we initially create the certificate, you are asked about the name of the computer, which is captured as part of the CN properties of the Subject field (if you look at the certificate details). However, Chrome, along with many other browsers, are now using the Subject Alternative Name field instead, which can contain several items, including DNS Name, IP Address, and some others. If you have having a problem getting the web page to come up without the security warning, you will need to include all DNS names and IP addresses you would typically use to access it (i.e. 127.0.0.1, localhost, etc…). I’m guessing if you added your URL mask as one of the DNS names, it would work.

Once alternative you can use now is a wildcard certificate that would have DNS Name=*.domain.com and would work on several servers.

1 Like
19

Thank you very much for the replies. I figured it was not an ignition issue rather than moving our domain from one provider to another.