Skip to main content

Security Certificate configuration

Client installation of security certificate

If agencies using Netsmart Homecare use the security certificate issued by a trusted provider, they do not have to install the public SSL certificate manually. Administrators must perform additional actions for private or self-signed certificates issued by private issuers.

  1. Install the public SSL certificate.
  2. Install the root certificate issued by the private CA provider.
Certificate implementation

Certificates must be created with specific criteria to protect the intended resources properly. The most important aspect of creating and using a certificate is for its name to exactly match the fully qualified domain name (FQDN) of the environment you want to protect and the path it will be accessed from. For example, if a user connects to 'MyExternalServer.MyCompany.com', the certificate must be issued for that exact same FQDN (MyExternalServer.MyCompany.com). Each server requires its own certificate to protect it.

If there is a naming mismatch, the browser or application shows a warning about the untrusted connection and may refuse to function in this insecure manner. Due to the naming mismatch warning, web service calls typically fail and result in an application error.

Important: The Netsmart Homecare application is only accessible if the FQDN name matches.

For Netsmart Homecare, you can implement security certificates in one of the following ways:

  • Obtain a wildcard certificate for your domain.
    OR
  • Obtain certificates for each server (including test and public app servers). In Netsmart Homecare, two types of certificates are needed: STS and SSL certificates for the Netsmart Homecare server. One individual SSL certificate with a private key must be installed on each host where mobile phone, mobile tablet, or Physician Portal services are installed.

Note: If your organization has an app and a mobile server, both must have unique certificates matching each server's Fully Qualified Domain Name.

For example, 'HCAppServer.MyCompany.com' and 'HCTabletServer.MyCompany.com'. You cannot use a certificate for a server that does not match that server's Fully Qualified Domain Name. Some exceptions can be made for wildcard certificates if they validly cover the Fully Qualified Domain Name requirements on both environments. The certificate for the mobile server must match the fully qualified domain name that users specify on their mobile devices when connecting to the mobile server. If users are expected to connect to the external internet facing the Fully Qualified Domain Name of the mobile server, then this is the Fully Qualified Domain Name that the certificate must protect.

Important: It is recommended that you do not use proxy servers for internet access in the Netsmart Homecare environment. If you decide to use a proxy server, set it up to bypass the application server, mobile server, and Physician Portal server so that Netsmart Homecare can directly access the internet.

Certificates for features

An SSL certificate is required per host. This means that if you install all features that require an SSL certificate on one host, you need only one SSL certificate for that host. The recommended certificate types for the application server are domain validation and wildcard.

Root certificate

A root certificate is a certificate that identifies the certificate authority (CA). A root certificate is part of a public key infrastructure scheme. If you use an STS or SSL certificate from the private issuer or a self-signed certificate, the public root certificate must be manually installed in the Trusted Root Certification Authorities certificate store on all server and client machines.

Intermediate certificate

All intermediate certificates present in the STS and SSL certificate path or chain must be located (manually installed) in the Intermediate Certification Authorities store on all server and client machines.

SSL certificate requirements 
  • The size of the certificate public key must be greater than or equal to 2048 bits. This key is used to verify the server's identity and encrypt the symmetric key.
  • At least a SHA256 fingerprint with either a 2048-bit or greater RSA key or a 256-bit or greater Elliptic-Curve (ECC) key.
  • The SSL certificate must be obtained for the specific purpose. To verify this, open the certificate file and, on the Details tab, ensure that the field values are the same as follows:
    • Key Usage: Digital Signature, Key Encipherment (a0)
    • Enhanced Key Usage: Client Authentication (1.3.6.1.5.5.7.3.2) Server Authentication (1.3.6.1.5.5.7.3.1)

 

  • Was this article helpful?