Troubleshooting common issues that you may be having with installation and configuration of the 1E Client.

If for any reason you are unable to install, then please review the Requirements.

When installing interactively, please confirm you are logged on using an account that has local Administrator rights.

You can troubleshoot installation issues by reviewing the installation logfile. On Windows, start an Administrative command prompt and use an msiexec command line including a log file as described in: 1E Client 5.0 - Deploying 1E Client on Windows: Installing the 1E Client by command-line.

If your problem is not identified on this page, then please review 1E Client 5.0 - Known issues: Tachyon

Please ensure you have run through the steps in the Tachyon 5.0 - Verifying page.

On this page:

Tachyon client certificate issues

If the Tachyon Server has been configured to require client certificates, Tachyon clients must be running on devices where a valid device certificate has been applied. If this is not the case, the following symptoms will appear:

  • The device where the Tachyon client is running will not be able to connect to the Tachyon Server
  • A warning similar to the following will appear in the Tachyon.Switch.Host.log file (the default location for all the Tachyon Server logs is %AllUsersProfile%\1E\Tachyon folder on the server where Tachyon Server is installed):

    WARN  - Error receiving data from [tachyon.test.local]:4000 : An established connection was aborted by the software in your host machine
  • On the Tachyon client device, you will see an error similar to the following in the 1E.Client.log file (the default location for the Tachyon Agent log is %AllUsersProfile%\1E\Client folder on the device where the agent is installed):

    Received WS message: SwitInfo{"SwitchId":1,"SwitchName":"","WorkerNum":0,"SlotNum":3,"DisconnReason":"No Certificate"}

If you find log entries similar to these appearing in the log files you can check that Tachyon is working correctly for the device by manually requesting a device certificate. If the device can then connect to the Tachyon Server you should contact your network PKI administrator.

Each client/agent in 1E Client uses certificates independently of each other.

Tachyon clients search for a client certificate so they can be authenticated by Tachyon servers.

Nomad clients search for a suitable client certificate so they can be authenticated by CM Distribution Points, and for use with Peer to Peer sharing. They can optionally use Nomad CertIssuer/CertSubject configuration settings to help find suitable certificates.

Shopping and WakeUp clients each have their own CertIssuer/CertSubject configuration settings that determine which client authentication certificate they each use. These are only needed if their websites have a HTTPS binding that is configured to require certificates. 

Manually requesting a device certificate on Windows 10

The following steps show the manual process of requesting a certificate (enrolling) for the computer on which the Tachyon clinet is installed. Although these instructions cover Windows 10 the general approach of using the Certificates MMC snap-in can be extrapolated to cover most Windows Operating Systems.

  1. Run the certificate mmc snap-in. For example, by finding the Manage computer certificates application, as shown in the following picture. 

  1. Doing this displays the certlm MMC snap-in, as shown in the following picture.

  1. Right-click on the Personal folder and select the All Tasks->Request New Certificate... menu option from the right-click menu, as shown in the following picture.

  1. Doing this displays the Certificate Enrollment wizard. On the Before You Begin screen click Next to continue.

  1. On the Select Certificate Enrollment Policy screen select the Active Directory Enrollment Policy option, as shown in the following picture.

  1. On the Request Certificates screen select the Computer certificate checkbox, as shown in the following picture, then click the Enroll button.

  1. The Certificate Installation Results screen shows whether the certificate has been installed correctly. When it has, as shown in the following picture, click Finish to exit the wizard.

  1. Once the wizard has completed you should see the new certificate under the Personal->Certificates folder, as shown in the following example.

Enabling SHA-512 to work with TLSv1.2

Tachyon uses TLSv1.2. On new installations of some Windows OS, SHA-512 is disabled when using TLSv1.2, as described in KB2973337. This means Windows cannot use TLSv1.2 with certificates that have a SHA-512 signature hash algorithm, including those in the certification path (trust chain). 

One method of seeing whether your installation is affected, is when Chrome browser refuses to connect to a website, but Internet Explorer allows the connection. Unlike Chrome, if Internet Explorer cannot use TLS 1.2 it will downgrade to TLS 1.0 or 1.1 if enabled in the Advanced tab of Internet Options. If you disable these check-boxes then Internet Explorer will refuse to connect. This issue occurs only when one or more certificates in the trust chain is using SHA-512 as a signature hash algorithm.

To resolve this, you must install relevant updates on each OS as described in the KB, which may already be installed by Windows Updates. However, you may not have updated a new installation, for example in a lab. The table below is a guide only, and you should read KB2973337 first and apply prerequisite updates. A restart is required after each update.

Windows 10 and later OSNot applicable
Windows 8.1 and Server 2012 R2


KB2919442 then KB2919355

Windows 8 and Server 2012KB2975331KB2993651
Windows 7 and Server 2008 R2KB2973337
Windows XP and Server 2003KB968730

1E Digital Signing Certificates

As described in Common client requirements: Digital signing certificates, the certificate for the root DigiCert High Assurance EV Root CA   must exist in the  Third-Party Root Certification Authorities  store (which is replicated in the Trusted Root Certification Authorities store).

If this certificate is not available on a Windows computer, then the 1E Client will stop shortly after starting up, and the 1E Client log files will show an error similar to the following.

[ 3796] ERROR - Unable to verify signature for 'C:\Program Files\1E\Client\1E.Client.exe'

This root CA certificate is normally automatically provided by Microsoft's Update Root Certificates feature, however this may not be present for legacy OS. You can tell if the root CA certificate is present as follows:

  • view the properties of the 1E.Client.exe file
  • select the Digital Signatures tab
  • select the sha1 signature and click Details (this may take some time to respond while Windows is trying to check the certificate revocation) 
  • click View Certificate
  • select the Certification Path
  • if you do not see DigiCert at the top of the certification path, then you do not have the root CA certificate

Ensure that your Root Certificates are up-to-date. The Update Root Certificates feature is enabled by default on these OS but its configuration may have been changed or restricted by Group Policy Turn off Automatic Root Certificates Update.

If the GPO is being used then you may see DisableRootAutoUpdate = 1 (dword) in HKLM\Software\Policies\Microsoft\SystemCertificates\AuthRoot.

In a lab environment that is not connected to the Internet, you may need to manually import the root CA certificate into the Third-Party Root Certification Authorities store. You can do this by exporting the certificate from a working system, or obtaining the certificate from Symantec

You can distribute certificates to client computers by using Group Policy, as described in