3.2 Managing Certificates

Access Manager comes with certificates for testing purposes. The test certificates are called test-signing, test-encryption, test-provider, test-consumer, and test-connector. At a minimum you must create two SSL certificates: one for Identity Server test-connector and one for the Access Gateway reverse proxy. Then you replace the predefined certificates with the new ones.

If you install a secondary Administration Console, the certificate authority (CA) is installed with the first instance of eDirectory™, and the secondary consoles have eDirectory replicas, and therefore no CA software. All certificate management must be done from the primary Administration Console. Certificate management commands issued from a secondary Administration Console can work only if the primary console is also running properly. Other commands can work independently of the primary console.

IMPORTANT:Before generating any certificates with the Administration Console CA, make sure time is synchronized within one minute among all of your Access Manager devices. If the time of the Administration Console has a time that is before the device for which you are creating the certificate, the device rejects the certificate.

The following sections contain detailed information about creating and managing certificates for Access Manager:

3.2.1 Creating Certificates

This task involves creating a certificate to be signed locally, or creating one that generates the CSR to be signed externally, which you later import after signing.

Creating a Locally Signed Certificate

By default, the Access Manager installation process creates the local CA for you. eDirectory contains a CA that can issue and sign certificates, and a certificate server that generates or imports certificates and keys, and generate CSRs

  1. In the Administration Console, click Security > Certificates.

    Certificates page

  2. Click New.

    Creating a new certificate

  3. Select the following option:

    Use local certificate authority: Creates a certificate signed by the local CA (or Organizational CA), and creates the private key. For information about creating a CSR, see Generating a Certificate Signing Request.

  4. Provide a certificate name:

    Certificate name: The name of the certificate. Pick a unique, system-wide name for the certificate that you can easily associate with the certificate’s purpose. The name must contain only alphanumeric characters and no spaces.

  5. For Subject, click the Edit button to display a dialog box that lets you add the appropriate attributes for the subject name.

    Edit subject

    The subject is an X.500 formatted distinguished name that identifies the entity that is bound to the public key in an X.509 certificate. Choose the subject name that the browser expects to find in the certificate. The name you enter must be fully distinguished. Completing all the fields creates a fully distinguished name that includes the appropriate types (such as C for country, ST for state, L for location, O for organization, OU for organizational unit, and CN for common name). For example, cn=AcmeWebServer.ou=Sales.o=Acme.c=US.

    The following attributes are the most common ones used in certificate subjects:

    Common name: The name or IP of the server.

    Enter the value, for example AcmeWebServer. Do not include the type (cn=). The UI adds that for you.

    For the Identity Server, this is the domain name of the base URL of the Identity Server configuration. This value cannot be an IP address or begin with a number, in order to ensure that trust does not fail between providers.

    Organizational unit: Describes departments or divisions.

    Organization: Differentiates between organizational divisions.

    City or town: Commonly referred to as the Locality.

    State or province: Commonly referred to as the State.

    Country: The country, such as US.

    Use the Additional Attributes drop-down menus to add additional attributes. For more information about these attributes, see Additional Attributes.

  6. Click OK, then fill in the following fields:

    Signature algorithm: The algorithm you want to use (SHA-1, MD-2, or MD-5). SHA-1 is currently recommended.

    Valid from: The date from which the certificate is valid. For externally signed certificates, the external certificate authority sets the validity period.

    Months valid: The number of months that the certificate is valid.

    Key size: The size of the key. Select 512, 1024, 2048, or 4096.

  7. (Optional) To configure advanced options, click Advanced Options.

    Certificate advanced settings

  8. Configure the following options as necessary for your organization:

    Critical: Specifies that an application should reject the certificate if the application does not understand the key usage extensions.

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

    Encrypt data directly: Encrypts data for private transmission to the key pair owner. Only the intended receiver can read the data.

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

    Non-repudiation: 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.

  9. If you are creating a key for a certificate authority, configure the following options:

    This key is for a Certificate Authority: Specifies that this certificate is for the local configuration (eDirectory) certificate authority.

    If you create a new CA, all the keys signed by the CA being replaced no longer have a trusted CA. You might also need to reassign the new CA to all the trust stores that contained the old CA.

    Critical: Enforces the basic constraints you specify. Select one of the following:

    • Unlimited: Specifies no restriction on the number of subordinate certificates that the CA can verify.

    • Do not allow intermediate signing certificates in certificate chain: Prevents the CA from creating other CAs, but it can create server or user certificates.

    • Number of allowable intermediate signing certificates in signing chain: Specifies how many subordinate certificates are allowed in the certificate chain. Values must be 1 or more. Entering 0 creates only entity objects.

  10. (Optional) To create subject alternative names used by the certificate, click the Edit Subject Alternate Names button.

    Alternate names can represent the entity identified by the certificate. The certificate can identify the subject CN=www.OU=novell.O=com, but the subject can also be known by an IP address, such as 222.111.100.101, or a URI, such as www.novell.com, for example.

    Critical: Specifies that if an application does not understand the alternate name extensions, it should reject the certificate.

  11. Click New.

    Subject alternative names

    Name Type: Names as specified by RFC 2459. Use the drop-down list to specify a name type, such as:

    • Directory name: An X.500 directory name. The required format for the name is .<attribute name>=<attribute value>. For example:

      .O=novell.C=US

      Access Manager supports the following attributes:

      • Country (C)
      • Organization (O)
      • Organizational Unit (OU)
      • State or Province (S or ST)
      • Locality (L)
      • Common Name (CN)

    • IP Address: An IP address such as 222.123.123.123

    • URI: A URI such as www.novell.com.

    • Registered ID: An ASN.1 object identifier.

    • DNS Name: A domain name such as novell.com.

    • Email Address (RFC 822 name): An e-mail address such as ca@novell.com.

    • X400 Name: The messaging and e-mail standard specified by the ITU-TS (International Telecommunications Union - Telecommunication Standard Sector). It is an alternative to the more prevalent Simple Mail Transfer Protocol (SMTP) e-mail protocol. X.400 is common in Europe and Canada.

    • EDI Party: EDI (Electronic Data Interchange) is a standard format for exchanging business data.

    • Other: A user-defined name.

    Name: The display alternative name.

  12. Click OK.

Additional Attributes

Use the drop-down menus to add additional attributes. These values allow you to specify additional fields that are supported by eDirectory, and you can include them as part of the subject to further identify the entity represented by the certificate.

CN: The Common name attribute in the list of Commonly used attributes (OID: 2.5.4.3)

C: The Country attribute in the list of Commonly used attributes (OID: 2.5.4.6)

SN: The surname attribute (OID: 2.5.4.4)

L: The locality attribute, which is the City or town attribute in the list of Commonly used attributes (OID: 2.5.4.7)

ST: The State or province attribute in the list of Commonly used attributes (OID: 2.5.4.8)

S: The State or province attribute in the list of Commonly used attributes (OID: 2.5.4.8)

O: The Organization attribute in the list of Commonly used attributes (OID: 2.5.4.10)

OU: The Organizational unit attribute in the list of Commonly used attributes (OID: 2.5.4.11)

street: Describes the street address (OID: 2.5.4.9)

serialNumber: Specifies the serial number of a device (OID: 2.5.4.5)

title: Describes the position or function of an object (OID: 2.5.4.12)

description: Describes the associated object (OID: 2.5.4.13)

searchGuide: Specifies a search filter (OID: 2.5.4.14)

businessCategory: Describes the kind of business performed by an organization (OID: 2.5.4.15)

postalAddress: Specifies address information required for the physical delivery of postal messages (OID: 2.5.4.16)

postalCode: Specifies the postal code of an object (OID: 2.5.4.17)

postOfficeBox: Specifies the post office box for the physical delivery of mail (OID: 2.5.4.18)

physicalDeliveryOfficeName: Specifies the name of the city or place where a physical delivery office is located (OID: 2.5.4.19)

telephoneNumber: Specifies a telephone number (OID: 2.5.4.20)

telexNumber: Specifies a telex number (OID: 2.5.4.21)

teletexTerminalIdentifier: Specifies an identifier for a telex terminal (OID: 2.5.4.22)

facsimileTelephoneNumber: Specifies the telephone number for a facsimile terminal (OID: 2.5.4.23)

x121Address: Specifies the address used in electronic data exchange (OID: 2.5.4.24)

internationalISDNNumber: Specifies an international ISDN number used in voice, video, and data transmission (OID: 2.5.4.25)

registeredAddress: Specifies the postal address for the delivery of telegrams or expedited documents (OID: 2.5.4.26)

destinationIndicator: Specifies an attribute used in telegram services (OID: 2.5.4.27)

preferredDeliveryMethod: Specifies the preferred delivery method for a message (OID: 2.5.4.28)

presentationAddress: Specifies an OSI presentation layer address (OID: 2.5.4.29)

supportedApplicationContext: Specifies the identifiers for the OSI application contexts in the application layer (OID: 2.5.4.30)

member: Specifies the distinguished name of an object associated with a group or a list (OID: 2.5.4.31)

owner: Specifies the name of an object that has responsibility for another object (OID: 2.5.4.32)

roleOccupant: Specifies the distinguished name of an object that fulfills an organizational role (OID: 2.5.4.33)

seeAlso: Specifies the distinguished name of an object that contains additional information about the same real world object (OID: 2.5.4.34)

userPassword: Specifies the object's password (OID: 2.5.4.35)

name: Specifies a name that is in the UTF-8 form of the ISO 10646 character set (OID: 2.5.4.41)

givenName: Specifies the given or first name of an object (OID: 2.5.4.42)

initials: Specifies the initials of an object (OID: 2.5.4.43)

generationQualifier: Specifies the generation of an object, which is usually a suffix (OID: 2.5.4.44)

x500UniqueIdentifier: Specifies an identifier which distinguishes between objects when a DN has been reused (OID: 2.5.4.45)

dnQualifier: Specifies information which makes an object unique when information is being merged from multiple sources and objects could have the same RDNs (OID: 2.5.4.46)

enhancedSearchGuide: Specifies a search filter used by X.500 users (OID: 2.5.4.47)

protocolInformation: Specifies information which is used with the presentationAddress attribute (OID: 2.5.4.48)

distinguishedName: Specifies the distinguished name of an object (OID: 2.5.4.49)

uniqueMember: Specifies the distinguished name of an object associated with a group or a list (OID: 2.5.4.50)

houseIdentifier: Identifies a building within a location (OID: 2.5.4.51)

dmdName: Specifies a directory management domain (OID: 2.5.4.54)

E: Specifies an email address.

EM: Specifies an e-mail address.

DC: Specifies the domain name for an object (OID: 0.9.2342.19200300.100.1.25)

uniqueID: Contains an RDN-type name that can be used to create a unique name in the tree (OID: 0.9.2342.19200300.100.1.1)

T: Specifies the name of the tree root object (OID: 2.16.840.1.113719.1.1.4.1.181)

OID: Specifies an object identifier in dot notation.

Generating a Certificate Signing Request

  1. In the Administration Console, click Security > Certificates, then click New.

  2. Select the following option:

    Use external certificate authority: Generates a Certificate Signing Request (CSR) for you to send to the CA for signing. A third-party CA is managed by a third party outside of the eDirectory tree. An example of a third party CA is VeriSign*. After the signed certificate is received, you need to import the certificate. See Importing a Signed Certificate.

  3. Fill in the following fields:

    Certificate name: The name of the certificate. Pick a unique, system-wide name for the certificate that you can easily associate with the certificate’s purpose. The name must contain only alphanumeric characters and no spaces.

    Subject: An X.500 formatted distinguished name that identifies the entity that is bound to the public key in an X.509 certificate. Choose the subject name that the browser expects to find in the certificate. The name you enter must be fully distinguished. Completing all the fields creates a fully distinguished name that includes the appropriate types (such as C for country, ST for state, L for location, O for organization, OU for organizational unit, and CN for common name). For example, cn=AcmeWebServer.ou=Sales.o=Acme.c=US

  4. Click the Edit button to display a dialog box that lets you add appropriate locality information types for the subject name.

    The following attributes are the most common ones used in certificate subjects:

    Common name: The name or IP of the Web server. Enter only the value. Do not enter the type (cn=). The UI adds it for you.

    Organizational unit: Describes departments or divisions.

    Organization: Differentiates between organizational divisions.

    City or town: Commonly referred to as the Locality.

    State or province: Commonly referred to as the State.

    Country: The country, such as US.

    Use the Additional Attributes drop-down lists to add additional attributes. These values allow you to specify additional fields that are supported by eDirectory, and you can include them as part of the subject to further identify the entity represented by the certificate.

  5. Click OK, then fill in the following fields:

    Signature algorithm: The algorithm you want to use (SHA-1, MD-2, or MD-5). SHA-1 is currently recommended.

    Valid from: The date from which the certificate is valid. For externally signed certificates, the external certificate authority sets the validity period.

    Months valid: The number of months that the certificate is valid.

    Key size: The size of the key. Select 512, 1024, 2048, or 4096.

  6. If necessary, fill in the certificate fields, which are described in Creating a Locally Signed Certificate.

  7. Click OK.

  8. On the Certificate Details page, copy the CSR data and send the information to the external CA.

    The certificate status is CSR Pending until you import the signed certificate.

  9. Click Close.

Continue with Importing a Signed Certificate after you receive the signed certificate and the trusted root (CA chain).

Importing a Signed Certificate

After you receive the signed certificate and the CA chain, you must import it. There are several ways in which the CA can return the certificate. Typically, the CA either returns one or more files each containing one certificate, or returns a file with multiple certificates in it.

  1. In the Administration Console, click Security > Certificates, then click the certificate name.

  2. Click Import Signed Certificate.

  3. In the Import Signed Certificate dialog box, browse to locate the certificate data file, or paste the certificate data text into the Certificate data text field.

  4. To import the CA chain, click Add trusted root, then locate the certificate data.

  5. Click Add intermediate certificate if you need to continue adding certificates to the chain.

  6. Click OK, then click Close on the Certificate Details page.

The certificate is now available for use by Access Manager devices.

If you receive an error when attempting to import the certificate, see Section B.0, Troubleshooting Certificate Issues.

3.2.2 Managing Certificates and Keystores

You can import certificates created by an external certificate authority. These certificates then need to be assigned to a device by adding the certificate to the device’s keystore. The subject name of the certificate needs to match the DNS name of the device, or if you are using wildcard certificates, the main domain name needs to match. You can perform the following certificate tasks:

Importing a Private/Public Key Pair

If you created a key pair that was exported from another certificate management system, you can import the key pair and then assign it to an Access Manager device. The file needs to be in PKCS12 (*.pfx) or (*.p12) format.

  1. In the Administration Console, click Security > Certificates.

  2. Choose Actions > Import Private/Public Keypair.

  3. Fill in the following fields:

    Certificate name: The name of the certificate. This is a system-wide, unique name used by Access Manager. The name must contain only alphanumeric characters and no spaces. If the name starts with a number, an underline (_) prefix is added to the name so that the name conforms to XML requirements. If the name contains invalid characters, it is automatically renamed.

    Keystore password: Type the encryption/decryption password established when exporting the certificate.

    Certificate data file (PFX/PKCS12): The certificate file to import. You can browse to locate the PFX or PKCS12 file.

    Certificate data file (JKS): To locate a JKS file, select this option, then click the Browse button.

  4. Click OK.

    If you receive an error when importing the certificate, the error comes from either NICI or PKI. For a description of these error codes, see Novell® Certificate Server Error Codes and Novell International Cryptographic Infrastructure. For general certificate import issues, see Section B.1.1, Importing an External Certificate Key Pair.

  5. Continue with Adding a Certificate to a Keystore.

Adding a Certificate to a Keystore

After importing a certificate, you need to assign the certificate to keystore before it is used by Access Manager.

  1. In the Administration Console, click Security > Certificates.

  2. Select a certificate.

  3. Click Actions > Add Certificate to Keystores.

  4. Specify the keystore to which you are adding the certificate. To locate a keystore:

    1. Click the Select Keystore button.

      For a description of the Access Manager created keystores, see Section 3.1.3, Access Manager Keystores.

    2. On the Keystore Details page, select the keystore, then click OK.

  5. Fill in the following fields:

    Alias: Specify the certificate alias.

    Overwrite keys with same alias: Select whether to overwrite certificates with the same alias, if the alias you specify is already in use in that keystore.

  6. Click OK.

  7. Update the device or devices that are using this keystore.

Renewing a Certificate

The Certificate Details page lists the properties of a certificate, such as certificate type, name, subject, and assigned keystores. This page also includes the original CSR when the certificate is still in a pending state (for example, you have generated the CSR, but you have not yet received and imported the signed certificate). If the certificate has expired, you can cut and paste its text to send it to the CA to get a renewed certificate, then import the newly signed certificate.

  1. In the Administration Console, click Security > Certificates.

  2. Click the certificate name.

  3. Click Renew.

    Renewing a certificate

  4. On the Renew page, either browse to locate and select the certificate or select the Certificate data text (PCM/Base64) option and paste the certificate data into the text box.

  5. Click OK.

  6. Update the device using the certificate.

Exporting a Private/Public Key Pair

When you create a certificate, you can specify whether it is exportable. If a key is exportable, it can be extracted and put in a file along with the associated certificate. The file is written in an industry standard format, PKCS#12, which allows it to be transported to other platforms. It is encrypted with a user-specified password to protect the private key.You can export private certificates to obtain a backup copy of the key, to move the key to a different server, or to share the key between servers.

You cannot export a certificate if you enabled the Do not allow private key to be exportable option while creating the certificate.

  1. In the Administration Console, click Security > Certificates.

  2. On the Certificates page, click the certificate.

  3. On the Certificate Details page, click Export Private/Public Keypair.

    Exporting a private/public key pair

  4. Select the format for the key:

    PFX/PKCS12: Public Key Cryptography Standards #12 (PKCS#12) format, which is also called PFX format. This format can be used to create JKS or PEM files.

    JKS: Java keystore format.

  5. Specify the password in the Encryption/decryption password field, then click OK.

    IMPORTANT:Remember this password because you need it to re-import the key.

  6. Click OK.

Exporting a Public Certificate

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 > Certificates.

  2. Click the certificate name.

  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.

Viewing Certificate Details

The Certificate Details page lists the properties of a certificate, such as certificate type, name, subject, and assigned keystores. The fields are not editable.

  1. In the Administration Console, click Security > Certificates.

  2. Click the name of a certificate.

    The Certificate Details page contains the following information about the certificate:

    Issuer: Displays the name of the CA that created the certificate.

    Serial number: Displays the serial number of the certificate.

    Subject: Displays the subject name of the certificate.

    Valid from: Displays the first date and time that the certificate is valid.

    Valid to: Displays the date and time that the certificate expires.

    Devices: Indicates the devices that are configured to hold this certificate on their file system.

    Key size: Indicates the key size that was used to create the certificate.

    Signature algorithm: Indicates the signature algorithm that was used to create the certificate.

    Finger print (MD5): Displays 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, a user 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): Displays 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, a user 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.

    Subject Alternate Names: Critical: 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.

    Key Usage: Critical: Indicates whether an application should reject the certificate if the application does not understand the key usage extensions.

    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.

3.2.3 Managing Trusted Roots and Trust Stores

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. You can perform the following tasks

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

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.

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.

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.

Viewing Trust Store Details

To view the details of a trust store:

  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.

    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 or 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.

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, a user 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, a user 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.

3.2.4 Security Considerations for Certificates

Your security deployment plan should contain policies for the following:

  • Key size for certificates: The Access Manager product ships with a CA that can create certificates with a key size of 512, 1024, 2048 or 4096. Select the maximum size supported by the applications that you are protecting with Access Manager.

  • Certificate renewal dates: We recommend that certificates should be renewed every two years. Your security needs might allow for a longer or shorter period.

  • Trusted certificate authorities: The Access Manager ships with a CA, and during installation of the various components, it creates and distributes certificates. For added security, you might want to replace these certificates with certificates from a well-known CA.