This topic covers the use of encrypted connections to encyclopedias meaning that data passed between the System Architect client application and the database server is encrypted.

In System Architect products, requesting encrypted connections from the client side is supported from version 11.4.5.1.

Use of the Transport Layer Security (TLS) protocol version 1.1 or greater is supported from version 11.4.5.1.

We support SSL (Secure Sockets Layer 2 and 3) and TLS (Transport Layer Security) 1.0, 1.1 and 1.2.

From System Architect 11.4.5.1, the following settings should be made in sa2001.mst.

Without these settings being present, the old SQL OLE DB provider is used and that only supports up to TLS 1.0.

Protocols are controlled in this registry key:

so, for instance, you can have a TLS 1.2 subkey with client and server subkeys and each can contain these DWORDs:

DisabledByDefault(0),
Enabled(0 or 1).

The server subkeys are required only on the server; the client subkeys are required only on the client. The server can be configured with all enabled, then you must restart the SQL Server service. System Architect needed to be restarted after changing these settings for it to be able to browse for and open an encyclopedia. System Architect Encyclopedia Manager (SAEM) did not need to be restarted.

This tells you that by default the protocols are all enabled except for SSL 2.0:

If no security protocol is enabled you get this message on attempting to open a connection: Encryption not supported on the client.

It is supported out of the box in SQL Server 2016. Prior versions require upgrading. All of the relevant material can be found here:

There is a server configuration that can be made to force the use of encryption for all connections. This carries no side-effects and does not require installation of a certificate on the client machine. The following link tells you where to find the configuration, just skip the part about certificates for now:

Without using the above, System Architect applications must be configured to request the use of encryption through the following ini or mst settings:

This setting should be made in the mst file in order for it to apply to SAREST and SAXT. The side-effect is that the server must be specified using the name in the certificate which is usually the fully-qualified domain name of the server. Without so specifying the server name you will generally receive error message target principal name is incorrect or a more general error on connecting to a database.

Connections_UseEncryption_Servern=[full domain name of server]\server name
     For example, Connections_UseEncryption_Server1=myservermachine.mydomain.com\myserver

If this setting is found (the match is not case sensitive) then it means encryption will be requested only for the named servers. If there is no Connections_UseEncryption_Server1 setting then the Connections_UseEncryption setting (see above) determines whether encryption is enabled. The settings are read in number order until a setting is not found, so ensure that the number sequence is contiguous and starts from 1.

When requesting encryption from the client, encryption can only be used with a security certificate installed on the server and the client machine.

On the client machine:

From SAEM you can verify that you have an encrypted connection by executing the following SQL, which returns a TRUE or FALSE value:

From System Architect you can verify that an encrypted connection has been requested by opening Microsoft Visual Basic for Applications: open the Immediate window by pressing Ctrl+G, and type:

and then press return – the connection string value should be presented in the Immediate window.

The connection string should include this:

The following errors can be reported:

It is possible for a user to log in to SAXT as Reader or SAREST when encryption has been requested from the client or the server side when no security protocols are enabled. The responsibility for correct client and server configuration lies with the customer.