Trust Management – CBA Live Assist Help Center

By default, Fusion Application Server is configured to use Transport Layer Security (TLS). Using TLS enables servers to verify the identities of both the server and client through exchange and validation of their digital certificates, as well as encrypt information exchanged between secure servers using public key cryptography, ensuring secure, confidential communication between two entities.

Data is secured using key pairs containing a public key and a private key. The owner encrypts the sent data using the recipient’s public key, which can then be decrypted only with the private key in the pair. Encryption alone provides no proof of the identity of the sender of the encrypted information, however. Certificates address this problem by also providing a digital signature, an electronic means of verifying a resource's identity.

To prove its identity, a resource requests a certificate from a Certification Authority (CA). The issued certificate is then signed with the CA's private key, and should be added to the resource's identity certificate store. A certificate typically contains the following information:

Owner's public key
Owner's name
Expiration date of the public key
Name of the issuer (the CA that issued the certificate)
Serial number of the certificate
Digital signature of the issuer

This certificate can then be sent to other resources to establish trust with that resource. The receiving resource should add the CA certificate to their trust certificate store. For two-way trusted communication, certificates should be exchanged between resources.

If both entities trust the same CA, this allows them to establish a bond of identity and trust between them.

Using Certificates with FAS

The components within a FAS cluster should implicitly trust each other, so you should provision all nodes within a FAS cluster with certificates signed by the same trusted CA.

The installation process provisions the servers with temporary certificates which have a CN (Common Name) reflecting the cluster address that you specified when installing each component; this defaults to the host’s IP address for a single box installation, but you could have specified an FQDN. The temporary certificates all have a common signer, so each of the nodes within the cluster can communicate over TLS with the others.

After installation, you should replace the temporary certificates with certificates that have been signed by a third-party Certification Authority (CA) or by a SCEP server. The CN in the updated certificates should reflect the fully-qualified DNS name of cluster. If all of the cluster components share the same CN, it will only need one signed certificate.

As external data is sent to and from the Load Balancer nodes, the LBs need to know which external hosts are trusted. To trust an external host, the certificate of the CA that signed the external host's certificate must be added to the LB’s trust certificate store, and the external host will need to add the certificate of the CA that signed the LB’s certificate to its trust certificate store. Any communications with that host can then be trusted.

Where your deployment has no Load Balancer node, external data is sent to your Application Server nodes. In this case, your Application Server nodes also need a trust certificate store.

Managing Certificates

Certificates can be managed using the Management Console, and you can manage the certificates for multiple Certificate Groups. The Management Console enables you to perform the following functions:

view identity certificates
create and sign new identity certificates using SCEP
create certificate signing requests (CSRs) for third-party CAs
replace existing identity certificates (for example, when they are about to expire, or the CN value has changed)
replace expired identity certificates
view trust certificates
import trust certificates

To work with certificates, you must know the security password; the default password is changeit, but the installer can set this to a different value.

Note: Certificates are initially created on the node hosting the Domain Host Controller, and are then automatically copied to all the nodes in the cluster.

Identity and Trust Certificate Groups

An identity certificate is a certificate that can be used to identify a host. The CN of these certificates will usually contain either:

A fully-qualified name which can be resolved in DNS. This name may resolve to one or more machines.
The IP address of the machine.

Identity certificates are managed in identity certificate groups. The installer creates the following identity certificate groups:

mgmt-server-group - for the node which runs the Domain Host Controller, the Management Console, and the License Server.
main-server-group - for the Application Server nodes.
main-loadbalancer-group - for the Load Balancer nodes.

The main-server-group and main-loadbalancer-group require a certificate for each transport type (SIPS and HTTPS) in the group, as shown in the image above. As the Domain Host Controller is only a management interface, the mgmt-server-group only needs an HTTPS certificate.

Trust certificates are managed in trust certificate groups. By default, there is a single trust certificate group, which can be used throughout the cluster.

When the Management Console creates certificates, it saves them in identity certificate group and trust certificate group directories on the node hosting the Domain Host Controller; they are automatically copied to each FAS node in the cluster, and to any new nodes added to the cluster.

Configuring with Certificates signed by a CA

If you want to generate a new identity certificate to be signed by a third-party CA, you must generate a Certificate Signing Request (CSR) (see the Generating a Certificate Signing Request section in this article), send the generated CSR to the third-party CA (see the Sending a CSR to an External CA for Signing section in this article), and then import the signed certificate (received from the CA) into the identity certificate group (see the Importing a Signed Certificate section in this article).

Normally you will choose an existing certificate to be signed by the CA, but sometimes you may need to generate a new certificate; see the Generating a New Identity Certificate section in this article.

Note: Certificates can also be signed by a SCEP server. See the Configuring with Certificates signed by a SCEP Server section in this article.

Generating a Certificate Signing Request

Launch the Management Console - see the Starting the Management Console section in the Management Interfaces article.
From the top right menu, select Profiles.
From the top left menu, select the management profile.
In the menu on the left, expand Subsystems and Trust Management, and select ID Certificates.
In the Identity Certificate Group section, select the identity certificate group that contains the certificate that you want to be signed:

In the Identity Certificate Group Management section, select the certificate that you want signed, and click Generate CSR.
Enter the password and click Next to show the Generate CSR dialog:

Enter the security password in the Challenge Password field.
Change the Subject DN as required.

In most cases, the DN for the existing certificate will be what you want, but if you need to change it, the CN value in the DN should reflect that of the SIP domain; for example CN=192.168.1.234, or CN=example.net. If you wish to add an organizationName attribute, you can enter the DN as e.g. O=acme.com,CN=example.net.

Add entries to the Subject Alternative Name field.

In most cases the Subject Alternative Names for the existing certificate will be what you want, but if you want to add entries, you can add records for each IP address (e.g. IP:172.16.1.8) or host name (e.g. DNS:foo.bar.com) which will be used to access the machine.

Click Generate. A dialog showing the generated CSR will be displayed:

Select the generated text, including the starting and ending tags (-----BEGIN_CERTIFICATE_REQUEST----- and -----END_CERTIFICATE_REQUEST-----), copy it, and paste it into a text editor and save the file.
Click Close.

Sending a CSR to an External CA for Signing

The procedure for getting your certificate signed by a third-party CA depends upon the requirements of that CA. See the guidance from the CA.

Importing a Signed Certificate

When you receive the signed certificate back from your CA, you must import it into the correct identity certificate group:

Launch the Management Console - see the Starting the Management Console section in the Management Interfaces article.
From the top right menu, select Profiles.
From the top left menu, select the management profile.
In the menu on the left, expand Subsystems and Trust Management, and select ID Certificates.
In the Identity Certificate Group section, select the identity certificate group that contains the certificate that has been signed:

Select the certificate which has been signed by the CA. This must be the same one that you selected when you generated the CSR.
Click Import to bring up the Import Certificate dialog:

Enter the security password in the Password field.
Open the certificate you have received from the CA in a text editor, select all the contents, including the start and end tags, copy them, and paste them into the Encoded Certificate field.
Click Import.

Once the certificate is imported, the window will update to display any changed certificate details, such as the issuer DN and the expiry date.

Restart each node in the cluster for the changes to take effect.

Configuring with Certificates signed by a SCEP Server

If you want to generate a new certificate that is signed using the SCEP protocol, there is a single UI operation, which performs the CSR generation, sending, receiving, and importing steps automatically; see the Generating a SCEP-Signed Certificate section in this article.

Before you can perform this procedure, you must configure FAS with the details of a server that implements the SCEP protocol, such as an EJBCA server; see the Configuring FAS to use the SCEP protocol section in this article.

Normally you will choose an existing certificate to be signed by the SCEP server, but sometimes you may need to generate a new certificate; see the Generating a New Identity Certificate section in this article.

Configuring FAS to use the SCEP protocol

Launch the Management Console - see the Starting the Management Console section in the Management Interfaces article.
From the top right menu, select Profiles.
From the top left menu, select the management profile.
In the menu on the left, expand Subsystems and Trust Management, and select SCEP Configuration:

Click Add to bring up the New SCEP Configuration dialog:

Enter the values:

Field	Description
Name	A name for this SCEP configuration
Url	The SCEP server CGI URL. A typical value for an EJBCA server might be: http://ejbca.example.com:8080/scepraserver/scep/pkiclient.exe
Profile	The value of the SCEP profile, or identity, that you want to use
Subject DN Prefix	The string that will be prefixed to the CN= value when constructing the Subject Distinguished Name in the X509 certificate. For example, if this field is set to C=GB,O=Cafex,OU=Test, then the resulting DN might be: C=GB,O=Cafex,OU=Test,CN=example.com

Click Save.

Generating a SCEP-Signed Certificate

Launch the Management Console - see the Starting the Management Console section in the Management Interfaces article.
From the top right menu, select Profiles.
From the top left menu, select the management profile.
In the menu on the left, expand Subsystems and Trust Management, and select ID Certificates.
In the Identity Certificate Group section, select the identity certificate group that contains the certificate that you want to be signed:

In the Identity Certificate Group Management section, select the certificate that you want signed, and click SCEP Sign.

This will generate the CSR, send it to the SCEP server (which will sign and return it), and import the returned certificate into the identity certificate group directory automatically.

Restart each node in the cluster for the changes to take effect.

Configuring LBs with Trust Certificates

External traffic typically flows into FAS through the LBs. To allow TLS connections to the LBs from external entities that use identity certificates signed by a CA that is not currently recognized, a certificate from the unknown CA must be added to the trust certificate group.

Importing a Trust Certificate

Launch the Management Console - see the Starting the Management Console section in the Management Interfaces article.
From the top right menu, select Profiles.
From the top left menu, select the management profile.
In the menu on the left, expand Subsystems and Trust Management, and select Trust Certificates:

In the Trust Certificate Group section, select the trust certificate group that you want to import the trust certificate into.
Click Import to bring up the Import Certificate dialog:

Enter a meaningful name into the Name field.

The name should preferably indicate the CA whose certificate is being imported.

Enter the security password in the Password field.
Open the certificate from the unknown CA in a text editor, select all the contents, including the start and end tags, copy them, and paste them into the Encoded Certificate field.
Click Import.
Restart each node in the cluster for the changes to take effect.

Configuring the DHC with an Identity Certificate

The Domain Host Controller and License Server, which are installed on the same host, must also have an identity certificate containing the CN of that host. The installation process provisions this host with a default, self-signed, identity certificate, in the management-group identity certificate group. You should replace this certificate with an alternative certificate signed by a third-party Certification Authority (CA) or a SCEP server.

Follow the instructions in either the Configuring with Certificates signed by a CA section or the Configuring with Certificates signed by a SCEP Server section in this article, choosing the mgmt-server-group Identity Certificate Group, and the https Identity Certificate (by default, this is the only identity certificate in this group).

Replacing an Identity Certificate

You would typically need to replace an identity certificate when it has expired.

To replace a certificate, follow the instructions in either the Configuring with Certificates signed by a CA section or the Configuring with Certificates signed by a SCEP Server section in this article, choosing the certificate you want to replace. These instructions will obtain a new certificate (signed by either a CA or the SCEP server), and replace the existing one with it.

Exporting an Identity Certificate

You can create a backup copy of a certificate by exporting it.

Launch the Management Console - see the Starting the Management Console section in the Management Interfaces article.
From the top right menu, select Profiles.
From the top left menu, select the management profile.
In the menu on the left, expand Subsystems and Trust Management, and select ID Certificates.
In the Identity Certificate Group section, select the identity certificate group that contains the certificate to be exported:

Select the identity certificate you want to export.
Click Export. The Management Console will ask for the certificate password.
Enter the certificate password and click Export:

Copy the text, paste it into a text editor, and save the file.
Click Close.

Removing a Trust Certificate

You would typically remove a trust certificate to prevent TLS connections from machines that use identity certificates signed by a specific CA that you no longer trust.

Launch the Management Console - see the Starting the Management Console section in the Management Interfaces article.
From the top right menu, select Profiles.
From the top left menu, select the management profile.
In the menu on the left, expand Subsystems and Trust Management, and select Trust Certificates:

In the Trust Certificate Group section, select the trust certificate group that contains the trust certificate you want to remove.
In the Trust Certificate Management section, select the Trust Certificate you want to remove.
Click Remove:

Click Confirm.
Restart each host in the cluster for the changes to take effect.

Generating a New Identity Certificate

Launch the Management Console - see the Starting the Management Console section in the Management Interfaces article.
From the top right menu, select Profiles.
From the top left menu, select the management profile.
In the menu on the left, expand Subsystems and Trust Management, and select ID Certificates.
In the Identity Certificate Group section, select the identity certificate group that you want to add a certificate to:

In the Identity Certificate Group Management section, click Generate Keypair to show the Generate Keypair dialog:

Enter a value for the Name, preferably indicating the component and transport type which the new certificate is to be used for. For example, a certificate for SIP traffic on LBs could be named sip-lb.
Enter the Subject DN value (please see page 6 of <https://www.ietf.org/rfc/rfc4514.txt> for attribute types). The CN value in the DN should reflect that of the SIP domain; for example CN=192.168.1.234, or CN=example.net. (If the LBs are in a different domain to the ASs, use the domain applicable to the component type that the new certificate is for.)

If you wished to add an organizationName attribute, you can enter the DN as e.g. O=acme.com,CN=example.net.

Enter an Expiry Date, using either the date picker or by entering it manually in the form yyyy-mm-dd.
Enter the security Password.
Enter Subject Alternative Name records for each IP address (e.g. IP:172.16.1.8) or host name (e.g. DNS:foo.bar.com) which will be used to access the machine.

The cluster IP address will be added by default, and in many cases you will need no other entries. You can add other entries (not shown in the screenshot) by scrolling down, but in most cases you can leave these at their default values.

Click Generate.

The Management Console will add a new entry with the specified name to the list of certificates.