This issue may be caused by the TLS protocol mismatch.

It is caused by a mismatch between the client and server TLS versions. Usually, this problem occurs on the Windows 7 SP1/Windows 2008 Server R2 or below platforms.

The Windows 7 SP1/Windows 2008 Server R2 only support TLS1.0 or below by default.

If the customer sets the agents to use TLS 1.2 to communicate with the server, refer to the Windows Server 2008 R2 section of KB 1117987 to install Windows Update.

To resolve the issue:

1. After the agent has installed Windows Update and the EasyFix, it will add the registry key "DefaultSecureProtocols"=dword:00000a00

   [X86 platform]
   [HKEY_LOCAL_MACHINE\SOFTWARE\\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]

   The key will also be added in:

   [X64 platform]
   [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]

   Reference for this change is the Microsoft article: Update to enable TLS 1.1 and TLS 1.2 as default secure protocols in WinHTTP in Windows

   The registry value is a DWORD bitmap. The value to use is determined by adding the values corresponding to the protocols desired.

   DefaultSecureProtocols Value	Protocol enabled
   0x00000008	Enable SSL 2.0 by default
   0x00000020	Enable SSL 3.0 by default
   0x00000080	Enable TLS 1.0 by default
   0x00000200	Enable TLS 1.1 by default
   0x00000800	Enable TLS 1.2 by default

   • The 0XA80 means enable TLS1.0, TLS1.1 and TLS1.2.
   • The 0XA00 means enable TLS1.1 and TLS1.2.
   • The 0X800 means enable TLS1.2.

2. The user needs to run the Cipher Suites.reg file on the agent to enable TLS1.0, TLS1.1 and TLS1.2.

   Example:

   When the server uses HTTPS to communicates with the agent, it uses the following TLS settings (TLS1.2, for example).

   TA-Server

   • On the Apex One/OSCE server-side, it uses the TLS client setting:

     [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]

   • On the Apex/OSCE agent side, it uses the TLS server setting:

     [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server

   • On the Windows 7 SP1/Windows Server 2008R2 or below endpoint, it depends on the “DefaultSecureProtocols” and “\SCHANNEL\Protocols\TLS 1.x” setting to determine what protocol the agent uses.

   TA-Agent

   When the agent uses HTTPS to communicates with the agent, it uses the following TLS setting (TLS1.2, for example).

   • On the Apex One/OSCE agent-side, it uses the TLS client setting:

     [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]

   • On the Apex/OSCE server side, it uses the TLS server setting:

     [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server

   On Windows 7 SP1/Windows Server 2008 R2 or below endpoint, it depends on the “DefaultSecureProtocols” and “\SCHANNEL\Protocols\TLS 1.x” setting to determine what protocol the agent uses.
    
3. After installing the Windows Update, EasyFix package and Cipher Suites.Reg, you need to restart the machine for it to take effect.
4. After finishing the above 3 steps, if the issue still persists, this may be caused by a certificate mismatch of the agent and the Apex One server. To fix it, refer to the KB article: Ofcsslagent certificate issue detected by the Troubleshooting Assistant for Server tool.

Additional Steps

• Use the Wireshark tool to capture the traffic on the server and agent to analyze the TLS issue.

  The filter is "tcp.port == 'LocalServerPort on the agent' and ip.address == 'agent IP address'" (Case Sensitive)

  For example: “tcp.port == 21112 and ip.addr == 192.168.100.100”

• Refer to the KB article: Potential issues with HTTPS communication in OfficeScan XG Service Pack 1 and Apex One , which introduces how the server and the agent negotiate the TLS version.