DAI Secure (HTTPS) Connections and Certificates

For improved security, DAI requires the use of the secure internet connection protocol (HTTPS). This means all DAI clients, including users with web browsers and the DAI agents, must use https in the URL they use to access DAI.

Implementing DAI with HTTPS requires that you provide a Transport Layer Security (TLS) certificate for the DAI Server, and root certificates on the client systems that will access DAI.

The two main types of certificates involved in an HTTPS implementation in DAI are as follows and are described in detail below:

• Transport Layer Security (TLS) certificates (for the DAI Server)

• Root/CA certificates (for DAI clients)

For an explanation of certificate authorities (CAs) and digital certificates in general, see the Wikipedia article Certificate authority.

note

Using HTTPS became a requirement for the DAI Server on Windows in version 26.2.1. Configuring the DAI Server with HTTP connections is not supported after DAI version 26.2.0. Container deployments of DAI, which run on Linux, have always required HTTPS connections.

For information about installing the DAI Server on Windows, see Installing or Upgrading (DAI 26.2.1 and Higher) or Installing or Upgrading (DAI 26.2.0 and Older) as appropriate for the version you are installing. For information about deploying the DAI Server in a container (available on Linux containers only), see Deploy to Containers. For information about other DAI requirements, see the Prerequisites page.

Transport Layer Security (TLS) Certificates

You install the Transport Layer Security (TLS) certificate on the Windows system where you will install the DAI Server, and then specify its location during installation of the DAI Server. This type of certificate is also known by its older name, SSL certificate, or as an end entity certificate because it is the certificate that ultimately needs to be trusted by the DAI clients (for example, the browser that you use to log into the DAI web app or a DAI agent).

info

Using a trusted certificate authority (CA) certificate signed by a publicly trusted CA or an enterprise CA signed by your company, for example, is the recommended certificate type for production installations.

DAI supports TLS versions 1.2 and 1.3.

The following table describes the TLS certificates supported by DAI for HTTPS connections:

Types of TLS Certificates	Description	Requirements
Publicly trusted Certificate Authority (CA) certificates	Certificates that are issued from a publicly trusted CA, such as Verisign or Let's Encrypt.	The CA certificate must be: - Issued specifically for the hostname of the Windows system where you are installing the DAI Server. - Installed on that system, so you can specify the path to its location during DAI Server installation. (Note that the DAI Server Setup program on Windows checks to see if the host name specified in the certificate matches the system where it is running.) - Certificates also require an associated key file. See Certificate SSL Keys and Files below for more information.
Private or enterprise CA certificates	Private or enterprise CA certificates are certificates issued by a private CA, such as your company.	Private or enterprise certificates have the same requirements as publicly trusted CA certificates above. If you create a certificate that is signed by your own CA, you must include the following: - Issuer: the organization that is issuing the certificate, for example, "yourcompanyname". - Subject: the hostname that the certificate has been generated for, for example, "local.dai.com", which must match the hostname that you enter during installation. To be accepted by Chrome and Firefox, the TLS certificate must set the Subject Alternative Name and Authority Key Identifier fields. - You must also use a hash function that is cryptographically strong enough such that a browser deems it as secure; sha512 and sha256 are currently acceptable.
Self-signed certificates	A "self-signed certificate" is a certificate for which there is not a separate certificate authority. See the Wikipedia article Self-signed certificate for a more thorough explanation.	DAI provides the option to Generate a self-signed certificate during DAI Server installation on Windows, instead of using a publicly trusted or private or enterprise certificate. Generating a self-signed certificate during installation: - Allows you to install or upgrade DAI. - Is automatically trusted by DAI agents on all platforms, as well as Eggplant Functional/Fusion Engine. Note: We do not recommend using this option for production installations, however, because web browsers do not automatically trust these certificates. If you do, each of your DAI users must download a certificate the first time they try to access DAI with their browser using the https URL. Or, they must configure their browser to explicitly trust the certificate. For example, in Chrome, you can import it as a "Trusted Certificate."

Certificate SSL Keys and Files

A few things to note about the certificate keys and files are as follows:

Certificate Keys and Files	Notes
SSL (TLS) Keys	Can be all key formats that are accepted by nginx, for example, RSA and ECDSA Public Key Infrastructure (PKI) keys are supported.
Key and Password Files	- Key files must be in the PEM file format. - If you are using a Personal Information Exchange (.pfx) file, you will need to convert it to a format accepted by nginx. - If the key file is encrypted, you must also provide a password file containing the passkey needed to decrypt it. - The password file contains the password as plain text. - The file ending does not matter. It can be .txt, .pass, .file.

Root (CA) Certificates

Root/CA certificates must be present on all systems running DAI clients in order for them to trust the TLS certificate.

info

If you use a publicly trusted CA certificate as the TLS certificate for your DAI Server, such as from Verisign or Let's Encrypt, then the root/CA certificates you need are most likely already installed on your systems. Similarly, if you use an internal or enterprise CA, then the certificates you need are also likely to be installed on all the systems on your network.

If, after installing, you are able to access DAI with your https URL, and you don't see a warning about it being untrusted, then the certificates you are using are trusted. Your certificate configuration is verified.

Certificates	Description	Requirements
Root/CA certificates	- Root certificate is another name for a Certificate Authority (CA) certificate. - This is the certificate that the TLS certificate has been signed with (either directly or via a chain of intermediate certificates.) - In the case of the Eggplant self-signed certificate that you can choose during the Windows DAI Server installation, there is not a root certificate. The self-signed certificate is acting as its own certificate authority, which is why browsers will not trust it by default. You will see a message about it being untrusted in your browser when you try to access the DAI URL.	- Root/CA certificates must be installed on all client systems from which users will access DAI with a browser or DAI agent. As highlighted above, if you use a publicly trusted, private, or enterprise CA certificate as the TLS certificate for your DAI Server, the root/CA certficates you need are likely already installed on your client systems. - If you choose the option to generate an Eggplant self-signed TLS certificate during the DAI Server installation on Windows, the client components of DAI (the agents and Eggplant Functional/Fusion Engine) are configured to automatically trust this certificate. However, browsers will not automatically trust it, which is why we don't recommend it for production installations. You (and all your users) will have to download the certificate when you first try to access DAI from your browser. Or, explicitly configure your browsers to trust these certificates. For example, in Chrome, you can import it as a "Trusted Certificate."