Network > Secure Communication

Certificate Management

Each Q-SYS device maintains its certificate and three specific lists of certificates to manage security:

• Trusted certificates: Devices that are allowed to communicate with this device.
• Pending certificates: Devices that have submitted their certificates to this device for approval to communicate.
• Declined certificates: Devices that are explicitly disallowed to communicate with this device.

In addition to certificate management through automatic and manual processes, you can manage all types of certificates. Certificates that meet automatic approval criteria are added to the trusted list, while those requiring manual approval appear on the pending list. Pending certificates can then be manually approved or declined. Certificate management actions include:

• Upload Certificate: This involves either pasting the certificate text or selecting a text file to upload. Only certificates that are considered trusted can be uploaded to the Q-SYS Core, ensuring secure communication.
• Decline Certificate: The action of blocking a certificate deemed to be compromised.
• Remove Certificate: This action involves removing the selected certificate(s).

Mutual Authentication Process

In secure mode two devices can communicate securely if they can mutually authenticate. For two devices to communicate securely:

• The device must find the peer’s certificate on its trusted list.
• The peer must prove ownership of the private key associated with the offered certificate.

Automatic and Manual Certificate Management

• In certain configurations, certificates can automatically be added to the trusted list. By default, the Core’s trusted list includes all Peripheral certificates, and each Peripheral automatically trusts the Core’s certificate (or both in a redundant Core pair). This allows Cores and Peripherals to establish trust seamlessly without user intervention.
• If automatic trust isn’t possible, the peer's certificate is added to the pending list for manual approval by the user. Once a Peripheral’s list includes at least one certificate, it switches to secure mode, restricting communication to only the associated Core.
• Certificates found on, or chaining to those on, the declined list are denied communication capabilities and won’t be added to the pending list.

Management of Redundant Core Pairs

• Cores in a redundant pair must first establish mutual trust with each other.
• Only after mutual trust is established will both Core certificates be shared with Peripherals, allowing Peripherals to trust both Cores.

1. Update the firmware on all Q-SYS devices to version 10.0 (or higher) to support secure communication.
2. Install the required certificates on the Core and Peripherals. If no new certificates are installed, the currently installed ones will be used. Refer to the section Network > Secure Communication for instructions on installing certificates.
3. Set up Access Control of all Cores and all Peripherals. For more details, see Access Management > Users in Core Manager and Device Password in Peripheral Manager.

Note: Since primary and backup (redundant) Cores automatically sync, ensure Access Control is enabled on the backup Core.

4. Configure trust options:
   • Trust On First Usage (TOFU):
     • Peripheral: A Peripheral with TOFU enabled will automatically add a Core's certificate to its trusted list if the list is empty. Once secured, the Peripheral requires manual approval for any new Core certificates via Peripheral Manager.
     • Core: The Core adds each Peripheral's certificate to its trusted list automatically. If a Peripheral device is swapped but retains the same name, manual approval for the new certificate is needed through Core Manager.
   • Rollover: (Disabled in the Core by default). This option, enabled by default on Peripherals but not on the Core, facilitates automatic replacement of certificates, avoiding need for manual approvals when a certificate is updated.

5. Further secure communication of your Q-SYS setup:
• Select 'Control Server Authentication' to enforce certificate-based authentication for server connections. (Note: This may disable control connections from external UCI viewer apps).
• Disable non-authentication supporting network services:
  • Navigate to Network > Services > Management and disable the following services:
    • Q-SYS External Control Protocol - ASCII
    • Q-SYS Remote Control Protocol - JSONRPC
• Consider certificate expiration by checking the 'Verify Validity Period' to block expired certificates from authenticating.
6. Click the 'Enable Secure Communication' button in the Core to initiate secure mode.
7. Ensure secure connections are established between Cores and Peripherals. If automatic trust does not apply, review pending certificates and verify their authenticity by comparing fingerprints. See Certificate Management for more information.

To ensure Core and Peripherals engage in trusted relationship, visit the Troubleshooting section.

Notes:

• Once secure mode is activated, you cannot remove the device password without first disabling secure mode.
• The automatic rollover may fail if device is installed a new certificate while its peer was offline. Manual approval of certificate is required when rollover fails.
• For inter-design communications, manual certificate exchanges are necessary to gaining trust.
• Security configuration options are synced between active and backup Cores: user can change the security configuration in the active Core only. Trusted lists of certificates are synced between active and backup Cores: only the certificates of the currently running design are exchanged between the Cores. At all times the active Core makes sure trusted Peripherals trust the backup Core as well.
• Disabling both TOFU and Rollover is advised if there is any perceived security threat during deployment.
• In a setup with two Cores with Secure Communication enabled on only one, if a peripheral is added to both designs, the Core with Secure Communication will establish connection while the other Core will show: Authentication failure.

1. To disable secure communication, click on the 'Disable Secure Communication' button in the Core settings. This action prompts the Core to attempt to remove its certificate from the Peripherals. By clearing the Peripheral's trusted list, the device will revert to a non-secure mode of communication.
2. If some Peripherals do not switch to the non-secure mode automatically, manually clear their trusted lists. In scenarios where a Peripheral trusts devices beyond the current Core (or redundant Core pair), the current Core will not revoke certificates from the Peripheral. Manually removing trust for the Peripheral may be required, considering its trust relationships with other Cores, to ensure security consistency across different Q-SYS setups.

Note: If planning to downgrade the Q-SYS system to firmware that does not support secure communication, ensure that security mode is disabled in the Core, and all Peripheral trusted lists are cleared. A Core using firmware that does not support secure communication will fail to connect with Peripherals still operating in secure mode.

WARNING: In a redundant system, ensure that primary and secondary core certificates are trusted for stable communication across the system.

When devices don't trust each other a control connection cannot be made. In this case a device's status indicates 'Fault - Authentication Failure'. A Core's log can be examined for the error messages explaining nature of authentication failure with respect to each device. Possible reasons of 'Authentication Failure' status:

• Device has no user password set, secure mode of communication is not available for this device. Please make sure that both redundant Cores have access control enabled and all Peripherals have a user password set.
• Offered certificate is pending manual user approval in the Core or Peripheral. Please use Core Manager and Peripheral Manager of corresponding devices: review the list of pending certificates and approve trust after confirming the certificate’s fingerprint is correct.
• Offered certificate is declined by the Core or the Peripheral. Please review declined certificates in Core Manager and Peripheral Manager of and consider removing declined certificate(s) added there by mistake.
• Offered certificate has expired. Please re-generate and install new certificate in the device with expired certificate.
• Establishing trust with the Peripherals is pending until redundant pair of Core's establish trust with each other. Please make sure redundant pair Cores trust each other. Once trust is established between the Cores this unblocks trust establishment with the Peripherals.