SSL and certificate notes in AX-3.8

This section explains a little more about the Workbench SSL certificate warnings seen in the section Get the Demo Up and Running. Note that in AX-3.8, a few SSL-related changes were made since the releases for AX-3.7/AX-3.7u1 that affect the “demo” station, which are also described below.

It is safe to “Accept” the certificate (Identification Verification) warnings seen in Workbench when following steps in this document. However, don’t assume that always accepting similar certificates is the correct choice. An overview with a few background details is below. For complete details about SSL and NiagaraAX, refer to the NiagaraAX SSL Connectivity Guide.

Since AX-3.7, NiagaraAX has included integral support for industry-standard Secure Socket Layer (SSLv3) and Transport Layer Security (TLSv1) protocols, via an “SSL Toolset”. Included are Workbench tools for managing PKI (Public Key Infrastructure) digital certificates or “self-signed” digital certificates, which are used in verifying SSL connections. When you install NiagaraAX on your PC, a local self-signed “tridium” certificate is generated, and is available for (default) local SSL usage.

In AX-3.7 (and AX-3.7u1), after installing NiagaraAX on your PC, you could optionally enable SSL for your local PC platform, by making a local platform connection and accessing the Platform Administration view. By default, the “tridium” certificate is presented to any Workbench client that attempts an SSL platform connection.
In AX-3.8 this changed—now when you install NiagaraAX, platform SSL is automatically enabled for you Workbench PC platform—by default using the self-signed “tridium” certificate. In addition, changes were made to the standard “demo” station in AX-3.8 to enable SSL for station access (“Foxs Enabled” in the station’s Fox Service), as well as SSL for browser access (“Https Enabled” in the station’s Web Service)—again, (by default) both reference the self-signed “tridium” certificate.

In either case just described, when you open the first platform SSL connection from Workbench (the client) to your local platform daemon (a server), Workbench presents a warning “Identity Verification” popup that shows you the details of your local self-signed “tridium” certificate.

If you Accept, an “allowed host” exemption is created for your Workbench (client), and you proceed to the Authentication dialog to enter your platform credentials. This warning should not appear again unless you delete the allowed host exemption, or unless the certificate expires.
If you Reject, no exemption is created, nor do you see the Authentication dialog to make a connection. Instead, an error message is generated.

Note this Workbench certificate warning repeats when you open the first station SSL connection (Foxs) to a local station—in this case to your AX-3.8 “demo” station. When you Accept, another “allowed host” exemption is created for your Workbench client, this time for a different software port: 4911 Foxs default, (vs. 5011 platformssl default). Similarly, web browser access using a secure connection produces a warning in your client browser; see Browser access notes.

In general, usage of PKI signed certificates with NiagaraAX is recommended over the (default) self-signed “tridium” certificate. However, details are well outside the scope of this document. Again, refer to the NiagaraAX SSL Connectivity Guide for complete details.