Skip to main content

Encryption Overview

`CenterScape as well as RF Code M250 readers support various encryption configurations in the various ways data is sent over the network. By default, CenterScape and each M250 reader include a self signed certificate and a keystore that includes known public encryption authorities similar to what would ship on operating systems such as windows and Linux. The private keys and self signed certificates on both the readers and CenterScape can be replaced with a publicly signed certificate or with an internally signed certificate provided by a corporate certificate authority. Additionally, certificate authority (CA) certificates can be added to the CenterScape’s keystore to recognize corporate or locally signed certificates that are not signed but public certificate authorities.

A private key with signed certificate by either a public certificate authority or a internal/corporate security authority is needed on CenterScape for the following:

  • To provide HTTPS encryption and hostname validation for web clients for CenterScape’s web user interface
  • To provide HTTPS encryption and hostname validation for API clients for the web services interface
  • To provide readers using the up connect feature to validate the hostname and certificate of CenterScape when attempting to connect o port 6503 over TLS

A private key with a signed certificate by either a public certificate authority or a internal/corporate security authority is needed on M250 readers for the following:

  • To provide HTTPS encryption and hostname validation to web clients using the readers web interface
  • To provide encryption and hostname validation for CenterScape connections using TLS on port 6500

A CA authority certificate or any single use certificate that must be respected by CenterScape is needed to use the following.

  • To send email to an SMTP host requiring TLS that has a corporate signed certificate
  • To send notifications, alerts, or reports to a HTTPS web server that has a non public corporate signed certificate and verification of Certificate and Hostname is required.
  • To connect to a Microsoft SQL Server or or PostgreSQL server that requires encryption and who’s certificate is corporate or internal and needs a CA cert to authenticate
  • To connect to an LDAP or Active directory server with encryption who’s certificate is internal/corporate and needs a CA certificate to authenticate.

The CenterScape application is a Java based virtual machine that runs inside the JDK or JRE that serves web pages, interfaces with Microsoft SQL Server or PostgreSQL , and processes data. Its encryption is based on a java keystore which is administered by the java keytool program, which is included as part of the JDK/JRE. The default keystore will include a private key and a self signed certificate. This certificate is used to server HTTPS from CenterScape’s bundled web server after initial install. Also included with the Open JDK bundled version of the software is a ca certs file. This file includes the public certificates of respected internet signing authorities and is maintained by the Adoptium Open JDK project. It will be similar if not identical to the public CA certificates shipped with Linux and Windows operating systems. The JVM will not use the operating system certificate stores on the host that CenterScape is installed on but will depend on the certificates listed in the keystore file [install dir]/conf/keystore, and the CA certs file. If another JDK or JRE is used with the No-JRE distribution of CenterScape then the CA certs file will be maintained by the provider of the JRE (ie Oracle, IBM etc). Because of this the CenterScape application by default will only accept publicly signed certificates from companies included in the CA certs file. (ie Godaddy, GeoTrust, Verisign etc..)

Modifying Certificates Overview​

There are a number of options for modifying the certificates that CenterScape uses. The self signed certificate is generally used as an interim certificate just for basic TLS functionality upon installation. It is highly recommended that the certificate and private key be replaced by either a certificate signed by a public certificate authority or an internal company certificate authority. Additionally multiple CA certificates can also be added to the keystore file if an enterprise has multiple signing authorities. The method used to modify the keystore file can vary by enterprise based on the software they use for enterprise public key infrastructure management (PKIs). Some software vendors may create the private key and certificate with a java keystore as an option. In those cases, all that needs to be done is to rename the keystore file and place it in the /conf directory. The system.properties file will then need the key and keystore passwords in order to access the new keystore file. In other circumstances a private key and certificate request (CSR) will need to be generated with the keytool and then signed by the CA. The CA generated certificate or more likely certificate chain will then need to be added to the keystore.

Note: Before modifying the keystore, backup the default keystore by copying the file to another directory. CenterScape will not start with an invalid keystore or incorrect keystore access credentials.

If the PKI generates a keystore with a private key and certificate/ certificate chain, skip the keytool section of this document and follow the instructions in the Keystore Access section after shutting down the service. Rename the keystore file simply “keystore” and move it to the conf directory.

If the PKI requires a CSR to generate a certificate, such as Windows Active Directory Security Services, then follow the Keytool Administration Section and then the Keystore Access section.