The topic of computer security is a complex and technical one. If you are at all unsure about any of the information provided below please do not hesitate to contact Hansoft support at

Protection of project data

During normal operation the Hansoft client will hold portions of the Hansoft database in memory. When the client is disconnected from the server (for example by the user logging out) the client will save a cache of the database that it holds to disk. This cache is stored on the users hard drive encrypted with AES-256. The encryption key used is provided by the server and is not stored on the users machine. This means that once a user logs out of Hansoft on their machine any information in the Hansoft projects they are a member of is not available to anyone but that user.

Any documents that the user may have downloaded from a Hansoft project are not encrypted.

Connection security

When a Hansoft client connects to a server the following steps take place to ensure the security of the connection:

1) Client connects to the server using SSL (provided by the industry standard OpenSSL library)

1.1) The server proves its identity to the client via its X.509 certificate.

1.2) The client decides whether or not to trust the server by either presenting the certificate to the user or by validating the certificate against the trust store of the client.

1.3) The server can optionally require the client to provide its own certificate to allow the server to verify the identity of the client.

TLS 1.2 is used for the entire session.

All communication between the server and client occurs over this secured connection.

A number of settings on both the server and client machines can be used to control aspects of the connection process. These settings are discussed in the sections "Server security settings" and "Client security settings" below.



Hansoft supports X.509 Base64 encoded DER certificates.

The server will by default automatically generate a self signed certificate for identifying itself to clients. For improved security you can specify your own server certificate, possibly signed by a known and already trusted certificate authority.

As part of verifying a server's identity a client will check that the server's hostname is present in the subjectAltName or subjectCommonName field of the certificate. If you generate your own server certificate ensure that you include the DNS entry for each databases’ hostname in the subjectAltName field to avoid hostname mismatch validation errors when clients connect.

Hansoft supports wildcard hostname matching in certificates.

Version 8.2009 and onwards of Hansoft support the security protocol TLS 1.2.

Refer to the Security section of the Hansoft user manual (available from for information on how the validation process appears in the client.


Replace self sign certificate

The certificate needs to be Base64 encoded to work, once you change the public certificate on the server, you have one minute to put the corresponding private key into the private folder on the server. Once both are in place there will be an entry in the server log to indicate that the security settings have changed.

Hansoft supports Base 64 encoded X509 certificate and keys. To avoid hostname mismatch warnings when clients connect it is important to ensure that the hostname that users connect to is either the common name of the certificate or listed within the subject alternative names.

It doesn't matter what the certificate or key files are called, as long as there is only one file in the Cert folder and one file in the Private folder.

You should not need to restart the server for the new certificate to be used by the server.


Shares and certificates

Tickets for shares also include the public certificate of the server that generated the ticket. This ensures that a server importing a ticket can verify the server they are connecting to.

Note: If a server changes its security settings while a share is connected, the ticket will automatically be exchanged with the other server and the connection re-established. If the shares are disconnected when security settings change you will be required to generate the ticket again (which will now contain the new certificate of the server) and re-import it.


Server security settings

There are four folders that contain certificates that are used to identity itself to clients (Cert and Private) and identify clients (TrusedCerts and CRLStore). These are located in the Security folder, in the same folder as the server executable.

Folder Description
Cert Should contain one file: The public certificate of the server
Private Should contain one file: The private certificate of the server
TrustedCerts Can optionally contain the public certificates of the certificate authorities used to verify client certificates
CRLStore Can optionally contain certificate revocation lists for the certificate authorities specified in the TrustedCerts folder.

If you do not want clients running an older version of SSL to be able to connect and upgrade you can un-tick the appropriate box in the Security Options dialog in the Server Administrator Client.

You can also control whether or not you wish to allow insecure connections from out of date SDKs from within the Security Options dialog. By default insecure connections from out of date SDKs are allowed.

The Hansoft server administrator client.

Change server security window.


Client security settings

There are a number of settings that can be set on the machine the client runs on that can control how the client verifies that the servers they are connecting to are secure.



On Windows these settings should be set in the registry under:

HKEY_CURRENT_USER/Software/Hansoft/Hansoft Project Manager/Client/SecuritySettings/Normal (For the regular client)


HKEY_CURRENT_USER/Software/Hansoft/Hansoft Project Manager/Client/SecuritySettings/ServerAdmin (For the server admin client)



On OS X these settings should be set in ~/Library/Preferences/se.hansoft.Hansoft Project Manager.plist. Settings for the regular client use the prefix: Client.SecuritySettings.Normal. Settings for the server admin client use the prefix: Client.SecuritySettings.ServerAdmin. Consult the "Editing property lists" section on the web page for information on how to edit the settings file.



On Linux the settings are found in ~/.config/Hansoft/Hansoft\ Project\ Manager.conf. If you wish to push these settings out over an enterprise level network please contact support for assistance.




Value of 1: should Hansoft be unable to determine whether a certificate presented to it by a server can be trusted, the user will be shown the certificate sent by the server. The user will be able to decide whether to continue with the connection. This setting also determines whether a user can choose to connect to a server that has identified itself as a Hansoft server that pre-dates certificate authentication support.

Value of 0: the user is not able to make decisions on certificate trust. If Hansoft is unable to verify a certificate, the connection will fail.

This is enabled by default.


This key is only applicable if AllowUserTrustDecisions has a value of 1.

Value of 0: the user is not permitted to allow Hansoft to remember certificates that they have manually trusted in the past.

Value of 1: The user is permitted to allow Hansoft to remember certificates that they have manually trusted in the past. This list can be managed from the Connect options UI within the Hansoft client.

This is enabled by default.


A value ranging between 0 and 9. This determines the limit up to which depth certificates in a chain are used during the verification procedure. If the certificate chain is longer than allowed, the certificates above the limit are ignored.


String consisting of the public certificate used by the client.


String consisting of the private key used by the client.


String consisting of the public certificate of the certificate authority used by the client to verify certificates presented by Hansoft servers.

It is also possible to supply a path to the public certificate of the certificate authority. This value should be added as a registry key named ‘CertificateAuthorityPath’


String consisting of the certificate revocation list of the certificate authority used by the client.

It is also possible to supply a path to the CRL file. This value should be added as a registry key named ‘CertificateRevocationListPath’


A value of 1 indicates that the client should validate that the certificate is valid for the hostname that is being connected to.

This is enabled by default.


A value of 1 indicates that the user is allowed to ignore validation errors such as hostname mismatches and expired certificates.

This is enabled by default.


A value of 1 indicates that the user is allowed to connect to servers that are running an older version of SSL. Setting this to 0 results in the client only being able to connect to servers that are running the same version or newer.

This is enabled by default.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request