Certificate requirements
All communication is encrypted, which requires a Public Key Infrastructure (PKI).
You need to have a PKI in your environment with at least one Issuing CA. By default, every 1E Client requires a client authentication certificate.
Client-Switch communication uses WebSocket Secure protocol, whereby each 1E Client establishes a secure link to the Switch, which is then used by the Switch to send instructions to the 1E Client. This is illustrated on the Firewall Ports page.
All other communications from external devices use HTTPS, including 1E Clients connecting to the Background Channel in order to download resources that may be required by instructions, and using the 1E Portal to administer and use the system.
PKI certificates
PKI is required for:
Client authentication certificates - each 1E Client uses the device's client certificate to authenticate itself to 1E Switches
Certificate Revocation Lists (CRLs) - 1E Clients and Switches use HTTP-based CRL Distribution Points to validate certificates
Code signing certificates - used for signing custom and modified instructions, so they can be imported into 1E and then run
Digital signing certificates - used for signing 1E software.
Public Key Infrastructure
You need to have a PKI in your environment with at least one Issuing CA.
1E requires each Issuing CA has:
A Certificate Revocation List (CRL) Distribution Point (CDP) that uses HTTP/S.
This HTTP/S CDP information included in certificates issued to 1E Server and client devices.
PKI notes
If you have an existing PKI and have just added a new CDP to support HTTP/S then you will need to re-issue certificates to your servers and devices.
1E web server deliberately does not work with self-signed certificates for security reasons. Therefore, 1Eservers cannot be installed on the same server as a Root CA, because its certificate is self-signed. For the same reason, 1E Client cannot be installed on a DC unless the client's Switch is configured to not require client certificates.
1E supports TLSv1.2 and TLSv1.3. If your PKI is using SHA512, then please ensure that your environment has relevant updates applied, as described in KB2973337. See Enabling SHA-512 to work with TLSv1.2.
If you want 1E to manage legacy OSs that Microsoft no longer supports, there may be issues with encrypted certificates described in Constraints of Legacy OS.
Note
1E Client and 1E Switches use OpenSSL and its validation process to verify certificates. Websites use Microsoft IIS validation methods.
Client authentication certificates
Note
The 1E Client requires that the client certificate it presents to the platform has both the Signature and Encryption request handling options. These options are the defaults if provisioning using a Computer Certificate template from a Microsoft Windows Certificate Authority. If you are using a custom template, or an alternative certificate authority, you should confirm that both these options are enabled.
If you have configured 1E to require client certificates then each device requires a certificate with the following properties, so the 1E Client can be authenticated by the 1E Switch.
Issued by a trusted Certificate Authority (CA):
The certificate for the Root CA in the Certification Path must exist in the Trusted Root CA store of the client.
If the issuing CA is not the Root CA then the certificate for the issuing CA and any intermediate CA in the Certification Path must exist in the Intermediate CA store of the client.
If either of these CA certificates are different to those used by the 1E Web Server, they will need to be exported and imported on the 1ETachyon Web Server.
Most organizations have automated distribution of these CA certificates to clients and servers, using Group Policy for example.
Has at least the following Enhanced Key Usage:
Client Authentication.
Has at least the following Key Usage:
Digital Signature.
Key encipherment.
Has a private key:
For workgroup and non-Windows devices, the private key must be exportable.
Revocation information is included:
References at least one CRL Distribution point that uses HTTP.
Has a Subject Name of type Common Name (CN=<computername>) or Subject Alternative Name (DNS Name=<computername>) where <computername> depends on the type of device:
On domain-joined Windows PCs this must be the computername FQDN of the computer, for example W701.ACME.LOCAL.
On workgroup Windows PCs and non-Windows devices, this must be the computername of the computer - as returned by the hostname command, for example on Windows PC this could be W701, and on a Mac this could be MAC01.local.
Note
1E clients and Switches use OpenSSL and its validation process to verify certificates.
The client device's certificate is stored differently depending on the type of OS:
Windows: The certificate is stored in the Windows Local Computer personal certificates store.
Non-Windows: Except for the Mac, the Tachyon client does not use proprietary certificate stores. Instead, the client requires the certificate exists as a .pfx file in the client installation folder structure. For more information, please refer to Deploying 1E Client on Linux.
macOS: You have a choice of storing the client certificate in the macOS Key Store or using the .pfx file approach required by other non-Windows devices. Please refer to Deploying 1E Client on macOS.
If using a Microsoft Enterprise CA then the following should be considered:
For domain joined Windows computers:
Use the Computer template or a duplicate.
Enable auto-enrollment - so that devices enroll automatically.
For workgroup Windows and non-Windows devices:
Use a duplicate or equivalent of the Computer or Workstation template.
The template's Subject Name uses supply in the request - so the hostname can be entered when requesting a certificate.
The template must Allow private key to be exported - so a certificate can be requested on a domain joined Windows computer, exported as a .pfx file and then imported on the target device.
If using a standalone CA, then certificates must be deployed by other means.
Code signing certificates
You will need your own code signing certificate, and have it registered in your 1E license, if you want to develop your own custom 1E instructions, or modify those of other authors. Instructions that are provided in the 1E platform zip or downloaded from the 1E Exchange have already been code signed using the Platform and 1E Exchange certificates from 1E. Your 1E license controls whether you can use these instructions.
Ideally, all of your 1E instruction developers should share a single code signing certificate between them. Each code signing certificate must be registered in your 1E license and associated with your organization's instruction name prefix. When you have chosen your prefix and have your code signing certificate(s) you then need to send details of these to 1E, who will update your 1E license. This will then automatically activate on your 1E server (assuming it has connection to the Internet).
The following applies to the importing and running of custom 1E instructions:
For SaaS customers you will need to supply the certificate public key to 1E, and will need the prefix and thumbprint added to your license, contact your 1E account representative for details.
1E platform will only allow instructions to be run if their prefix and code-signing certificate have been registered in the 1E server's license file (even if the instruction has been successfully imported, it will be flagged as unlicensed if the license information is not there).
Custom Instructions must be signed by TIMS using a code-signing certificate present in the Personal certificate store where TIMS is installed (either local user or machine store). The TIMS user signing the Instruction also needs to have access to the certificate's private key.
For a getting started guide to configuring and verifying your 1E system so that you can run customized 1E instructions, refer to Running instructions for the first time.
Digital signing certificates
On Windows computers, the installation MSI files, and binary executable and DLL files of 1E software are digitally signed. The 1E code signing certificate uses a timestamping certificate as its countersignature. 1E occasionally changes its code signing certificate, as shown in the table below, and uses it for new releases and hotfixes for older versions, as shown in the table below.
The signature algorithm of the 1E code signing certificate is SHA256RSA. In most cases, the file digest algorithm of an authenticode signature is SHA256, and the countersignature is a RFC3161 compliant timestamp. The exception is on legacy OS (Windows XP, Vista, Server 2003 and Server 2008) which require the file digest algorithm of an authenticode signature to be SHA1, and a legacy countersignature.
The root CA certificates (for signing and countersigning) must exist in the Third-Party Root Certification Authorities store (which is replicated in the Trusted Root Certification Authorities store). These root CA certificates are normally automatically provided by Microsoft's Update Root Certificates feature, however, this may not be true for legacy OS computers in a lab environment that are not connected to the Internet.
The table below applies to software and hotfixes released in 2020.
2020 | Signing certificate | Timestamping certificates |
|---|---|---|
Certificate | 1E Limited | TIMESTAMP-SHA256-2019-10-15 and DigiCert Timestamp Responder |
Issuing CA | DigiCert EV Code Signing CA (SHA2) Thumbprint: 60ee3fc53d4bdfd1697ae5beae1cab1c0f3ad4e3 | DigiCert SHA2 Assured ID Timestamping CA Thumbprint: 3ba63a6e4841355772debef9cdcf4d5af353a297 and DigiCert Assured ID CA-1 Thumbprint: 19a09b5a36f4dd99727df783c17a51231a56c117 |
Root CA | DigiCert High Assurance EV Root CA Thumbprint: 5fb7ee0633e259dbad0c4c9ae6d38f1a61c7dc25 | DigiCert Assured ID Root CA Thumbprint: 0563b8630d62d75abbc8ab1e4bdfb5a899b24d43 |