Deploying 1E Client on Linux

Guidance for deploying 1E Client onto Red Hat Enterprise Linux devices, including installation and uninstallation. Only the platform features of 1E Client are available on Linux and other non-Windows OS.

Requirements

• Please review Planning for 1E Client. After installation, please review the Verifying page.

• For details of supported OS platforms, please refer to Common client requirements.

• Guidance provided below is for installation on Red Hat Enterprise.

1E Client does not have a license key. Even so, you must adhere to the terms of your license agreement.

Deployment choices

• You must decide how you will configure the 1E Client and deploy to devices.

• Deploying the 1E Client is normally achieved using your existing software deployment tool.

• For more information about configuring the 1E Client properties during and after installation, please refer to 1E Client configuration settings and installer properties.

Non-Windows installation account

To install the 1E Client on a non-Windows client the installation account must have privileges to run the sudo command.

Certificate files

Each platform client device requires a .pfx certificate file. Please refer to Deploying 1E Client on macOS, for steps to create and use the .pfx file. For Linux devices, the client does not use proprietary certificate stores. Instead, the client requires the certificate exists as a .PFX file in the client installation folder structure.

Each device requires a certificate with the following properties, so the client can be authenticated by the 1E Switch.

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 is different from those used by the 1E Web Server, they will need to be exported and imported on the 1E 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

1E clients and Switches use OpenSSL and its validation process to verify certificates.

Preparation

1E Client installation files are available for download from the 1E Support Portal.

Installation source files for non-Windows are available in a zip file called 1EClient-Non-Windows.vxx.x.x.x.zip.

Installation

The basic command to install an RPM package is rpm -i <package_file>. Although RPM, by design, does not support configuration during installation (with the Linux recommended approach to configure after installation) - the 1E Client does in fact support configuration through the use of environment variables. These can be easily set in a bash command line by one or more space-separated name=value pairs preceding the install command. So, if the RPM package file name is 1e.client-RHEL_8.3_x64_v8.0.4.261.rpm and the 1E Server (assuming that the switch and the background channel are both installed on the 1E Server) has the DNS Name FQDN tachyon.acme.local then the command to run would be:

sudo SWITCH=platform.acme.local:443 BACKGROUNDCHANNELURL=https://platform.acme.local:443/Background/ rpm -i 1e.client-RHEL_8.3_x64_v8.0.4.261.rpm

Please refer to 1E Client configuration settings and installer properties for a list of other configuration properties that can be configured in the same way.

After the package is installed the application configuration files will be installed to the following directory:

/etc/1E/Client

After running the Linux RPM package the client is installed and started as a daemon (service).

The client certificate 1E.pfx and a cacert.pem file are required in the hidden directory: /etc/1E/Client/.sslcerts

If 1E.pfx contains the same certificate trust chain as the 1E Switch, then cacert.pem is optional. This is because the client will have already cached the public certificates when it parses 1E.pfx and cacert.pem will be duplicating the public certificate information. If 1E.pfx is using a different certificate trust chain from the 1E Switch, then cacert.pem is always required.

Reconfiguration

Please refer to 1E Client command-line parameters if you would like to see details of other CLI commands.

Example:

/usr/sbin/1E.Client -reconfigure Switch=ACME-DMZ01.ACME.LOCAL:443 BackgroundChannelUrl=https://ACME-DMZ01.ACME.LOCAL:443/Background/ -restart

Client certificates

Each client device requires its own certificate, which must be created as a .pfx file.

Using OpenSSL to create the .pfx file

Each non-Windows device requires its own certificate. Below is a guide for using a Microsoft CA to issue a certificate (which is the same for Windows computers), then exporting it and using OpenSSL to prepare it before installing it on a non-Windows device.

First, you will need to have created a new Certificate template on your Certificate Authority by making a duplicate of either the Computer or Workstation template and configuring it with at least the following properties:

• General - use a suitable name such as 1E Devices and validity period.

• Request Handling - Allow private keys to be exported.

• Subject Name - Allow information to be supplied in the certificate request, rather than being built from Active Directory information.

• Extensions - Application Policies should contain only Client Authentication.

• Security - ensure relevant users and computers will be able to request certificates.

Once the new template is created on the CA, issue it.

Using the issued template, request a certificate for a target device, and export it in .pfx form and remember the password.

The target device requires a copy of the basic cacert.pem and the .pfx file with its password removed. You can do this using the following steps. Use the relevant OpenSSL version for the OS. OpenSSL is normally available by default on Linux and Mac devices. If you want to follow these steps on Windows, you will need to download the open-source version appropriate to your OS.

1. First, extract the certificate:

   Copy

   openssl pkcs12 -clcerts -nokeys -in <YourPKCSFile>.pfx -out certificate.crt

2. Second, the CA key:

   Copy

   openssl pkcs12 -cacerts -nokeys -in <YourPKCSFile>.pfx -out ca-cert.ca

3. Now, the private key:

   Copy

   openssl pkcs12 -nocerts -in <YourPKCSFile>.pfx -out private.key -passout pass:TemporaryPassword

4. Remove the passphrase:

   Copy

   openssl rsa -in private.key -out new.key -passin pass:TemporaryPassword

5. Put things together for the new PKCS-File (on Windows, type can be used instead of cat):

   Copy

   cat new.key > PEM.pem
   cat certificate.crt >> PEM.pem
   cat ca-cert.ca >> PEM.pem

6. And create the new .pfx file, when prompted for a password ensure that you enter an empty password (that is press enter when prompted for the password and confirmation without entering any text):

   Copy

   openssl pkcs12 -export -nodes -CAfile ca-cert.ca -in PEM.pem -out platform.pfx

Now you have a new PKCS12 key file without a passphrase on the private key part. This 1E.pfx file and the cacert.pem file, must be placed in one of the following locations - depending on the OS. These are hidden folders.

Storing the .pfx on the client

The client certificate file (1E.pfx), and Certificate Authority (CA) certificate(s) for the Switch certificate (cacert.pem file) are stored in the hidden directory:

/etc/1E/Client/.sslcerts

If the client certificate (1E.pfx) uses the same certificate trust chain as the 1E Switch, then cacert.pem is optional. This is because the client will have already cached the public certificates when it parses 1E.pfx.

If the client certificate (1E.pfx) uses a different certificate trust chain from the 1E Switch, then cacert.pem is always required.

Uninstallation

The following command-line can be used to uninstall the 1E Client on Linux:

sudo rpm -e 1e.client

Uninstallation will leave behind files, folders and registry entries that were created after installation: