Server certificate requirements

All server certificates must have certain properties and be in the correct file format to function in the suite.

Certificate Subject Name

A crucial step in the process of configuring enterprise HTTPS is to ensure that the certificates have the correct Certificate Subject Name that matches the system configuration in the Enterprise Manager, as described in the table. Failure to comply with these naming conventions results in the client receiving a certificate address mismatch error.

The certificate subject name is specified in the Subject Alternative Name (SAN) field. During the TLS handshake, the target name is checked against the SAN field.

Subject field check is deprecated by modern HTTPS implementation (for example, as of Chrome 58), it is required to have all valid certificate subject names specified in the SAN field.

In IE11, the Subject field is still supported, and it is enough to have all valid certificate subject names specified in the Subject field only.

Communication	Certificate used for TLS handshake	Match this setting with the Certificate Subject Name
Browser ➞ LB	LB	Application server's alias name (external address of LB)
LB ➞ Application Server	Application Server (If data center SSL offload is enabled, communication between the LB and the application server is HTTP).	Application server's server name
Browser ➞ Server	Target Server	Target server's alias name
Server ➞ Server	Target Server	Target server's server and alias name

In case an LB is deployed in SSL pass-through mode, the SAN field on the application servers must contain the load balancer address as well.

Wildcard TLS certificates are supported.

Certificate Properties

Prepare the certificates container file according to the requirements.

Server Certificate element	Description
File Name and Format	File name must be svr_cert_key.p12 File format must be PKCS12 When using a certificate chain, you must include all CA certificates in the chain in the P12 file. The system does not support a P12 password with certain special characters such as &, ^, %, @. If a customer provided a P12 file with a password containing one of the unsupported characters, the customer is required to recreate a temporary P12 file with an alternative password. The temporary file can be deleted once the TLS server certificates are installed.
Issuer	All server certificates must be signed by one of the following: A private CA (such as Microsoft Certificate Authority on the Domain Controller) A public CA vendor (such as Verisign) NOTE: For the system to function, TLS certificates cannot be self-signed. A valid CA must sign each certificate.
Private key	The key used by the server to decrypt data transmitted to it over the network, and to encrypt responses back to clients.
Public key	The key used by the client encrypt requests sent to the server, and to decrypt server responses. The public key cryptography must be either ECC or RSA.
Signature hash	SHA2 algorithm is supported. NOTE: SHA1 is supported, but the SHA1 signature hash is no longer secure and may expose servers to spoofing or man-in-the-middle attacks. Therefore, SHA1 certificates may be blocked by modern browsers and 3rd party updates.
Enhanced Key Usage	This field in the certificate must contain “Server Authentication”.
Certificate expiration date	The date that the certificate expires. NOTE: It is the customer's responsibility to make sure certificates are kept up to date.
Certificate revocation list (CRL)	The CRL enumerates revoked certificates along with the reason(s) for revocation. It is the customer’s responsibility to keep the CRL up-to-date. Note: CRL distribution point must be accessible from all system servers and desktops. In case it is not accessible (for example, in case of a public CA and no internet connection), CRL check must be disabled as described in the Technology, Security, & Network Integration Deployment Reference Guide (DRG).

Related information

Common Name (https://tools.ietf.org/html/rfc5280)