Creating CA-Signed Certificates

Optionally, the EFTLink application TLS encryption keys for secure communication between POS client and EFTLink server may be signed by a CA.
From a terminal, run the CreateKeys script file with an appropriate set of parameters to create encryption keys. The parameters are the same as to those used to generate self-signed certificates; however, the first parameter must be specified as -s.

CreateKeys.bat -s <algorithm> <bitlength> <signAlgorithm> <daysValidity> [-dname]

CreateKeys.sh -s <algorithm> <bitlength> <signAlgorithm> <daysValidity> [-dname]

For example:

CreateKeys.bat -s RSA 4096 SHA256withRSA 750

CreateKeys.bat -s RSA 4096 SHA256withRSA 750 -dname

After the encryption keys have been generated, a subdirectory named using the current date and time is created. The contents of the directory depend on the communication method configured for EFTLink, as shown in the examples below.

Mode	File	Description
WebSocket	eftlink.server.p12	EFTLink private keystore (self-signed certificate).
	eftlink.server.csr	Certificate signing request (CSR) for the EFTLink certificate.
	eftlink.client.p12	POS private keystore (self-signed certificate).
	eftlink.client.csr	Certificate signing request (CSR) for the POS certificate.
	`eftlink.keystore.properties`	Properties file containing keystore encryption information.
TCP Socket	eftlink.private.jks	EFTLink private keystore (self-signed certificate).
	pos.private.jks	POS private keystore (self-signed certificate).
	eftlink.private.csr	Certificate signing request (CSR) for the EFTLink certificate.
	pos.private.csr	Certificate signing request (CSR) for the POS certificate.
	eftlink.private.jks.bak	Backup copy of the EFTLink self-signed keystore.
	pos.private.jks.bak	Backup copy of the POS self-signed keystore.
	`comms.keystore.properties`	Properties file containing keystore encryption information.

Files are held in this temporary folder rather than the keys folder as the signing process may take some time, and several sets of signed keys can be handled.

Submit the generated certificate signing request (CSR) files to your Certificate Authority (CA).

WebSocket

eftlink.server.csr

eftlink.client.csr

TCP Socket

eftlink.private.csr

pos.private.csr

In response, your Certificate Authority (CA) should provide the signed certificates and the root certificate used to sign them. The filename may vary depending on the CA.

Configuration Certificates Returned by the CA

WebSocket

Configuration	Certificates Returned by the CA
WebSocket	`eftlink.server.cer.der` (signed certificate for eftlink.server.csr). `eftlink.client.cer.der` (signed certificate for eftlink.client.csr).
TCP Socket	`eftlink.private.cer.der` (signed certificate for eftlink.private.csr). `pos.private.cer.der` (signed certificate for pos.private.csr).

eftlink.server.cer.der (signed certificate for eftlink.server.csr).

eftlink.client.cer.der (signed certificate for eftlink.client.csr).

TCP Socket

eftlink.private.cer.der (signed certificate for eftlink.private.csr).

pos.private.cer.der (signed certificate for pos.private.csr).

In addition, the CA should provide the following certificate chain files:

root.cer - Root certificate used to the sign the certificate chain

intermediate.cer - Once or more intermediate CA certificates, if applicable

Import the signed certificates into the keystores, by placing the signed files and root certificate (plus optional intermediate certificates) in the temporary signing keys folder keys[date] then running the following command.

Createkeys -I <foldername> <root cert> <eftlink signed file> <pos signed file> <(optional) intermediate certificate 1><(optional) intermediate certificate 2>

Signed Files, Root Certificates and Intermediate Certificates
Switch	Parameter	Description	Supported
-e	<foldername>	Temporary keys Subfolder name. Do not provide the full path, just the foldername.	18 character folder name
	<root cert>	The root certificate provided by the CA	Security certificate
	<eftlink signed file>	Signed file returned by CA	Security certificate
	<pos signed file>	Signed file returned by CA	Security certificate
	<intermediate certificate 1>	CA Intermediate certificate	Optional Security certificate
	<intermediate certificate 2>	CA Intermediate certificate	Optional Security certificate

For example, createkeys -i keys20200101010101 ca_root.cer eftlink.private.der.cer pos.private.der.cer ca_intermediate1.cer ca_intermediate2.cer

Archive the temporary keys[date] folder to a safe location as this contains sensitive information.
The following files should be removed from the EFTLink installation directory and placed in the POS keys folder, for example: C:\xstoredata\xstore\keys, or prior to version 22 of xstore in C:\xstore\keys:

pos.private.jks, eftlink.public.jks for TCP socket communication or eftlink.client.jks for WebSocket communication.

After the required files have been moved to the POS client's keys folder, the EFTLink installation keys folder should contain only the following files, depending on the configured communication mode:

WebSocket

eftlink.client.csr

eftlink.keystore.properties

TCP Socket

eftlink.private.csr

pos.public.jks

comms.keystore.properties

Remove the appropriate files from the EFTLink server once they have been transferred to their target systems. This ensures that TLS keys are present only where required, reducing the likelihood of key compromise and the potential for traffic between POS and EFTLink server to be monitored or intercepted.

Note:
From V20 onwards, expiry of TLS certificates is enforced by default. Self-signed certificates will be valid for a maximum of 750 days.
Clear warnings will be placed in log files when certificates are due to expire. Expired certificates will not result in loss of communication between POS and EFTLink.