3.4 Managing Trusted Roots and Trust Stores

A certificate from a certificate authority (CA) is commonly referred to as trusted root. A trusted root is a trusted certificate, or the certificate of a known CA. These certificates are self-signed and are recognized as representing a CA that is trusted. In order to validate a digital signature, you must trust at least one of the certificates in the user or server’s certificate chain. You can directly trust the certificate of the user or server, or you can choose to trust any other certificate in the chain. Typically, the certificate that is trusted is the root CA’s certificate.

When an external certificate authority creates certificates, you need to import the trusted root of the certificate authority and assign the trusted root to the trust store of the device that needs to trust the certificate.

  1. In the Administration Console, click Security > Trusted Roots.

  2. Select form the following actions:

    Import: Allows you to import trusted roots so that Access Manager devices can trust the certificate sent by other computers at runtime. For more information, see Section 3.4.1, Importing Public Key Certificates (Trusted Roots).

    Delete: To delete a trusted root, select the trusted root, then click Delete.

    Add Trusted Roots to Trust Stores: Allows you to assign a trusted root to a device so it can be used by that device. For more information, see Section 3.4.2, Adding Trusted Roots to Trust Stores.

    Auto Import From Server: To import a trusted root from another server, click Auto Import From Server. For more information, see Section 3.4.3, Auto-Importing Certificates from Servers.

    View Trusted Root Details: To view information about a trusted root, click the name of a trusted root. For more information, see Section 3.4.6, Viewing Trusted Root Details.

3.4.1 Importing Public Key Certificates (Trusted Roots)

You import trusted roots so that the specific device can trust the certificate sent by other computers at runtime. After you import a trusted root, you can assign it to the proper trust store associated with a device, which allows the device to trust certificates signed by the trusted root.

  1. In the Administration Console, click Security > Trusted Roots.

  2. Click Import, then specify a name for the certificate.

    This is a system-wide, unique name used by Access Manager.

  3. Select one of the following methods for importing the public key:

    • Certificate data file (DER/PEM/PKCS7): Select this method to browse to a file. Click Browse to locate the file on your file system.

    • Certificate data text (PEM/Base64): Select this method to paste Base64-encoded certificate data text.

  4. Click OK.

  5. Continue with Adding Trusted Roots to Trust Stores

3.4.2 Adding Trusted Roots to Trust Stores

After importing a trusted root, you need to assign it to a device before it is used by Access Manager.

To add a trusted root to an existing trust store:

  1. In the Administration Console, click Security > Trusted Roots.

  2. Select the trusted root, then click Add Trusted Roots to Trust Stores.

  3. Fill in the following fields:

    Trusted roots: Select the trusted root store. To locate the trusted root store, click the Select Keystore icon. When you browse, the system displays the Select Trusted Roots page. Select the trusted root store, then click OK.

    Alias(es): Specify an alias for the trusted root.

  4. Click OK.

  5. Update the device that is using this trust store.

3.4.3 Auto-Importing Certificates from Servers

You can import certificates from other servers (such as an LDAP server, an identity provider, or service provider) and make them available for use in Access Manager. You must provide the IP address, port, and certificate name.

  1. In the Administration Console, click Security > Trusted Roots > Auto-Import from Server.

  2. Fill in the following fields:

    Server IP Address: Specify the server IP address. You can use a DNS name.

    Server Port: Specify the server port.

    Certificate Name: Specify a unique name of the certificate to store in Access Manager.

  3. Click OK.

3.4.4 Exporting the Public Certificate of a Trusted Root

You can export a trusted root or a public key certificate to a file so that a client can use it to verify the certificate chain sent by a cryptography-enabled application, or to have a backup copy of the file.

You can export the certificate in the following formats:

  • DER-encoded (.der) to a file.

  • PEM-encoded to a file. This is a Base64-encoded DER certificate that is enclosed between BEGIN CERTIFICATE and END CERTIFICATE tags.

  • PEM CUT/Paste Buffer. This displays the certificate data so you can copy it to the system Clipboard. You can then pasted it directly into a cryptography-enabled application.

To export the public certificate:

  1. In the Administration Console, click Security > Trusted Roots.

  2. Click the name of the trusted root.

  3. On the Certificate Details page, click Export Public Certificate, then click the file type.

  4. Save the output file to the location of your choosing.

3.4.5 Viewing Trust Store Details

  1. In the Administration Console, click Security > Trusted Roots.

  2. Under the Devices column, click the name of a trust store.

  3. View the following information:

    Field

    Description

    Trust store name

    The name of the selected trust store.

    Trust store type

    The type of trust store, such as Java, PEM, or DER.

    Cluster of Device name

    The name of the cluster using this trust store or the single device that is using the trust store.

    Cluster Members’ Trust Stores

    The trust stores assigned to a cluster. If a device does not belong to a cluster, this section does not appear.

    Trusted Roots

    The trusted roots that are stored in the trust store.

  4. Click Close.

3.4.6 Viewing Trusted Root Details

  1. In the Administration Console, click Security > Trusted Roots.

  2. Click the name of a trusted root.

  3. View the following information:

    Field

    Description

    Issuer

    The name of the CA that created the certificate.

    Serial number

    The serial number of the certificate.

    Subject

    The subject name of the certificate.

    Valid from

    The first date and time that the certificate is valid.

    Valid to

    The date and time that the certificate expires.

    Devices

    The devices that are configured to hold this certificate on their file system.

    Key size

    The key size that was used to create the certificate.

    Signature algorithm

    The signature algorithm that was used to create the certificate.

    Finger print (MD5)

    The certificate's message digest that was calculated with the MD5 algorithm. It is embedded into the certificate at creation time. It can be used to uniquely identify a certificate. For example, users can verify that a certificate is the one they think it is by matching this published MD5 fingerprint with the MD5 fingerprint on the local certificate.

    Finger print (SHA1)

    The certificate's message digest that was calculated with the SHA1 algorithm. It is embedded into the certificate at creation time. It can be used to uniquely identify a certificate. For example, users can verify that a certificate is the one they think it is by matching a published SHA1 fingerprint with the SHA1 fingerprint on the local certificate.

    The Subject Alternate Names section indicates whether an application should reject the certificate if the application does not understand the alternate name extensions. Any configured alternate names are displayed in the list.

    The Key Usage section indicates whether an application should reject the certificate if the application does not understand the key usage extensions. The following are possible:

    Sign CRLs: Indicates whether the certificate is used to sign CRLs (Certificate Revocation Lists).

    Sign certificates: Indicates that the certificate is used to sign other certificates.

    Encrypt other keys: Indicates that the certificate is used to encrypt keys.

    Encrypt data directly: Indicates that the certificate encrypts data for private transmission to the key pair owner. Only the intended receiver can read the data.

    Create digital signatures: Indicates that the certificate is used to create digital signatures.

    Non-repudiation: Indicates that the certificate links a digital signature to the signer and the data. This prevents others from duplicating the signature because no one else has the signer’s private key. Additionally, the signer cannot deny having signed the data.

    CRL Distribution Points: Displays a list of Certificate Revocation List (CRL) distribution points that are embedded into the certificate as an extension at certificate creation time. Implementations search the CRL from each distribution point (the distribution point is usually a URI that points to a store of revoked certificates) to see whether a certificate has been revoked.

    Authority Info Access (OCSP): Displays a list of Online Certificate Status Protocol (OCSP) responders that are embedded into the certificate as an extension at certificate creation time. Implementations query the OCSP responder to see whether a certificate has been revoked.

  4. Select from the following actions:

    Export Public Certificate: Allows you to export a trusted root to a file so that a client can use it to verify the certificate chain sent by a cryptography-enabled application. For more information, see Section 3.3.5, Exporting a Public Certificate.

    Add Trusted Root to Trust Stores: Allows you to assign a trusted root to a device so it can be used by that device. For more information, see Section 3.4.2, Adding Trusted Roots to Trust Stores

  5. Click Close.