3.3 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:

3.3.1 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. Select one of the following:

    • Click the name of a certificate that is not in a CSR Pending state. The Certificate Details page contains the following information about the certificate:

      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 and the keystore that holds them.

      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.

      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 whether the certificate is used to sign other certificates.

      Encrypt other keys

      Indicates whether the certificate is used to encrypt keys.

      Encrypt data directly

      Indicates whether the certificate can encrypted data for private transmission to the key pair owner. Only the intended receiver can read the data.

      Create digital signatures

      Indicates whether the certificate can create digital signatures.

      Non-repudiation

      Indicates whether 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

      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)

      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.

    • Click the name of a certification in a CSR Pending state. The following information is displayed:

      Subject

      The subject name of the certificate.

      Valid from

      The date and time that the request was generated.

      Valid to

      The date and time that the request expires.

      Devices

      No entries. A CSR cannot be assigned to a device.

      Key size

      The key size that was used to create the request.

      Signature algorithm

      The signature algorithm that was used to create the request.

      State

      Displays CSR Pending, indicating that the request has been generated.

      CSR data

      The certificate signing request data. You can either export this data or copy and paste it into CA’s request tool.

  3. (Conditional) For a certificate not in a CSR Pending state, select one of the following actions:

    Renew: Allows you to renew the certificate. For more information, see Section 3.3.3, Renewing a Certificate.

    Export Private/Public Keypair: Allows you to 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. For more information, see Section 3.3.4, Exporting a Private/Public Key Pair

    Export Public Certificate: Allows you to export a public key certificate to a file. For more information, see Section 3.3.5, Exporting a Public Certificate.

    Add Certificate to Keystores: Allows you to assign the certificate to keystore so it can be used by Access Manager. For more information, see Section 3.3.2, Adding a Certificate to a Keystore.

  4. (Conditional) For a certificate in a CSR Pending state, select one of the following actions:

    Import Signed Certificate: Allows you to import the certificate that was generated for this request. For more information, see Section 3.2.5, Importing a Signed Certificate.

    Export CSR: Allows you to export the CSR to a CSR file.

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

NOTE:For problems related to failures in adding certificates to a keystore and for validating the cross device-existence of the Trusted Root of the certificates present in a particular keystore, see Section 7.3, Troubleshooting Options for Certificate Problems.

3.3.3 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 is expiring, you can cut and paste its text to send it to the CA to get a renewed certificate, then import the newly signed certificate.

For the certificates that Access Manager uses internally, a certificate process is started with Tomcat. This process runs once every 24 hours. It checks all the internal certificates and determines if they are going to expire within 30 days. If they are due to expire, the process automatically regenerates the certificate or trusted root. When a certificate is regenerated, the following message appears:

One or more automatically created certificates were regenerated. Reboot the entire administration console as soon as possible to avoid interruption of service.

This message appears when the administrator logs into the Administration Console, or if the administrator is already logged in, when the administrator switches from one page to another.

This event is also auditing. Another audit event is also generated which tells the administrator to restart any effected services. When the Administration Console certificate and the eDirectory certificates are expiring, a log entry is written to the app_sc log file. The log entry contains the “Recreating auto-generated certificates” string as well as a couple success or failure messages per key re-generated.

Certificates and trusted roots that are manually created with the Access Manager CA or are imported into Administration Console use a different process. The administrator is warned that these certificates are expiring when the administrator logs in to the Administration Console. The following message is displayed:

Warning: the following certificates are expired or will expire within X days: <certA>, <certB>.

This message is displayed each time the administrator logs into the Administration Console. Events for the expiration of these certificates are not audited and are not logged.

To renew a 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.

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

3.3.5 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 the 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.

3.3.6 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 PFX/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 *.p12 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 7.1.1, Importing an External Certificate Key Pair.

  5. Continue with Adding a Certificate to a Keystore.

3.3.7 Reviewing the Command Status for Certificates

You can view the status of the commands that have been sent to the certificate server for execution.

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

  2. Use the following options to review or change a server’s certificate command status:

    • Delete: To delete a command, select the check box for the command, then click Delete. The selected command is cleared.

    • Refresh: Click Refresh to update the current cache of recently executed commands.

    • Name: Click this box to select all the commands in the list, then click Refresh or Delete.

    The following table describes the features on this page:

    Column Name

    Description

    Name

    Contains the display name of the command. Click the link to view additional details about the command.

    Status

    Specifies the status of the command. Some of the possible states of the command include Pending, Incomplete, Executing, and Succeeded.

    Type

    Specifies the type of server, such as Identity Server or Access Gateway.

    Commands

    Specifies the command given, such as Import certificate, or Import trusted root.

    Admin

    Specifies if the system or a user issued the command. If a user issued the command, the DN of the user is displayed.

    Date & Time

    Specifies the local date and time the command was issued.

  3. To review command information, click a link under the Name column.

    Command information for a certificate

    This page displays status information about the command and allows you to perform the following tasks:

    Refresh: Select this option to refresh the data for this command.

    Delete: Select this option to clear this command.

    The following command information is listed:

    Name: Specifies the display name that has been given to the command.

    Type: Specifies the type of command.

    Admin: Specifies whether the system or a user issued the command. If a user issued the command, the field contains the DN of the user.

    Status: Specifies the status of the command, and includes such states as Pending, Incomplete, Executing, and Succeeded.

    Last Executed On: Specifies when the command was issued. The date and time are displayed in local time. If the command failed, additional information is available.

    For a command that the Administration Console can successfully process, the page displays a Command Execution Details section with the name of the command and the command results.

  4. Click Close.

3.3.8 Keystore Details

The Keystore Details page allows you to view associated cluster member keystores and to replace certificates associated with the keystore.

Not all keystores are associated with a cluster configuration. Those that are (for example, the Signing and Encryption keystores) display the following information:

Column

Description

Keystore Name

The name of the keystore.

Type

The type of keystore, such as Java or PKCS12.

Device or Cluster Name

The name of the device or of the cluster that is using the keystore.

Some keystores require a single certificate, so you can only replace the certificate. Other keystores can contain multiple certificates. In this type of keystore, you can add and remove certificates.

To view a keystore:

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

  2. Click the down-arrow in the Devices column, then select a keystore.

  3. To remove a certificate, select the certificate, then click Remove.

    This option is not available for all keystores.

  4. To add or replace a certificate:

    1. Click either Add or Replace.

    2. Fill in the following fields:

      Certificate: Specifies the certificate you want to add. You can browse to locate the certificate. When you browse, the system displays the Select Certificate page. Select the certificate, then click OK.

      Alias(es): Specifies the certificate alias. This name is displayed among the list of certificates assigned to the keystore.

      Overwrite keys with the same alias: (If available) Select if you want only one certificate with the specified alias in the keystore.

    3. Click OK.

  5. Click Close.