- 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):
On the Tachyon Agent device you will see an error similar to the following in the Tachyon.Agent.log file (the default location for the Tachyon Agent log is %AllUsersProfile%\1E\Tachyon folder on the device where the agent is installed):
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.
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.
- Run the certificate mmc snap-in. For example, by finding the Manage computer certificates application, as shown in the following picture.
- Doing this displays the certlm MMC snap-in, as shown in the following picture.
- 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.
- Doing this displays the Certificate Enrollment wizard. On the Before You Begin screen click Next to continue.
- On the Select Certificate Enrollment Policy screen select the Active Directory Enrollment Policy option, as shown in the following picture.
- On the Request Certificates screen select the Computer certificate checkbox, as shown in the following picture, then click the Enroll button.
- 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.
- 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.
1E Digital Signing Certificates
As described in Common client requirements: Digital signing certificates, the root signing certificate is DigiCert High Assurance EV Root CA and the root timestamping certificate is DigiCert Assured ID Root CA. These must exist in the Trusted Root Certification Authorities store, which contains a replica of the Third-Party Root Certification Authorities store.
If the relevant certificates are not available on a Windows computer, then the 1E Client will stop shortly after starting up, and the 1E.Client.log file will show an error similar to the following.
This occurs when 1E Client is unable to validate the code signing signature of the executables or libraries. This can happen if one or more of the following is true:
- the trusted root certificate of the countersignature is missing from the Windows Trusted Root Certification Authorities certificate store - this may be because Automatic Root Certificates Update is disabled
- other certificates in the trust path are missing, and Windows is unable to connect to the Internet and dynamically download them during validation.
In either case, the failure to download trusted certificates may be due to the computer being disconnected from the Internet, for example in a lab.
The issue can also affect installation and patching because MSI and MSP files are also countersigned, but that depends on your organizations security policies for software installation.
The issue may not be apparent until after installation, when restarting and not able to connect to the Internet, for example if the computer has been moved into lab.
The root CA certificates are 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
In a lab environment that is not connected to the Internet, the computer may not be able to automatically obtain intermediate CA certificates.
Ensure that your Root Certificates are up-to-date. The Update Root Certificates feature is enabled by default but its configuration may have been changed or restricted by Group Policy. You may see
DisableRootAutoUpdate = 1 (dword) in
If disconnected from the Internet, then manually import the certificates for:
- Root CA into the Third-Party Root Certification Authorities store or Trusted Root Certification Authorities store.
- Issuing CA into the Intermediate Certification Authorities certificate store.
You can distribute certificates to client computers by using Group Policy, as described in https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/distribute-certificates-to-client-computers-by-using-group-policy.
The table below applies to software and hotfixes released in 2020.
TIMESTAMP-SHA256-2019-10-15 and DigiCert Timestamp Responder
DigiCert EV Code Signing CA (SHA2)
DigiCert SHA2 Assured ID Timestamping CA
and DigiCert Assured ID CA-1
DigiCert High Assurance EV Root CA
DigiCert Assured ID Root CA