Internet Security (TLS, X.509, SSL)

"SSL" is the acronym for the Secure Sockets Layer security protocol. SSL is an older technology, but the term has become the de facto name for Internet security. VTScada uses the more modern Transport Layer Security (TLS) protocol (although, for the sake of compatibility with older Windows operating systems, it can use SSL.)
While the term "SSL Certificate" is in common use, "X.509 Certificate" is the correct term.

Installing a Certificate and configuring VTScada to use it, is not an inherently difficult process, but it is frequently a cause of frustration. Sometimes significantly so. Every step in the process must be followed carefully, skipping none.

Certificates expire and must be renewed. After purchasing your certificate, take note of the expiry date and create one or more Trigger Tag + Alarm Tag pairs, configured to alert you when it is time to renew the certificate.

Terms:

CA.

A Certificate Authority. Responsible for issuing certificates and maintaining Certificate Revocation Lists (CRL).

Private key

Most often held in PEM format, this is a Base64 encoded blob surrounded by "-----BEGIN PRIVATE KEY-----" and "-----END PRIVATE KEY-----". Can also be be encrypted and then has the header "-----BEGIN RSA PRIVATE KEY-----" followed by "Proc-Type: 4,ENCRYPTED". This MUST be held securely, if lost, the certificate is useless and must be re-issued. If leaked, others could pretend to be your host.

X.509 certificate

This contains, among other things a public key corresponding to a private key, and identifying information for the subject (host) of the certificate and the issuing authority. Usually in PEM format, surrounded by "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----".

Often a text version of the certificate is also in the file, this is ignored by OpenSSL and the Windows certificate manager. Can be re-issued by the CA.

PFX file

This is a #PKCS12 format file containing a certificate and a private key. Often includes additional root and intermediate certificates. Encrypted.

An X.509 certificate is a digitally-signed authentication that fulfills the following requirements:

Identifies a host computer, organization, or individual, carrying with it an assurance (warranted by a Certification Authority (CA)) that the host computer, organization, or individual is whom they represent themselves to be, and providing an electronic means of verifying that a communication came from that individual, and not from someone else posing as them.
Contains a public key and provides assurance that the key has not been tampered with.

A certificate that is digitally-signed by a CA can be trusted on the basis that a CA will not digitally sign a certificate unless they have adequate proof that the host computer or individual has a right to represent itself by that information.

Account name and password authentication is all that protects access to the VTScada Thin Client Server, unless you use other security mechanisms, such as a virtual private network (VPN)). The web or mobile browser needs to be sure that it is communicating with a legitimate VTScada Thin Client Server before transmitting a name and password. To protect these authentication credentials, Transport Layer Security (TLS) is used, with the VTScada server providing a certificate to the web browser or VIC.

A certificate carries with it a public key that is secure and has not been tampered with. This public key is half of a pair of an asymmetric set of keys. One key is called the private key, while its mate is called the public key. Data encrypted using the private key can only be decrypted using the public key, and data encrypted using the public key can only be decrypted using the private key.

The private key is held securely by the organization that owns the certificate containing the public key (e.g. your organization). No one, not even the CA who issues the certificates knows the private key, rather the CA knows only the public key, and digitally signs the certificate to provide assurance that the public key it holds is the mate to the private key held by the party receiving the certificate.

You must safeguard and keep backups of the private key, as well as the X.509 certificate.

VTScada provides tools to help you generate a request for a certificate from a Certification Authority (such as VeriSign) using the X.509 Certificate tab of the VTScada Thin Client/Server Setup dialog. This request is formed and deposited on your Windows® operating system clipboard. You may then send this request to the CA, either by email, or using an online form (if provided by the CA at their web site). The request is persistently lodged in the VTScada Thin Client Server request store, and when the reply arrives from the CA, the VTScada Thin Client/Server Setup dialog must be used again to process the reply from the clipboard into the server's store. This processing phase removes the request from the request store and places the certificate into the server's certificate store, binding it to the correct private key.

It is highly recommended that you use the Microsoft Management Console (MMC) to backup the certificate and private key. If the registry has to be restored or is lost, the private key will be permanently lost as well. If you do not have a backup of your private key, there is no way to re-generate it. If you irretrievably lose your private key, you will have to purchase a new certificate. Therefore, you should ensure that you store your certificate request and subsequent certificate in PKCS #12 (.PFX) format, and include the private key in the backup.

Before processing a certificate, you must sign in to Windows using an account that has administrative privileges. Make the certificate request on the same PC that will be the VTScada Thin Client Server. After you've done so, you may back up the certificate and copy it to the PC for which the request was made.

The key is encrypted to protect it during the backup process. You are therefore required to enter a password.

Best practices for thin client servers in a DMZ (demilitarized zone)

A VTScada thin client server can support VICs, Anywhere Clients and MICs. The thin client server is a full featured VTScada RPC client that can connect to any other VTScada "thick" server that will accept connections and can also accept inbound connections from a thick server. When RPC communications is established, data flows in both directions over the RPC channel. The thin client can be configured to be "Read-Only" but this only affects tags so that the client can't write tag outputs, but it can still write many other kinds of data to the thick servers.

Given this, the current best practice for deploying a thin client server would be:

Deploy the minimum number of thin client servers that are required for the redundancy \ geographic distribution \ load requirements of the system.
Deploy the thin client servers in a separate firewall zone from the thick clients. The firewall will have to allow TCP access on port 5780 between the thick clients and the thin client servers but this can be restricted to only allow connections to be initiated from the thick client servers.
Consider using a secure channel for the connection between the thick and thin client servers, e.g. IPSec.
Client access to the thin client server (i.e. VIC etc.) should be controlled via firewalls as required in a further zone and protected by TLS as required.
Disable all unused ports on the DMZ server(s). VTScada only requires TCP/5780 for RPC communication, plus whichever port(s) thin client connections use.
Always use TLS connections to thin clients.

Limit Connections to Allow Only Newer Versions of TLS

VTScada uses the SChannel TLS settings provided by the host operating system (Windows), therefore that must be configured to restrict TLS versions that are deprecated. This task cannot be done within VTScada. Refer to the instructions provide by Microsoft at the following URL:https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings

Note that for VTScada as a server (thin client or otherwise) the "Server" settings will be required. To modify client use (that is, when VTScada connects to other TLS servers or when running the VIC) the "Client" settings will be required.