Configuring Secure Connections (SSL/TLS)
This topic provides an overview of SSL/TLS certificates and explains the versions of SSL/TLS supported by the Edge MicroServer.
Essentially, SSL/TLS certificates are used for either of two purposes:
• Establishing Trust — Trusted Certificate Authority (CA) certificates verify other certificates. Typically, these files are found on a client that is attempting to establish an SSL/TLS connection with a server. For example, store a valid certificate in the home directory of your EMS. The valid certificate must belong to the issuers of the certificates (Certificate Authority or “CA”) of the ThingWorx Platform instance (“server”) with which the EMS communicates. The CA certificates must be stored in the home directory of EMS.
• Establishing Identity — Identity certificates with private keys provide a way of communicating the unique identity of an SSL/TLS peer. Identity certificates with private keys are typically used to show the identity of a server to a client. When a server requires client authentication, Identity certificates are also required on the client. In this latter case, the Trusted Certificate Authority certificate would be required on the server (a ThingWorx Platform).
The requirements for products acting as clients, such as EMS, or servers, such as a ThingWorx Platform, in SSL/TLS connections follow:
• A server must always have an Identity certificate. Optionally, if the product acting as a server supports and is configured to use client authentication, the server would need a Trusted Certificate Authority certificate.
• A client must always have a Trusted Certificate Authority (CA) certificate. An example of a Trusted CA certificate name is SSLCACert.pem. Optionally, if the product acting as a server supports and is configured to use client authentication, the client would also need an Identity certificate. An example of a client-side Identity certificate file name is SSLCert.pem, and an example of its private key name is SSLPrivKey.pem.
The EMS can validate certificates that have been signed using the following algorithms:
• MD5
• SHA-1
• SHA-256 digest
 |
Always configure a secure HTTP server. Otherwise, the EMS and LSR log warning messages when SSL, authentication, or certificate validation is disabled or if self-signed certificates are allowed.
|
With the more recent releases of OpenSSL, FIPS mode is no longer supported. This change affects v.5.4.5 and later versions of the EMS. The following table lists other changes for recent releases of OpenSSL and versions of EMS still under standard support:
|
EMS Version
|
OpenSSL Version
|
FIPS Supported?
|
|---|---|---|
|
5.4.5
|
OpenSSL 1.0.2q
|
No. This version and later versions of OpenSSL do not support FIPS. The distibution still contains the axTLS library, but for best security, it strongly recommended to use OpenSSL..
|
|
5.4.6
|
OpenSSL 1.0.2r
|
No. The axTLS library is no longer provided in the distribution bundle. Only OpenSSL libraries are provided in the distribution bundle.
|
|
5.4.7, 5.4.8, 5.4.9
|
OpenSSL v.1.1.1c
|
No.
|
|
5.4.10
|
OpenSSL 1.1.1j
|
No
|
OpenSSL v.1.1.1j implements TLS v.1.3, which you can use between the EMS and an LSR. Once the ThingWorx Platform is updated to support TLS v.1.3, you will be able to use TLS v.1.3 between the EMS and the platform.
|
|
Starting with v.5.4.8, the EMS provides a property called http_client_ca_certs that allows the use of a separate Certificate Authority (CA) certificate file that will only be used for Edge-to-Edge HTTPS connections. If this option is not used, the default CA certificate list that is used to validate the platform connection is used. This property is in the certificates group in the EMS configuration file. For more information, refer to Configuring the EMS to Use a Different Certificate Chain for Edge to Edge
Communications (Optional).
|