Secure communication troubleshooting
This topic suggests solutions for common connection security problems.
When I attempt to import the signed server certificate back into the host User Key Store, I get errors.
This may happen if you deleted the original certificate created on the host from which you created the CSR. If you backed up this certificate, import it back into the User Key Store and import the CSR again. Generating a new certificate with the same name does not generate the same key pair and will result in errors when you attempt to import a signed certificate whose keys do not match.
For months I have been able to log in without being prompted to accept a certificate. All of a sudden the software is asking me to accept the certificate again.
One or more of the following may be occurring:
The client may no longer contain the host's root CA certificate in the User Trust Store (for whatever reason). Check the certificate and import a matching root CA certificate into the User Trust Store.
The root CA certificate may have expired or changed and you need to import new certificates. Check the server certificate carefully to make sure it is trusted and temporarily approve it, creating an exemption in the Allowed Hosts list. Create or acquire a new root CA certificate and create new server certificates. Get the new server certificates signed by the new root CA certificate. Finally, import the certificates into the appropriate stores, deleting any expired certificates and any temporary exemptions you approved in the Allowed Hosts list.
There may be a problem with the Fox port. Check the FoxService on the client NiagaraNetwork to ensure the correct Fox port: 4911 for Foxs; 1911 for Fox.
You may be subject to a man-in-the-middle attack and no trusted root CA certificate exists for the attacker in the platform/station Trust Stores. Check the certificate’s Issued By and Issuer DN (Distinguished Name) carefully. Do not manually approve a certificate for an issuer you do not recognize.
The Session Info window (right-click ) shows a red shield with a white x in the section that reports host identity authentication.
There may be a number of reasons for this:
If you are serving as your own Certificate Authority, a platform and station requires your root CA certificate in its User Trust Store. When you start the platform or station for the first time the User Trust Store is empty. This causes the system to generate a self-signed certificate and display it for you to approve before it establishes the connection. Compare the Issued By and Subject properties. They are the same for a self-signed certificate. If you recognize the name, you can manually approve the certificate and rest assured that communication is secure. If you do not recognize the name, do not manually approve the certificate. If you are configuring the host for the first time, import your root CA certificate to the host’s User Trust Store as soon as possible and delete the default, self-signed certificate.
If, in a hurry, you allowed a certificate without checking its Issued By and Issuer DN (Distinguished Name), and you are worried about what you approved, open the platform/station stores (); click the Allowed Hosts tab; locate the certificate and, if you do not recognize it, click Unapprove.
When running in a browser, the Https in the address is crossed through with a red X next to it.
This indicates that you are using a self-signed certificate for which no client certificate exists in the browser’s trust store. Using Google Chrome, the browser caches nothing. You can still access the platform and station, but system performance is less than desirable. To speed performance, set up and import your own root CA certificate into the browser’s trust store, or purchase and install a signed client certificate from a CA (Certificate Authority).
I enabled TLS and logged in using a secure connection, but the platform icon does not include the lock symbol. Why did the platform boot with a connection that is not secure?
Most likely there is something wrong with the certificate. If a certificate fails, or for any reason secure communication cannot start, rather than lock you out of the platform, the system enables a connection without security. Restart the platform.
I enabled TLS and logged in using a secure connection. The platform icon shows the lock symbol, but no communication is occurring.
A firewall or secure router may be blocking or ignoring a port. Consult your firewall or router documentation for a list of blocked ports, then either unblock the port in the firewall or router, or change the port using Workbench.
I'm using a signed server certificate, but the message "Unable to verify host identity" still appears when connecting to the platform.
The system cannot find a root CA certificate in a Trust Store that matches the server certificate. Import the root CA certificate used to sign the server certificate into the User Trust Store.
My platform or Supervisor private key has been compromised, what should I do?
Get on site as quickly as possible. Take the entire network off the Internet. Configure security again for each compromised platform creating and signing all new certificates.
When importing a root CR certificate into a client User Trust Store I get the message, "The ‘Import’ command encountered an error" or the certificate simply did not import.
Click the Details button to view the Workbench console. Investigate these possibilities:
You may be attempting to import a private key into the User Trust Store. This cannot be done.
Export the root CA certificate from the Workbench User Key Store without its private key and try to import it again into the client User Trust Store.
The Issuer of the certificate you are importing must be the same as the Subject of the certificate that is below it in the certificate tree (the certificate used to sign the one that is causing the error). This may be an intermediate certificate or the root CA certificate. Beginning at the bottom of the tree, the issuer-subject relationship is something like this:
Issuer, SubjectC, DB, CA, B
Where “A” is the root CA (Certificate Authority) at the root of the certificate tree. “D” is the subject of the final server certificate in the tree. The rest are intermediate certificates.
If necessary, delete the certificate, create a new certificate, sign it using the certificate below it in the trusted certificate tree, and attempt to import again.
I'm trying to get two stations to connect and it is not working.
If this is the first time you are making this connection, check the Allowed Hosts list. The station serving as the client may not have a certificate in its User Trust Store for the station that is serving as the server. In the Allowed Hosts list, analyze the exemption, then select the certificate to make sure that you recognize its Issued By and Issuer DN (Distinguished Name) and click Approve. Check the certificate for the correct name and port number in the Host column.
If you have been connecting successfully but suddenly you are unable to connect, try to figure out what changed. Check the daemon logs for an error message.
If you are using root and intermediate certificates, check the Issuer name on your signed intermediate and server certificates. It should be the same as the Subject name on the root CA certificate. When it is unable to validate the certificate tree, the software prevents communication.
We use self-signed certificates. All hosts are approved in the Allowed Hosts list, and we've been able to connect to our platforms without getting the message that our hosts are not trusted. All of a sudden we're getting that message again. What happened?
If the IP address of the platforms changed, the entry in the Allowed Hosts list is no longer valid.
I get the message, “Cannot connect. Ensure server is running on specified port.” when I attempt to log in to a secure station:
This is a general message. A number of things could be wrong:
There may be a problem with the controller. Ensure that the controller is connected to power and the power is on.
You entered invalid credentials or, for some other reason, you are having difficulty logging on (the station may have stopped running). Confirm your credentials, start the platform and use the Platform Application Director to start the station, then connect again.
Your secure WebService (Https) or FoxService (Foxs) may not be enabled (set to true). Both must be enabled to make a secure station connection. Make a regular station connection by clicking , select Station Connection, provide credentials, then, on the FoxService Property Sheet, confirm that Foxs is enabled (set to true), close the station and connect to it again. Make sure you select a Station TLS Connection for Type in the Connect window.