Skip to main content

1E 23.11 (SaaS)

Certificate requirements

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 shown as a dotted line in the pictures in 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.

All communication is encrypted, which requires a Public Key Infrastructure (PKI).

PKI certificates

PKI is required for:

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.

1E_Client_-_certificate_options.png

If you have configured 1E to require client certificates (Client certificates) then each device requires a certificate with the following properties, so the 1E Client can be authenticated by the 1E Switch.Client certificates

  1. 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.

  2. Has at least the following Enhanced Key Usage:

    • Client Authentication.

  3. Has at least the following Key Usage:

    • Digital Signature.

    • Key encipherment.

  4. Has a private key:

    • For workgroup and non-Windows devices, the private key must be exportable.

  5. Revocation information is included:

    • References at least one CRL Distribution point that uses HTTP.

  6. 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:

  • For Windows devices, the certificate is stored in the Windows Local Computer personal certificates store.

  • For non-Windows devices, 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 Client certificates.

  • For 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 Client certificates.Client certificates

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 (see non-Windows Device Certificate).Certificate requirements

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:

  • 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