Secure Hub and Robot

With newer security issues coming up every single day, organizations cannot ignore the focus on the continuous enhancement of their product's security. Understanding the importance of heightened security, CA UIM further enhances its security by allowing its customers to seamlessly move to secure hub and robot. Now, two types of hubs and robots are available—
secure 
and 
non-secure
. Beginning with CA UIM, secure hub (hub_secure) and secure robot (robot_update_secure) are available, which further improve the security in CA UIM. Secure hub and robot provide robust hub-to-hub and robot-to-hub communication. CA UIM 9.0.2 and prior releases ship with the 
non-secure 
hub and robot, which use the legacy security model. 
uim902
secure_hub_robot
With newer security issues coming up every single day, organizations cannot ignore the focus on the continuous enhancement of their product's security. Understanding the importance of heightened security, CA UIM further enhances its security by allowing its customers to seamlessly move to secure hub and robot. Now, two types of hubs and robots are available—
secure 
and 
non-secure
. Beginning with CA UIM, secure hub (hub_secure) and secure robot (robot_update_secure) are available, which further improve the security in CA UIM. Secure hub and robot provide robust hub-to-hub and robot-to-hub communication. CA UIM 9.0.2 and prior releases ship with the 
non-secure 
hub and robot, which use the legacy security model. 
A CA UIM hub serves as the communication center for a group of robots. A hub binds robots into a logical group with the hub as the central connection point. Hubs are typically set up based on a location (such as a lab or a building) or by service (such as development). A hub can connect other hubs into a hierarchy of hubs. CA UIM lets you decide whether you want to use the secure hub and robot setup. You can use the CA UIM upgrade installer to upgrade your existing CA UIM setup to a secure setup. You can do this by selecting the secure option while installing UIM Server. Based on your selection, appropriate configurations are performed in your CA UIM environment.
The following topics cover the required information:
 
 
Introduction
General Architecture
The general architecture applies to both non-secure and secure hubs and robots. Architecturally, a hub is a robot that gains management capabilities through the presence of the 
hub probe
. Configure the probe to modify how the hub handles the following CA UIM services:
  •  
    Message distribution
    Messages from robots are routed through the hub. Messages are routed to other hubs, or dispatched to local subscribers (users and probes).
  •  
    Name service
    The hub translates a 
    /domain/hub/robot/probe
     address into an IP address and port. The service registers TCP/IP addresses at startup. Registration allows applications to connect to the service using TCP/IP.
     This is not applicable for secure hub and robot. In a secure setup, this functionality is achieved by using tunnels.
  •  
    Authentication
    The hub handles logins to the domain.
  •  
    Authorization
    The hub verifies user access rights to probes and the infrastructure (hub, robot, and spooler).
  •  
    Tunneling
    Hub-to-hub tunnels enable secure communication from one site to another site, much like a VPN.
Secure Hub and Robot Architecture
In addition to the general architectural components above, the secure hub and robot:
  • Establish a strong trust relationship between hubs, and between hubs and robots.
  • Proxy the communications to and from all probes, including the hub and controller.
  • Use encrypted, trusted transport.
  • Ensure that probes listen only on the loopback address. Non-encrypted and non-trusted inter-server probe-to-probe communication is prevented.
  • Support third-party certificate authorities and PKI. Self-signed certificates are supported, but are not recommended.
  • Replace the legacy Secure Sockets Layer (SSL) mode, proxy mode, and passive mode.
  • Support mixed-mode implementations. Mixed mode allows non-secure and secure hubs and robots to coexist.
  • Provide secure access to the CA UIM message bus. For example, callbacks above READ level from remote robots are not allowed.
  • Implement enhanced password hashing with the 
    Password Based Key Derivation Function 2
     (PBKDF2) hashing algorithm.
  • Do not support any communication between hub-to-hub without tunnels.
Secure Hub and Robot Version Format
The secure hub and robot package names follow a format that is different from the non-secure ones. Review that the package names have been suffixed with 
_secure
 to distinguish them from the non-secure ones:
  • hub_secure 9.20S
  • robot_update_secure 9.20S
The non-secure hub and robot packages follow the same format that is applicable for the previous releases:
  • hub 9.20
  • robot_update 9.20
Mixed Mode
In large installations, where many hubs connect to many robots, upgrading all the hubs and robots at once is impractical. To avoid a loss of communication during the upgrade, incremental upgrades are supported. Secure hubs can communicate with non-secure robots when the hub_adapter probe is installed on the secure hubs. A mixed-mode environment consists of both secure and non-secure hubs and robots in a CA UIM domain.
The following diagram illustrates an example of mixed-mode implementation.
  •  
    A
      Secure hubs communicate only through tunnels.
  •  
     The controller handles communication between secure hubs and robots. The communication is encrypted.
  •  
     Non-secure hubs and robots continue to use non-encrypted transport.
  •  
     All internal communication between components that are installed on a secure server occur over the loopback.
Mixed_Mode_Secure_NonSecure
Mixed_Mode_Secure_NonSecure
Considerations
Review the following considerations:
 
Existing CA UIM Environment
 
  • Ensure that your existing environment is CA UIM 9.0.2 before you upgrade to secure hub and robot.
  • In an existing CA UIM setup, if your primary hub is not a tunnel server or tunnel client, the 9.2.0 upgrade installer converts the primary hub into a tunnel server (if the secure option is used). Additionally, all other hubs that point to the primary hub are made tunnel clients to that primary hub. It is not ideal to have a primary hub as a tunnel server, but it might be useful in very small environments or for demonstrating proof of concepts (PoCs). However, in production environments, it is recommended that you always make your primary hub as a tunnel client.
 
Hubs and Robots
 
  • In a secure environment, it is recommended that the latest distsrv probe (9.20 or later) is installed on all the hubs that you want to change to secure hub. This helps in recovering from any failure. Once moved to a secure setup, there is a possibility of losing connection with the primary hub. When you have distsrv, you can directly connect to the IM of the failing hub and restore to the older version.
  • To avoid losing connectivity, the tunnel server hub is upgraded first, followed by tunnel client hubs. All hubs require hub-to-hub tunnel connections. Use tunnels for communication between secure hubs, and for communication between non-secure and secure hubs. Static routes between hubs are not supported.
  • The hub_adapter probe is added to a hub before upgrading the hub robot.
  • After making your environment secure, if you want to add more robots or hubs to your secure environment, you can do so. For more information about how you can add a new robot or hub, see the Add a New Robot or Hub to a Secure Environment sections.
  • Tunnel security is enhanced with the secure hub. It is possible to maintain a mixed-mode environment, where some hubs are secure and some are non-secure.
  • A secure hub can communicate with non-secure hub provided both the hubs share the same certificates (for example, signed by the same certificate authority (CA)).
  • Do not install any hub on a Dynamic Host Configuration Protocol (DHCP) client.
  • We recommend that all hubs and robots (pointing to those hubs) use the same certificate authority (CA).
  • The cipher security setting on the tunnel server must be set to High. Otherwise, no communication happens if any hub in the domain is made secure.
  •  distsrv 9.20 has a dependency on robot 9.20/9.20S. During an upgrade, if you try to deploy distsrv before the robot deployment, an error message is displayed stating that the existing robot version is lower than 9.20/9.20S. This error message does not display the suffix "S" in the robot version even if the robot package is a secure package. It simply displays the version without "S", which is misleading. The following error message is displayed: Dependency check error: Robot version >=9.20 is required (7.97 found)
  •  In a 
    non-secure to secure
     upgrade scenario, when you deploy the hub_secure or robot_update_secure packages, an error message is shown that states that the deployment has been aborted. However, the deployment completes without any issue. If you receive this error, you can ignore it.
 
ssl_mode Support (Deprecated)
 
  • The parameter ssl_mode is deprecated. With 9.2.0, by default, SSL communication is enabled between robot and hub through secure bus, if the secure option is selected during the 9.2.0 upgrade. Therefore, secure bus can be considered as an alternative to ssl_mode. If the non-secure option is selected during the 9.2.0 upgrade, ssl_mode will not have any impact.
 
Fully Qualified Domain Names (FQDNs)
 
  • Fully Qualified Domain Names (FQDNs) are required for validation. If short hostnames are used, the validation fails. If Domain Name System (DNS) is not properly configured, you need to explicitly provide FQDNs and create hosts file entries. Ensure that you add FQDNs of UMP, CABI, and other independent robots to the etc/hosts file on the hub from which you are performing the deployment. Similarly, you also need to add FQDNs of the respective hubs to the UMP, CABI, and other independent robots. FQDN name resolutions need to be set in the hosts file on the first line.
 
Package Renaming
 
  • We recommend that you do not rename the package name in the archive. If you rename the package name in the archive and try to deploy the package to the hub after logging into the same hub, an unexpected error can appear. However, deployment is completed correctly. For example, if you rename the robot_update package in the archive and try to deploy it to the hub after logging into that hub, you get the following error: 
    Aborted, retry limit exceeded, unknown status
    , but the deployment happens successfully.
 
Backup
 
  • Back up security.cfg and security.dta before the upgrade.
 
Certificate Package
 
  • The create_robot_cert_package callback has a dependency on the latest version of the distsrv probe or automated_deployment_engine (ade) probe released with 9.2.0. This callback is used to generate the UIMRobotCert package. Ensure that the latest version of distsrv or ade is already deployed to the secure tunnel server hub where you run the callback to create the package. If the latest version of both the probes is available, the callback uses distsrv by default. If distsrv is not available, it uses the ade probe.
 
Infrastructure Manager
 
The following considerations are related to Infrastructure Manager (IM). Infrastructure Manager is a configuration interface for CA UIM. IM is supported only on Windows platforms. Typically, you log in to the primary hub on IM.
  • In a secure CA UIM environment, you can use IM only on a Windows system that is converted to a secure hub. IM can connect to the loopback address (127.0.0.1) of the local system and can navigate to other hubs. This implies that remote IM connections are no longer available.
  • To use IM in a mixed-mode CA UIM domain:
    • If the primary hub is secured, and is 
      non-Windows
      , log in to any non-secure hub in the domain.
    • If the primary hub is secured, and is 
      Windows
      , install IM on the Windows primary hub. Connect to the domain using the Windows loopback IP address of 127.0.0.1.
    • If a secondary Windows hub is secured, install IM on the Windows secondary hub. Connect to the domain using the Windows loopback IP address of 127.0.0.1.
  • To use IM in a secured CA UIM domain:
    • If the primary hub is on a Windows platform, install IM on the Windows primary hub. Connect to the domain using the Windows loopback IP address of 127.0.0.1.
    • If the primary hub is non-Windows, install IM on a Windows secondary hub. Connect to the domain using the Windows loopback IP address of 127.0.0.1.
  • In a secure environment, the 
    Alarm Window
     section (
    View, Alarm Window
    ) does not open in IM. Furthermore, after clicking 
    View, Alarm Window
    , if you refresh your IM (
    View, Refresh
    ), you will lose the connectivity to all the hubs. You must log in again to view all the hubs in IM.
    If you want to view the 
    Alarm Window
     section in a secure environment, you can install IM on a secure (or non-secure) secondary hub and point the alarm window to the primary hub nas. To do so, select 
    Tools, Options
     from the menu bar and then select the primary hub nas option (for example, /<domain_name>/<primary_hub_name>/<primary_hub_robot_name>/nas) from the 
    Alarm Server
     drop-down list.
 
UMP and CABI
 
  • For upgrading your UMP and CABI in a secure setup, ensure that you bring your UMP and CABI robots to the secure state by deploying the appropriate certificates and then updating the version to the secure versions. After that, you upgrade UMP and CABI. 
Upgrade Existing CA UIM Setup to Secure Hub and Robot
If your primary hub is not a tunnel server or tunnel client, the 9.2.0 upgrade installer converts your primary hub into a tunnel server (when the secure option is used). It also converts other hubs that are pointing to that primary hub into tunnel clients. It is not ideal to have a primary hub as a tunnel server, but it might be useful in very small environments or for demonstrating proof of concepts (PoCs). However, in production environments, it is recommended that you always make your primary hub as a tunnel client.
CA UIM 9.2.0 supports the following upgrade scenarios:
  • Existing 9.0.2 Environment Configured without Tunnels 
  • Existing 9.0.2 Environment Configured with Tunnels (Primary Hub as Tunnel Server) 
  • Existing 9.0.2 Environment Configured with Tunnels (Primary Hub as Tunnel Client)  
The process to upgrade your existing CA UIM environment to a secure setup involves the following tasks:
  Secure_Upgrade_Process.jpg  
After securing your setup, if you want to add more robots or hubs to the secure environment at a later stage, you can do so. For more information about how you can add a new robot or hub, see the Add a New Robot or Hub to a Secure Environment sections.
Upgrade Existing 9.0.2 Environment Configured without Tunnels
In this scenario, your existing 9.0.2 environment is not configured with tunnels. The steps are as follows:
  1. Upgrade UIM Server (Primary Hub) 
  2.  Upgrade Secondary Hubs
  3.  Upgrade UMP
  4.  Upgrade CABI
  5.  Upgrade Other Robots
Upgrade UIM Server (Primary Hub)
9.2.0 upgrade installer (UIM Server) provides an option that lets you automatically deploy secure hub and robot binaries to the primary hub in your existing setup. When you run the upgrade installer, you get a secure option to upgrade your existing hub and robot to secure hub and robot. When the upgrade completes, depending on your existing setup, the upgrade performs the appropriate tasks as outlined in this section.
 
Follow these steps:
 
  1. Run the setupCAUIMServer.exe file on the computer where 9.0.2 UIM Server is installed.
    The 
    Upgrade Detected
     screen appears. 
  2. Review the installed version and upgrade version information, and click 
    Next
    .
    The 
    License Agreement
     screen appears.
  3. Review the license information, accept the agreement, and click 
    Next
    .
    The 
    Secure Bus Configuration
     screen appears. You use this screen to provide information that performs secure hub- and robot-related configurations in your environment.
    Secure_Hub_Robot_Options.PNG  
  4. Perform the following actions on this screen to upgrade to secure hub and robot:
    •  
      Enable
      Specifies whether you want to upgrade to secure hub and robot.
      • When this option is selected:
        • The 
          Tunnel Server Configuration
           section is displayed if the existing environment does not have a tunnel setup.
          As no tunnels are configured in this scenario, this section is displayed in the UI.
        • The 
          Tunnel Server Configuration
           section is not displayed if the existing setup is already configured with tunnels.
          For more information about the scenario where tunnel setup is available, see Existing Environment Configured with Tunnels (Primary Hub as Tunnel Server) and Existing Environment Configured with Tunnels (Primary Hub as Tunnel Client).
      • If you do not select the 
        Enable
         option, the normal (non-secure) deployment process is followed.
    •  
      Tunnel Server Configuration
      Lets you specify configuration settings for the tunnel server. This information configures the primary hub as a tunnel server, makes tunnel server as a certificate authority (CA), creates * tunnel certificates.
      •  
        Tunnel Server Port
        Enter the tunnel server port number, and click 
        Test
         to verify the port availability. The default port is 48003.
      •  
        CA/Server Password
         
        Enter the password that you want to use for generating the certificate authority (CA) and tunnel server certificate (CN: IP address).
      •   
        Confirm CA/Server Password
         
        Confirm the password that you entered in the 
        CA/Server Password
         field.
      •  
        Client Password
         
        Enter the password that you want to use for the tunnel client certificate. This password is used to generate the * (wildcard) tunnel client certificates.
      •  
        Confirm Client Password
         
        Confirm the password that you entered in the 
        Client Password
         field.
  5. Click 
    Next
    .
    The 
    Upgrade Preparation
     screen appears.
  6. Enter the password associated with the CA UIM administrator, and click 
    Run Upgrade Preparation
    . During this phase, the following tasks are performed based on the existing setup. More information about these scenarios is explained after the procedure steps:
    1. If the primary hub is configured as a tunnel server in the existing setup, a duplicate of the certificate is copied to the 
      <Nimsoft>\robot\certs
       folder and robot.cfg is appropriately configured with the certificate location.
    2. If the primary hub is configured as a tunnel client in the existing setup, a duplicate of the certificate is copied to the 
      <Nimsoft>\robot\certs
       folder and robot.cfg is appropriately configured with the certificate location.
    3. If no tunnels exist in the existing setup, the primary hub is configured as a tunnel server and all secondary hubs pointing to that primary hub are configured as tunnel clients. A UIMHubRobotCert package is created. This package updates the hub.cfg file on the secondary hubs with the * tunnel certificate, which it places in the 
      <Nimsoft>\hub\certs
       folder. It also updates the robot.cfg file on the secondary hubs with the duplicate of the * tunnel certificate, which it places in the 
      <Nimsoft>\robot\certs
       folder. It applies these configurations with a restart of the secondary hubs.
    When the upgrade preparation is done, the 
    Pre-Install Summary
     screen appears.
  7. Review the information; for example, verify 
    Secure Bus Configuration
     section.
  8. Click 
    Install
     to start the upgrade process.
    When the upgrade process is completed, the 
    Install Complete
     screen appears.
  9. Click 
    Done
    .
In this scenario, when you enable the secure option, the behavior is as follows:
  • The upgrade installer configures primary hub as a tunnel server.
  • The upgrade installer configures all secondary hubs that are pointing to the primary hub as tunnel clients.
  • The upgrade installer makes tunnel server (primary hub) as the certificate authority (CA), creates a tunnel server certificate, and * tunnel client certificate (signed by the created CA) in the 
    <Nimsoft>\hub\certs
     folder. An example snippet is as follows:
    ca.pem
    cert01.pem
    server.ca.ec.cert.pem
    server.ec.cert.pem
    server.ec.key.pem
    ....
  • The upgrade installer updates the tunnel server (primary hub) hub.cfg with the created tunnel server certificates location. An example snippet is as follows:
    <server>
    ...
    ca_location = certs/server.ca.ec.cert.pem
    public_cert = certs/server.ec.cert.pem
    private_key = certs/server.ec.key.pem
    password = +2U4jzflzhj01loXVWQ==
    </server>
  • The upgrade installer updates the tunnel server (primary hub) robot.cfg with the created tunnel certificates location. An example snippet is as follows:
    <controller>
    ...
    proxy_ca_location = C:\Program Files (x86)\Nimsoft\.\hub\certs\server.ca.ec.cert.pem
    proxy_cert = C:\Program Files (x86)\Nimsoft\.\hub\certs\server.ec.cert.pem
    proxy_private_key = C:\Program Files (x86)\Nimsoft\.\hub\certs\server.ec.key.pem
    proxy_private_key_password = +2U4jzflzhj01loXVWQ==
    proxy_check_ip_first = 1
    </controller>
  • The upgrade installer creates a * tunnel client certificate in the tunnel clients (secondary hubs) 
    <Nimsoft>\hub\certs
     folder. An example is as follows:
    client1.pem
    ...
  • The upgrade installer updates the tunnel clients (secondary hubs) hub.cfg with the created certificate location. An example is as follows:
    ...
    cert = certs/client1.pem
    password = +2U4jzflzhj01loXVWQ==
  • The upgrade installer creates the 
    <Nimsoft>\robot\certs
     folder on the tunnel clients (secondary hubs) and creates the * tunnel client certificate in this location. An example snippet is as follows:
    robotclient1.pem
    ...
  • The upgrade installer updates the tunnel clients (secondary hubs) robot.cfg with the created certificate location. An example snippet is as follows:
    <controller>
    ...
    proxy_ca_location = robot/certs/robotclient1.pem
    proxy_cert = robot/certs/robotclient1.pem
    proxy_private_key = robot/certs/robotclient1.pem
    proxy_private_key_password = +2U4jzflzhj01loXVWQ==
    proxy_check_ip_first = 1
    </controller>
  • The upgrade installer deploys the hub_adapter, secure hub, and secure robot to the tunnel server (primary hub).
    The following example screenshot shows that the required secure packages are successfully deployed to the primary hub (which is a tunnel server in this example):
    Secure_primary_hub_tunnel_server
Your primary hub is now secure.
Upgrade Secondary Hubs
After the upgrade installer performs required tasks, you can now configure secondary hubs and make them secure.
 
Follow these steps:
 
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
  2. From the primary hub archive, deploy the hub_adapter probe to the secondary hubs (tunnel clients).
    The following example screenshot shows that the hub_adapter probe is successfully deployed to the secondary hub:
    Hub_adapter_deployed_on_secondary_hub.PNG  
  3. From the primary hub archive, deploy the non-secure robot (7.97 or later) to the secondary hubs (tunnel clients).
    The following example screenshot shows that the non-secure robot is successfully deployed to the secondary hub:
    Robot_non_secure_on_secondary_hub.PNG  
  4. From the primary hub archive, deploy the secure hub to the secondary hubs (tunnel clients).
    The following example screenshot shows the secure hub is successfully deployed to the secondary hub:
    Secure_hub_on_secondary_hub.PNG  
  5. From the primary hub archive, deploy the secure robot to the secondary hubs (tunnel clients).
    The following example screenshot shows the secure robot is successfully deployed to the secondary hub:
    Secure_Robot_on_Secondary_hub.PNG  
  6. From the primary hub archive, deploy the distsrv (9.20 or later) probe to the secondary hubs.
    The following example screenshot shows that the distsrv 9.20 is successfully deployed to the secondary hub:
    Distsrv_on_secondary_hub.PNG  
Your secondary hubs are now secure.
In this upgrade scenario, the 9.2.0 upgrade installer creates a certificate package (UIMHubRobotCert) in the secure tunnel server archive. This certificate package includes * tunnel client certificate .pem files (for 
<Nimsoft>/robot/certs
 and for 
<Nimsoft>/hub/certs
), hub.cfx, and robot.cfx. You can also use this package on other robots if you want to make them secure. However, we recommend that you use the UIMRobotCert package. The reason is that the UIMHubRobotCert package creates the 
<Nimsoft>/hub/certs
 folder on the independent robots, which is not required on the independent robots and might cause confusion.
Upgrade UMP
After upgrading your secondary hubs, you can convert your UMP to a secure state.
 
Follow these steps:
 
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
  2. Use the certificate generation callback on the secure tunnel server hub to create a certificate package (UIMRobotCert) in the local archive of the secure tunnel server. This certificate package contains the * tunnel certificate .pem file and robot.cfx. When you deploy this package, it deploys the certificate .pem file and updates the robot.cfg file with the .pem file location. For more information about how to generate the certificate, see the certificate generation section in this article.
  3. From the primary hub archive, deploy the certificate package (UIMRobotCert) to the UMP robot.
  4. From the primary hub archive, upgrade the UMP robot version to the secure version.
  5. Run the UMP installer to upgrade UMP.
Your UMP deployment is now secure and is upgraded.
Upgrade CABI
You can now upgrade your CABI to the secure state. 
 
Follow these steps: 
 
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
  2. In the primary hub archive, locate the UIMRobotCert package that you have already created and deploy it to the CABI robot.
  3. Upgrade the CABI robot version to the secure version.
  4. Deploy the CABI 4.10 package to the CABI robot.
Your CABI deployment is now upgraded and is secure.
Upgrade Other Robots
If there are other independent robots in your domain that you want to make secure, you can do so. 
 
Follow these steps:
 
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
  2. In the primary hub archive, locate the UIMRobotCert package that you have already created and deploy it to the independent robots.
  3. From the primary hub archive, upgrade the independent robot version to the secure version.
Your independent robots are now secure.
Upgrade Existing 9.0.2 Environment Configured with Primary Hub as Tunnel Server
Your existing environment is configured with tunnels. In this setup, your primary hub is configured as a tunnel server and all other secondary hubs are configured as tunnel clients. The steps are as follows:
  1. Upgrade UIM Server (Primary Hub)
  2. Upgrade Secondary Hubs
  3. Upgrade UMP
  4. Upgrade CABI
  5. Upgrade Other Robots
 Verify that the cipher security setting on the tunnel server is set to High. Otherwise, no communication happens if any hub in the domain is made secure.
Upgrade UIM Server (Primary Hub)
To run the UIM Server upgrade installer, follow the steps as explained in the previous section. As tunnels are already configured in the existing setup, the 
Tunnel Server Configuration
 section is not displayed.
In this scenario, when you enable the secure option, the behavior is as follows:
  1. The upgrade installer does not change the existing tunnel setup. 
  2. The upgrade installer deploys the hub_adapter, secure hub, and secure robot to the primary hub (tunnel server).
    The following example screenshot shows that the required secure packages are deployed to the primary hub (which is a tunnel server in this screenshot and scenario):
    Primary_Hub_Tunnel_Server_Secure.PNG  
Your primary hub is now secure.
Upgrade Secondary Hubs
After the upgrade installer performs required tasks, you can now configure secondary hubs and make them secure.
 
Follow these steps:
 
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
    The following example screenshot shows the login to the IM on the secure primary hub using the loopback IP address:
    Secure_Primary_Hub_Login.PNG
    You can see all your secondary hubs listed because tunnels are already configured.
    The following example screenshot shows that a secure primary hub (tunnel server) and non-secure secondary hub (tunnel client) are listed in the IM after the login on the secure primary hub:
    Primary_Hub_Second_Hub_Listed.PNG  
  2. From the primary hub archive, deploy the hub_adapter probe to the secondary hubs (tunnel clients).
    The following example screenshot shows that the hub_adapter probe is successfully deployed to the secondary hub:
    Hub_Adapter_on_Secondary_Hub.PNG  
  3. From the primary hub archive, deploy the non-secure robot (7.97 or later) to the secondary hubs (tunnel clients).
    The following example screenshot shows that the non-secure robot is successfully deployed to the secondary hub:
    NS_Robot_on_Secon_Hub.PNG  
  4. From the primary hub archive, deploy the secure hub package to the secondary hubs (tunnel clients).
    The following example screenshot shows that the secure hub is successfully deployed to the secondary hub:
    Secure_Hub_on_Second_Hub.PNG  
  5. From the primary hub archive, deploy distsrv 9.20 to the secondary hubs.
    The following example screenshot shows that distsrv 9.20 is successfully deployed to the secondary hub:
    Distsrv_on_Second_Hub.PNG  
  6. Use the robot certificate callback on the secure tunnel server hub to create a certificate package (UIMRobotCert). This certificate package contains the * tunnel certificate .pem file and robot.cfx. When you deploy this package, it deploys the certificate .pem file and updates the robot.cfg file with the same .pem file location.
    The following example screenshot shows that the UIMRobotCert package is successfully created in the secure tunnel server archive (which is a primary hub in this scenario):
    Certificate_Package_in_Archive.PNG  
  7. From the primary hub archive, deploy the certificate package (UIMRobotCert) to the secondary hub robots, UMP robot, CABI robot, and other independent robots.
    The following example screenshot shows that the UIMRobotCert package successfully created a certificate .pem file in the ..\Nimsoft\robot\certs folder:
    Robot_Client_Certificate.PNG  
  8. From the primary hub archive, deploy the secure robot package to secondary hub robots.
    The following example screenshot shows that the secure robot package is successfully deployed to the secondary hub:
    Secure_Robot_on_Secondary_hub.PNG  
Your secondary hubs are now secure.
Upgrade UMP
After upgrading your secondary hubs, you can secure your UMP deployment.
 
Follow these steps:
 
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
  2. From the primary hub archive, upgrade the UMP robot version to the secure version.
  3. Run the UMP installer to upgrade UMP.
Your UMP deployment is now secure and is upgraded.
Upgrade CABI
You can now upgrade your CABI to the secure state. 
 
Follow these steps: 
 
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
  2. From the primary hub archive, upgrade the CABI robot version to the secure version.
  3. Deploy the CABI 4.10 package to the CABI robot.
Your CABI deployment is now upgraded and is secure.
Upgrade Other Robots
If there are other independent robots in your domain that you want to make secure, you can do so. 
 
Follow these steps:
 
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
  2. From the primary hub archive, upgrade the robot version to the secure version.
Your independent robots are now secure.
Upgrade Existing 9.0.2 Environment Configured with Primary Hub as Tunnel Client
Your existing environment is configured with tunnels. In this setup, your primary hub is configured as a tunnel client, one of the secondary hubs is configured as a tunnel server, and remaining secondary hubs are configured as other tunnel clients.  The steps are as follows:
  1.  Upgrade UIM Server (Primary Hub)
  2. Upgrade Secondary Hubs
  3. Upgrade UMP
  4. Upgrade CABI
  5. Upgrade Other Robots
 Verify that the cipher security setting on the tunnel server is set to High. Otherwise, no communication happens if any hub in the domain is made secure.
Upgrade UIM Server (Primary Hub)
To run the UIM Server upgrade installer, follow the steps as explained in the previous section. As tunnels are already configured in the existing setup, the 
Tunnel Server Configuration
 section is not displayed.
In this scenario, when you enable the secure option, the behavior is as follows:
  1. The upgrade installer does not change the existing tunnel setup. It duplicates the certificate used in the tunnel client configuration in the primary hub and places it in the ..\
    Nimsoft\robot\certs
     folder. The robot is configured to use that certificate.
  2. The upgrade installer deploys the hub_adapter, secure hub, and secure robot to the primary hub (tunnel client). 
Your primary hub is now secure. The following example screenshot shows that the secure packages are deployed to the primary hub (which is a tunnel client in this screenshot):
  Primary_Hub_Secure.PNG  
Upgrade Secondary Hubs
After the upgrade installer performs required tasks, you can now configure secondary hubs and make them secure. One of the secondary hubs is a tunnel server in this scenario.
 
Follow these steps:
 
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP). The following example screenshot shows the primary hub IM login using the loopback IP:
    Primary_Hub_Loopback_Login.PNG
    You should be able to see all your secondary hubs listed because tunnels are already configured. The following example screenshot shows the non-secure secondary hub (which is a tunnel server in this screenshot) and the secure primary hub after the IM login:
    Phub_Shub_Listing.PNG  
  2. From the primary hub archive, deploy the hub_adapter probe to the secondary hubs.
    The following example screenshot shows that the hub_adapter probe is successfully deployed to the secondary hub:
    Hub_Adapter_on_Sec_hub.PNG  
  3. From the primary hub archive, deploy the non-secure robot (7.97 or later) to the secondary hubs.
    The following example screenshot shows that the non-secure robot is successfully deployed to the secondary hub:
    NS_Robot_on_Sec_Hub.PNG  
  4. Deploy the secure hub to the secondary hubs.
    The following example screenshot shows that the secure hub is successfully deployed to the secondary hub:
    Secure_hub_on_SecHub.PNG  
  5. Deploy distsrv 9.20 to the secondary hubs.
    The following example screenshot shows that distsrv 9.20 is successfully deployed to the secondary hub:
    Distsrv_on_Sec_hub.PNG  
  6. Connect to IM from any Windows computer by using the normal IP of the tunnel server.
  7. Use the robot certificate callback on the secure tunnel server hub to create a certificate package (UIMRobotCert). This certificate package contains the * tunnel certificate .pem file and robot.cfx. When you deploy this package, it deploys the certificate .pem file and updates the robot.cfg file with the same .pem file location.
    The following example screenshot shows that the UIMRobotCert package is successfully created and added to the secure tunnel server (secondary hub) archive:
    Cert_Package_in_Archive.PNG  
  8. From the tunnel server archive, deploy this certificate package to the secondary hub robots, UMP robot, CABI robot, and independent robots.
    The following example screenshot shows that a robot certificate .pem file is successfully created in the ..\Nimsoft\robot\certs folder on the secondary hub:
    Robot_Certificate_on_Sec_Hub.png  
  9. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
  10. From the primary hub archive, deploy the secure robot package to secondary hubs.
    The following example screenshot shows that the secure robot is successfully deployed to the secondary hub:
    Secure_Robot_on_SecHub.PNG  
Your secondary hubs are now secure.
Upgrade UMP
After upgrading your secondary hubs, you can convert your UMP to a secure state.
 
Follow these steps:
 
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
  2. From the primary hub archive, upgrade the UMP robot version to the secure robot version.
  3. Run the UMP installer to upgrade UMP.
Your UMP is now upgraded and is secure.
Upgrade CABI
You can now upgrade your CABI to the secure state. 
 
Follow these steps: 
 
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
  2. From the primary hub archive, upgrade the CABI robot version to the secure version.
  3. Deploy the CABI 4.10 package to the CABI robot.
Your CABI is now upgraded and is secure.
Upgrade Other Robots
You can now upgrade other independent robots to the secure state. 
 
Follow these steps:
 
  1. Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
  2. From the primary hub archive, upgrade the independent robot version to the secure version.
Your independent robots are now secure.
Existing 9.0.2 Environment Configured with Partial Tunnel Setup
 It is not ideal to have a primary hub as a tunnel server, but it might be useful in very small environments or for demonstrating proof of concepts (PoCs). However, in production environments, it is recommended that you always make your primary hub as a tunnel client.
A partial tunnel setup implies all the hubs in your existing setup are not communicating through tunnels. Consider a scenario where tunnels are configured only on the secondary hubs and not on a primary hub. In this case, when you run the 9.2.0 upgrade installer by using the secure option, your primary hub will be made a tunnel server and all other secondary hubs that point to the primary hub will become tunnel clients to the tunnel server (primary hub). 
Therefore, to work in this type of scenario, you must manually configure tunnels in your environment so that one of the secondary hubs in the domain is configured as a tunnel server and all other hubs as tunnel clients to that hub (tunnel server). After that, you use the 9.2.0 upgrade installer as you do in the case where tunnels are already configured in the setup and primary hub is a tunnel client.
Generate Certificate Package
Use the 
create_robot_cert_package
 hub callback on the 
secure tunnel server
 to generate a * (wildcard) certificate package. The callback creates the certificate package (UIMRobotCert) and places it in the secure tunnel server archive. This package includes a * certificate .pem file (client#.pem) and robot.cfx file.
Deploy this package to the required non-secure robot (for example, tunnel client robot, independent robot, UMP robot, CABI robot) that you want to secure. When you deploy this certificate package to a robot that you want to secure, the package deploys the * certificate .pem file in the 
<Nimsoft>\robot\certs
 folder and updates the robot.cfg file with the .pem file location. 
 Ensure that the latest version of the distsrv probe or ade probe (released with 9.2.0) is already deployed to the secure tunnel server for this callback to work properly. If the latest version of both the probes is available, the callback uses distsrv by default. If distsrv is not available, it uses the ade probe.
 
Follow these steps:
 
  1. Open the probe utility (pu) for the secure tunnel server hub.
  2. Select the 
    create_robot_cert_package
     callback from the drop-down list as shown in the following screenshot:
    Certification_Package_Creation.png  
  3. Provide appropriate information for the following parameters:
    1.  
      countryName
       (Optional)
    2.  
      stateOrProvince
      (Optional)
    3.  
      localityName
      (Optional)
    4.  
      organizationName
      (Optional)
    5.  
      emailAddress
      (Optional)
    6.  
      commonName
       (Mandatory)
      Specify the common name as * (wildcard) to generate a * tunnel certificate.
    7.  
      days
       (Mandatory)
      Specify the validity of the certificate.
    8.  
      password
       (Mandatory)
      Specify the password for the certificate.
     If you try to run this callback without providing values for the mandatory parameters (
    commonName
    days
    , and 
    password
    ), the callback displays the invalid argument error.
  4. Run the command request.
    When the command is successfully completed, the robot client certificate package (UIMRobotCert) is created and is added to the secure tunnel server archive. 
  5. Deploy this certificate package to the robots that you want to secure.
Add a New Robot to a Secure Environment
If you want to add a new robot to a secure environment, you can use the appropriate method depending on your requirements:
  • Add a Robot Without Using a Non-Secure Secondary Hub
  • Add a Robot Using a Non-Secure Secondary Hub
  • Add a Robot Using UMP 
  • Add a Robot Using an XML File 
Add a Robot Without Using a Non-Secure Secondary Hub
You can directly add a robot to the secure setup.
 This procedure is not applicable for Linux. For Linux, you must have a non-secure secondary hub in your secure setup. Therefore, for Linux, see the Add a Robot Using a Non-Secure Secondary Hub section.
 
Follow these steps:
 
  1. Ensure that the secure hub to which you want to add a new robot already has hub_adapter enabled on it.
  2. Download the robot installer (NimBus Robot.exe) from the CA UIM home page.
  3. Run the robot installer on the computer to install the robot. Provide information about the required secure hub to which you want to add the robot.
  4. Deploy robot 9.20 (7.97 or later).
  5. On the secure tunnel server, use the robot certificate callback and generate the robot certificate package, if not already done.
  6. Deploy the robot certificate package to the robot computer.
  7. Deploy the secure robot to the robot computer.
    Non-secure robot is now converted to a secure robot.
Add a Robot Using a Non-Secure Secondary Hub
You can use a non-secure secondary hub in your secure environment to add a new robot. 
 For Linux, you must have a non-secure secondary hub in your secure setup. Also, ensure that the required package (install_LINUX_23_64) is already available in the non-secure secondary hub archive.
 
Follow these steps:
 
  1. Download the robot installer (nimldr or NimBus Robot.exe) from the CA UIM home page to the computer that you want to add as a robot.
  2. Run the robot installer on the computer to install the robot. Provide information about the required non-secure secondary hub during the robot installation.
    The following example screenshot shows that the nimldr is executed successfully and deploys the new robot:
    rob3 - Copy.PNG  
  3. Deploy robot 9.20 (7.97 or later).
    The following example screenshot shows that the non-secure robot is successfully deployed to the new robot computer:
    rob4 - Copy.PNG  
  4. Move the robot to the appropriate secure hub in your environment.
    The secure hub must be able to communicate with the non-secure robot because of the presence of hub_adapter on the secure hub.
    The following example screenshot shows that the new robot is successfully moved to the secure hub:
    rob5 - Copy.PNG  
  5. On the secure tunnel server, use the robot certificate callback and generate the robot certificate package, if not already done.
  6. Deploy the robot certificate package to the robot computer.
  7. Deploy the secure robot to the robot computer.
    Non-secure robot is now converted to a secure robot.
Add a Robot Using UMP
In this scenario, you use UMP in your secure environment to add a robot. Ensure that the hub_adapter probe is active on the secure hub. This allows the secure hub to communicate with the non-secure robot.
 
Follow these steps:
 
  1. In your secure environment, log in to UMP.
  2. Start the Discovery Wizard and locate the device that you want to convert to a secure robot.
  3. Select the device and deploy the non-secure robot (9.20).
    The non-secure robot is deployed in the secure setup and is visible in IM and Admin Console.
  4. On the secure tunnel server, use the robot certificate callback and generate the robot certificate package, if not already done.
  5. Deploy the robot certificate package to the robot computer.
  6. Deploy the secure robot to the robot computer.
    Non-secure robot is now converted to a secure robot.
Add a Robot Using an XML File
In this scenario, you use an XML file in your secure environment to add a robot. Ensure that the hub_adapter probe is active on the secure hub. This allows the secure hub to communicate with the non-secure robot.
 
Follow these steps:
 
  1. In your secure environment, ensure that the automated_deployment_engine (ade) probe that is released with 9.2.0 is running on the secure primary hub.
  2. Navigate to the 
    <Nimsoft>\probes\service\automated_deployment_engine
     folder.
  3. Create an XML file and provide all robot-related details (for example, user name, password, computer details, hub information). 
  4. Save the file with the name as host-profiles.xml in the 
    <Nimsoft>\probes\service\automated_deployment_engine
     folder.
    The ade probe checks the XML file and deploys the non-secure robot (9.10). The non-secure robot becomes visible in IM and Admin Console.
  5. On the secure tunnel server, use the robot certificate callback and generate the robot certificate package, if not already done.
  6. Deploy the robot certificate package to the robot computer.
  7. Deploy the secure robot 9.10S to the robot computer.
    Non-secure robot is now converted to a secure robot.
An example of an XML file is as follows:
<hosts>
<host>
<profile>Windows</profile>
<arch>64</arch>
<hostname>10.xxx.xxx.xxx</hostname>
<username>Administrator</username>
<password>in#4572</password>
<domain>uimser01_domain</domain>
<hubip>10.xxx.xxx.xxx</hubip>
<hub>uimser01_hub</hub>
<hubrobotname>uimser01</hubrobotname>
<hubport>48002</hubport>
<robotname>talsec_robot</robotname>
<tempdir>c:\tmp</tempdir>
</host>
</hosts>
Add a New Hub to a Secure Environment
If you want to add a new hub to a secure environment, you can use the appropriate method depending on your requirements:
  • Add a New Hub Without  Using a Non-Secure Secondary Hub
  • Add a New Hub Using a Non-Secure Secondary Hub 
Add a Hub Without Using a Non-Secure Secondary Hub
You can directly add a hub to the secure setup.
This procedure is not applicable to Linux. For Linux, you must have a non-secure secondary hub in your secure setup. Therefore, for Linux, see the Add a New Hub Using a Non-Secure Secondary Hub section.
 
Follow these steps:
 
  1. Download the secondary hub installer (NimBUS Infrastructure.exe) from the CA UIM home page to the system that you want to add as a hub.
  2. Run the installer to install the secondary hub on the system. Provide the domain name to which you want to add this hub.
  3. Copy the tunnelsetup.exe utility and the client certificate from the secure tunnel server. The tunnelsetup.exe utility is available in the 
    ..\Nimsoft\hub
     folder. The client certificate is available in the 
    ..Nimsoft\hub\certs
     folder.
  4. Run the tunnelsetup.exe on the new hub and provide all the details (for example, tunnel server IP, CA UIM administrator credentials, and certificate path).
    An example screenshot is as follows:
    tunnelset.exe.png  
     Alternatively, you can use IM on this new hub to make it a tunnel client of the secure tunnel server. To do so, you copy the certificate from the secure tunnel server and create a tunnel client certificate on the new hub.
  5. Open the hub configuration, navigate to the 
    Status
     tab (
    Tunnel Status
     section) and verify that the tunnel connection is up and running.
    The new non-secure hub is now listed in the domain.
  6. Follow the usual steps (as explained earlier) to bring the new hub to a secure state depending on your scenario:
    1. Deploy hub_adapter to the new hub.
    2. Deploy robot 9.20 (7.97 or later) to the new hub.
    3. Deploy secure hub to the new hub.
    4. Deploy the robot certificate package to the robot.
    5. Deploy the secure robot to make it a secure robot.
    You have successfully added a new hub and secured it.
Add a Hub Using a Non-Secure Secondary Hub
You can add a new hub to a secure setup by using a non-secure secondary hub, which is already present in the secure setup. 
 For Linux, you must have a non-secure secondary hub in your secure setup. Also, ensure that the required package (install_LINUX_23_64) is already available in the non-secure secondary hub archive.
 
Follow these steps:
 
  1. Download the secondary hub installer (nimldr or NimBUS Infrastructure.exe) from the CA UIM home page.
  2. Run the installer to install the secondary hub on the new system. Provide the required non-secure secondary hub information during the robot installation. For Linux, ensure that you make the new hub a tunnel client during the hub installation.
    The following example snippet shows that nimldr is being used to install the hub as a tunnel client:
    hub2 - Copy.PNG  
  3. For Windows, perform the following steps to make the new hub as a tunnel client (already explained in the previous procedure):
    1. Copy the tunnelsetup.exe utility and the client certificate from the secure tunnel server. The tunnelsetup.exe utility is available in the 
      ..\hub
       folder. The client certificate is available in the 
      ..\hub\certs
       folder.
    2. Run the tunnelsetup.exe on the new hub and provide all the details (for example, tunnel server IP, CA UIM administrator credentials, and certificate path). 
    For Linux, the new hub is made the tunnel client during the hub installation.
  4. Open the hub configuration, navigate to the 
    Status
     tab (
    Tunnel Status
     section) and verify that the tunnel connection is up and running.
    The following example screenshot shows the successful tunnel communication between the new hub (talki-robot2) and the secure primary hub:
    hub5 - Copy.PNG  
  5. Follow the usual steps (as explained earlier) to bring the new hub to a secure state depending on your scenario:
    1. Deploy hub_adapter to the new hub.
    2. Deploy robot 9.20 (7.97 or later) to the new hub.
    3. Deploy secure hub to the new hub.
    4. Deploy the robot certificate package to the robot.
    5. Deploy the secure robot to make it a secure robot.
    You have successfully added a new hub and secured it.
Converting Back to a Non-Secure Mode
To revert your secure environment to the non-secure state, you must downgrade all the robots and hubs in your secure environment by downloading and installing an older version of the robot and hub from the archive. Based on your setup, you can downgrade robots and hubs as follows:
  1. If your secure environment consists of standalone robots that are connected to a secure hub, then you must first downgrade all the standalone robots to an older version that you downloaded from the archive.
  2. After you downgrade standalone robots, downgrade the robots running on the secure hub to an older version that you downloaded from the archive.
  3. After you downgrade all the robots, downgrade the hubs to an older version that you downloaded from the archive.
Enable CABI and UMP to Communicate Securely from Separate Secure Robots
To enable CABI and UMP to communicate securely from separate secure robots, follow these steps:
  1. Whitelist the IP subnets where UMP and cabi are running by using the existing probe administration UI in IM.
    This configuration ensures that the secure bus understands that wasp and CABI on these subnets can be trusted by the bus.
    UMP CABI Communication 01.png  
  2. Using pu, use the hubsec_setup_put callback on the primary hub to add the IPs of the UMP robot and CABI robot as “trusted_ips” in the security.cfg file of the hub. Use a comma-separated list.
    This configuration ensures that the secure bus understands that these are special robots, and user logins from these robots must be allowed without downgrading access.
    UMP CABI Communication 02.png  
  3. Restart the primary hub, restart UMP, wait until UMP is fully up, and then restart CABI.
Known Issues
The following are the secure hub- and robot-related known issues:
  • The ppm probe provides functionality for the Admin Console probe configuration UIs. The ppm probe does not run on AIX hubs. To configure robots and probes on AIX hubs, use the Raw Configure utility in Admin Console, or use Infrastructure Manager.
  • If the communication with a robot fails in Linux, review your network configuration:
    1. A valid entry for the local system in the 
      /etc/hosts
       file for a robot, hub, server, or UMP system
    2. The entry for the local system must be a fully qualified hostname and IP address.
    3. If only the loopback address is defined, for example, localhost 127.0.0.1, the controller is unaware of its own IP address.
    4. IP address problems result in network communication failure.
  • The automated_deployment_engine robot distribution to Windows targets sometimes fails to activate the hdb and spooler probes. To resolve the issue, do a validate security on the affected probes (hdb and spooler)
  • If robots are added to the inventory by automated discovery, USM cannot auto-deploy the robots to AIX or z/Linux systems. Use one of the following alternative methods:
    1. Run the native installer manually or with a third-party tool. See Deploy Robots in Bulk with a Third-Party Tool and Native Installers.
    2. Use the automated_deployment_engine (ade) probe with an XML file. See Deploy Robots with an XML File and the ADE Probe.
    3. Import an XML file in USM. See Deploy Robots with an XML File in USM.
  • In a secure environment, if any probe that is installed on an independent secure robot tries to subscribe to queues in the related secure hub, the probe fails to attach to the queues. As a workaround, if the probes require to read or publish to a hub queue, then deploy the probe to the primary hub robot.
  • If you rename the package name in the archive and try to deploy the package to the hub after logging into the same hub, an unexpected error can appear. However, deployment is completed without any issue. For example, if you rename the robot_update package in the archive and try to deploy it to the hub after logging into that hub, you get the following error: 
    Aborted, retry limit exceeded, unknown status
    , but the deployment happens successfully.
  • In a 
    non-secure to secure
     upgrade, when you deploy the new hub_secure or robot_update_secure packages, an error message is shown that states that the deployment has been aborted. However, the deployment completes without any issue. If you receive this error, you can ignore it. 
  • distsrv 9.20 has a dependency on robot 9.20/9.20S. During an upgrade, when you try to deploy distsrv before the robot deployment, an error message is displayed stating that the existing robot version is lower than 9.20/9.20S. This error message does not display the suffix "S" in the robot version if the robot package is a secure one. It simply displays the version without "S", which is misleading. The following error is displayed: Dependency check error: Robot version >=9.20 is required (7.97 found) 
  • In a secure hub and robot setup, the Relationship viewer portlet does not work. The portlet is visible in UMP, but it does not fetch any data. The wasp probe tries to communicate with the hub and stops after five unsuccessful attempts. During this process, it throws communication errors in the wasp log.
Additional Information
  •  
    Manual Upgrade Process
     
    If you do not upgrade to secure hub and robot using the 9.2.0 upgrade installer (UIM Server) and want to do it at a later stage, you can follow the manual process. However, we recommend that you use the upgrade installer as it automatically performs various tasks and significantly eases the secure upgrade process. For more information about how to perform these manual steps to upgrade to secure hub and robot, follow the information documented in Manually Upgrade to Secure and Hub
  •  
    Troubleshooting
    To review various troubleshooting topics, see the Troubleshooting Secure Hub and Robot article.