...
- 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:
◊ Resetting encryption on one side, either Velocity or SNIB3, but not both
◊ Trying to connect to a SNIB3 that was previously paired with a different Velocity system
◊ Trying to discover a SNIB3 that was previously paired to a different port on the same Velocity system
◊ Switching the protocol of the Velocity port after the TLS connection has been established (so the SNIB3 is listening in TLS mode but Velocity will now try to communicate in a different mode)
◊ Corruption of, manually changing, or deleting the Velocity database that contains TLS-related configuration info
◊ Corruption of the SNIB3’s database storing the trust anchor (highly unlikely)
Check the port’s properties to make sure that the Protocol is set to XNET 3, and the Enable this Port option is checked. You can also try resetting encryption on both the SNIB3 and the Velocity port.
- If you received the Velocity Port event 8517 (SNIB3 failed to authenticate Velocity TLS Certificate), one possible cause is that the SNIB3 was previously connected to a different Velocity server. To solve this problem, reset encryption on both the SNIB3 and the Velocity port.
Another possible cause is that the Velocity server was moved to a different machine. To solve this problem, you must import the VelocityTLS certificate from the Velocity database into the new computer’s Windows Certificates store. The details of that procedure are provided earlier in this document, in the answer to the question about moving a Velocity server to a different machine.
- 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 mode. You may also have to reset the Velocity port encryption if the AES256 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 Velocity connects to a SNIB3 (as indicated by a socket connected message) but nothing further happens, the most likely cause is that the SNIB3 is configured to communicate in TLS mode but encryption was reset on the Velocity port. To solve this problem, reset encryption on the SNIB3.
Another possible cause is that the SNIB3 is configured to communicate in TLS mode but the Velocity port’s Protocol was changed from XNET 3. To solve this problem: disable the port; change the port’s Protocol back to XNET 3; and re-enable the port.
- 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 encryption for the XNET 3 protocol), you will have to reset encryption on both the SNIB3 and the Velocity port.