Using Certificates to Connect to the Digital Health Platform

The Enterprise Configuration Portal enables users to manage X.509 certificates that can be used to secure Inbound and Outbound Connections. The Enterprise Configuration portal also enables users to communicate how they intend to use certificates within their integration software, but is not responsible for performing that configuration.

Note: All direction provided in this topic is related to a user configuring their software and is meant to be presented at a high level, as there is no way to cover each type of specific integration software that is in use by a given customer.

General

First, the user must have the Certificate and Private Key that was used to create the Inbound or Outbound Connection within the Enterprise Configuration Portal. The user must import that Certificate and Private Key into the Key Store that is used by their software in order to establish TLSv1.2 (or better) connections.

The most effective way to uniquely identify a certificate is by its SHA-1 thumbprint. The Enterprise Configuration Portal displays certificate thumbprints within Certificate Management, and when assigned to Inbound and Outbound connections.





Any certificate can be inspected to determine its thumbprint.



When a user configures their software, it must be configured to use the certificate that was assigned to the Inbound or Outbound Connection within the Enterprise Configuration Portal.

Inbound Connections using Certificates

The user's integration software is acting as a Client and the Digital Health Platform is acting as a Server. As such, the user must configure their software to present the appropriate client or client/server certificate when initiating a connection with the Digital Health Platform.

When configuring client connections, the user should enable the following configuration items to improve security:

  1. Server Certificate Validation - The user's software will validate the chain of trust associated with the Server Certificate that is presented by Smart Device Connectivity. The public portion of Smart Device Connectivity's server certificate chain can be pulled down and configured as the Trusted Server Certificates associated with the client connection.
  2. Hostname Verification - Validation fails if the hostname presented in the server certificate does not match the actual endpoint that the user's software is connecting to.

Outbound Connections using Certificates

The Digital Health Platform is acting as a Client and the user's software is acting as a Server. As such, the user must configure their software to present the appropriate server or client/server certificate when the Digital Health Platform initiates a connection with their software. Smart Device Connectivity performs Server Certificate and Hostname Verification.

Certificate Expiration

By design, certificates expire after a given amount of time. If a certificate expires while it is currently in use by an Inbound or Outbound Connection, that connection will no longer function. The Digital Health Platform will notify the applicable users when any given certificate is nearing expiration at the following intervals:

  1. 30 days from the expiration date
  2. 14 days from the expiration date
  3. 7 days from the expiration date

Additionally, the Digital Health Platform will notify the applicable users when a certificate has expired.

When a certificate expires, action must be taken by the user to replace the certificate associated with the Inbound or Outbound Connection to avoid down time.