...
...
The TLS 1.2 encryption protocol is only supported between a SNIB3 communications expansion board and a Velocity server when all of the following conditions are met:
- The Velocity server system is running Velocity version 3.7 SP2 (or later).
- The SNIB3 is running SNIB3 firmware version 2.05.1030 (or later).
- The SNIB3 is the master communications expansion board on a port (and the downstream controllers must all have a SNIB3).The port is Velocity Port must be configured with a Network Type of either IPv4 or IPv6, and the Protocol of XNET 3:
...
- .
- The master and all downstream controller must all have a SNIB3 communications board installed.
NOTE: Downstream controllers connected using a Serial (RS-485) network cannot use TLS.
...
The TLS 1.2 encryption protocol is automatically used when all of the required conditions are met. Otherwise, traditional AES256 AES 256 bit encryption is used for the XNET 3 option.
The XNET 2 protocol (which uses AES128 AES 128 bit encryption) is still available as an option for the SNIB3.
...
Event ID# | Description | Comment |
|---|---|---|
| 8512 | TLS Configuration complete | TLS trust anchors have been established, and Velocity will automatically re-connect using TLS. |
| 8513 | TLS not supported on this port | This SNIB3's firmware does not support TLS. Upgrade it to version 2.05.1030 (or later). |
| 8514 | Socket connected via TLS | The socket has connected, and a TLS handshake will be initiated to establish a secure communication channel. |
| 8515 | TLS Handshake failed | The TLS handshake failed. There can be several reasons for this and the remedy depends on the condition of failure. (See the troubleshooting question later in this document.) |
| 8517 | SNIB3 failed to authenticate Velocity TLS Certificate | Was this SNIB3 previously connected to a different Velocity server? Try resetting the encryption on both the SNIB3 and the Velocity port. |
NOTE: If there is a problem with the Velocity TLS Certificate, the existing general service alarm 5905 will now report: "Unhandled internal error: Velocity TLS Certificate could not be accessed. TLS support disabled". In this situation, Velocity will fall back to using traditional AES256 AES 256 bit encryption for the XNET3 XNET 3 option. However, any SNIB3 previously connected using TLS will need to have its encryption reset, and you will probably also have to reset the encryption within the Velocity port encryptionproperties.
...
How can I tell if TLS is being used?
If TLS is being used, the Port event 8514 (Socket connected via TLS) will appear in Velocity’s Status Event Viewer when an appropriate port comes online.
...
Do I need to do anything special for TLS when moving my Velocity
...
database to a different
...
computer?
Moving your Velocity Server database to a different machine computer will require you to import the VelocityTLS certificate from the Velocity database into the new computer’s Windows Certificates store using the -import switch option of the provided GenerateVelocityTLSCertificate.exe tool. (You must also do this when setting up Velocity in a clustered environment.)
To delete the VelocityTLS certificate added by the installer:
- Open certmgr and go to Local Computer | Personal | Certificates.
- Right click on VelocityTLS and select delete.
To import the VelocityTLS certificate from the Velocity database into the Windows Certificates store:
- Open a command prompt with Administrator privileges (i.e., Run as Administrator).
- Use the cd command to change the directory to the Velocity installation directory (i.e., cd C:\Program Files (x86)\Identiv\velocity).
- Import the VelocityTLS certificate by entering the following command:
GenerateVelocityTLSCertificate –import - Run the GenerateVelocityTLSCertificate.exe tool with -import switch (i.e., C:\Program Files (x86)\Identiv\Velocity>GenerateVelocityTLSCertificate -import)
- Verify that the VelocityTLS certificate was imported to the Local Computer \| Personal \| Certificates store:
...
How can I troubleshoot and fix problems related to TLS?
Problems related to TLS are usually indicated by the generation of a particular event which appears in Velocity’s Status Event Viewer.
- If you received the Velocity Port event 8513 (TLS not supported on this port), upgrade that SNIB3’s firmware to version 2.05.1030 (or later).
- If you received the Velocity Port event 8515 (TLS Handshake failed), something happened to change the trust anchor configuration on the SNIB3 or in Velocity. For example:
...
- If you received the Velocity general service alarm 5905 (stating Velocity TLS Certificate could not be accessed. TLS support disabled) TLS communication will be disabled. Therefore any SNIB3 previously connected using TLS will need to have its encryption reset in order to communicate in AES256 AES 256 mode. You may also have to reset the Velocity port encryption if the AES256 AES 256 bit encryption fails.
This is a rare situation that could result from someone manually editing the Velocity database or the Windows certificate store, or applying a Group Policy that locks down access to Velocity’s TLS certificate.
...
- If you downgrade the firmware of a SNIB3 which previously was communicating with the Velocity server in TLS mode to an older version (such as 2.04.1038), encryption will be broken and the controller will go offline. To get the controller back online (using traditional AES256 AES 256 bit encryption for the XNET 3 protocol), you will have to reset encryption on both the SNIB3 and the Velocity port.