4.1 Certificate Authority Tasks

4.1.1 Creating an Organizational Certificate Authority Object

This task is described in Section 3.2, Creating an Organizational Certificate Authority Object.

4.1.2 Issuing a Public Key Certificate

This task allows you to generate certificates for cryptography-enabled applications that do not recognize Server Certificate objects.

Your Organizational CA works the same way as an external CA. That is, it has the ability to issue certificates from certificate signing requests (CSRs). You can issue certificates using your Organizational CA when a user sends a CSR to you for signing. The user requesting the certificate can then take the issued certificate and import it directly into the cryptography-enabled application.

To issue a public key certificate:

  1. Launch iManager.

  2. Log in to the eDirectory tree as an administrator with the appropriate rights.

    To view the appropriate rights for this task, see Section B.0, Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click Novell Certificate Server > Issue Certificate.

  4. Use the Browse button to locate a CSR file, open the file, then click Next.

  5. Specify the key type, the key usage, and the extended key usage, then click Next.

  6. Specify the certificate basic constraints, then click Next.

  7. Specify the subject name, the validity period, the effective and expiration dates, and any custom extensions, then click Next.

  8. Review the parameters sheet. If it is correct, click Finish. If not, click Back until you reach the point where you need to make changes.

    When you click Finish, a dialog box explains that a certificate has been created. You can save the certificate to the system clipboard in Base64 format, to a Base64-formatted file, or to a binary DER-formatted file. You can also click Details to view details about the issued certificate.

4.1.3 Viewing the Organizational CA's Properties

In addition to the eDirectory rights and properties that can be viewed with any eDirectory object, you can also view properties specific to the Organizational CA, including the properties of the public key certificate and the self-signed certificate associated with it.

  1. Launch iManager.

  2. Log in to the eDirectory tree as an administrator with the appropriate rights.

    To view the appropriate rights for this task, see Section B.0, Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click Novell Certificate Server > Configure Certificate Authority.

    This brings up the property pages for the Organizational CA, which include a General page, a CRL page, and a Certificates page.

  4. Click the tabs you want to view.

4.1.4 Viewing an Organizational CA's Public Key Certificate Properties

  1. Launch iManager.

  2. Log in to the eDirectory tree as an administrator with the appropriate rights.

    To view the appropriate rights for this task, see Section B.0, Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click Novell Certificate Server > Configure Certificate Authority.

    This brings up the property pages for the Organizational CA, which include a General page, a CRL page, a Certificates page, and other eDirectory-related pages.

  4. Click Certificates, then click the nickname of the public key certificate you want to view.

  5. To view the certificate chain, click the plus sign (+) in front of the certificate’s nickname to expand the view.

  6. Click Close.

4.1.5 Viewing the CA's Self-Signed Certificate Properties

  1. Launch iManager.

  2. Log in to the eDirectory tree as an administrator with the appropriate rights.

    To view the appropriate rights for this task, see Section B.0, Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click Novell Certificate Server > Configure Certificate Authority.

    This brings up the property pages for the Organizational CA, which include a General page, a CRL page, and a Certificates page.

  4. Click Certificates, then click the nickname of the self-signed certificate you want to view.

    If this is a Subordinate CA, there is no self-signed certificate.

  5. To view the certificate chain, click the plus sign (+) in front of the certificate’s nickname to expand the view.

  6. Click Close.

4.1.6 Exporting the Organizational CA's Self-Signed Certificate

The self-signed certificate can be used for verifying the identity of the Organizational CA and the validity of a certificate signed by the Organizational CA.

From the Organizational CA's property page, you can view the certificates and properties associated with this object. From the self-signed certificate property page, you can export the self-signed certificate to a file for use in cryptography-enabled applications.

The self-signed certificate that resides in the Organizational CA is the same as the Trusted Root certificate in a Server Certificate object that has a certificate signed by the Organizational CA. Any service that recognizes the Organizational CA's self-signed certificate as a trusted root can accept a valid user or server certificate signed by the Organizational CA.

This task does not apply if the CA is a Subordinate CA.

To export the Organizational CA's self-signed certificate:

  1. Launch iManager.

  2. Log in to the eDirectory tree as an administrator with the appropriate rights.

    To view the appropriate rights for this task, see Section B.0, Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click Novell Certificate Server > Configure Certificate Authority.

    This brings up the property pages for the Organizational CA, which include a General page, a CRL page, a Certificates page, and other eDirectory-related pages.

  4. Click Certificates, then select the self-signed certificate.

  5. Click Export and follow the prompts to export the certificate.

    This starts the Certificate Export Wizard. Ensure the Export private key check box is not selected (does not have a check mark).

  6. Click Finish.

4.1.7 Backing Up an Organizational CA

Novell recommends that you back up your Organizational CA's private key and certificates in case the Organizational CA's host server has an unrecoverable failure. If a failure should occur, you can use the backup file to restore your Organizational CA to any server in the tree that has Certificate Server version 2.21 or later installed.

NOTE:The ability to back up an Organizational CA is available only for Organizational CAs created with Certificate Server version 2.21 or later. In previous versions of Certificate Server, the Organizational CA's private key was created in a way that made exporting it impossible.

The backup file contains the CA's private key, self-signed certificate, public key certificate, and several other certificates necessary for it to operate. This information is stored in PKCS #12 format (also known as PFX).

The Organizational CA should be backed up when it is working properly.

With Certificate Server 3.2 and later, in order to completely back up the Certificate Authority, it is necessary to back up the CRL database and the Issued Certificates database.

For other platforms, both of these databases are located in the same directory as the eDirectory dib files. The defaults for these locations are as follows:

  • Windows: c:\novell\nds\dibfiles

  • Linux/AIX/Solaris: /var/opt/novell/edirectory/data/dib

These defaults can be changed at the time that eDirectory is installed.

The files to back up for the CRL database are crl.db, crl.01 and the crl.rfl directory. The files to back up for the Issue Certificates database are cert.db, cert.lck, cert.01, and the cert.rfl directory.

The eDirectory dib directory should be part of a standard and regular backup plan.

To back up the Organizational CA:

  1. Launch iManager.

  2. Log in to the eDirectory tree as an administrator with the appropriate rights.

    To view the appropriate rights for this task, see Section B.0, Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click Novell Certificate Server > Configure Certificate Authority.

  4. Click Certificates, then select either the Self Signed Certificate or the Public Key Certificate. Both certificates are written to the file during the backup operation.

  5. Click Export.

    This opens a wizard that helps you export the certificates to a file.

  6. Choose to export the private key, specify a password with 6 or more alphanumeric characters to use in encrypting the PFX file, then click Next.

  7. Click the Save the exported certificate to a file link and provide the filename and the location for the backup file.

  8. Click Save.

  9. Click Close.

    The encrypted backup file is written to the location specified. It is now ready to be stored in a secure location for emergency use.

IMPORTANT:The exported file should be put on a diskette or some other form of backup media and stored in a secure place. The password used to encrypt the file should be committed to memory or stored in a safe place to ensure that it is available when needed, but inaccessible to others.

4.1.8 Restoring an Organizational CA

If the Organizational CA object has been deleted or corrupted, or if the Organizational CA’s host server has suffered an unrecoverable failure, the Organizational CA can be restored to full operation through using a backup file created as described in Section 4.1.7, Backing Up an Organizational CA.

The ability to restore an Organizational CA is only available in Certificate Server version 2.21 or later.

NOTE:If you were unable to make a backup of the Organizational CA, the Organizational CA might still be recovered if NICI 2.x is installed on the server and a backup was made of the NICI configuration information.

With Certificate Server 3.2 and later, in order to completely restore the Certificate Authority, it is necessary to restore the CRL database and the Issued Certificates database.

For other platforms, both of these databases are located in the same directory as the eDirectory dib files. The defaults for these locations are as follows:

  • Windows: c:\novell\nds\dibfiles

  • Linux/AIX/Solaris: /var/opt/novell/edirectory/data/dib

These defaults can be changed at the time that eDirectory is installed.

The files to restore for the CRL database are crl.db, crl.01 and the crl.rfl directory. The files to restore for the Issue Certificates database are cert.db, cert.lck, cert.01, and the cert.rfl directory.

The eDirectory dib directory should be part of a standard and regular backup plan.

To restore the Organizational CA:

  1. Launch iManager.

  2. Log in to the eDirectory tree as an administrator with the appropriate rights.

    To view the appropriate rights for this task, see Section B.0, Entry Rights Needed to Perform Tasks.

  3. (Conditional) If the Organizational CA object still exists, you need to delete it:

    1. On the Roles and Tasks menu, click Directory Administration > Delete Object.

    2. Browse to and click the Organizational CA object.

    3. Click OK.

  4. From the Roles and Tasks menu, click Novell Certificate Server > Configure Certificate Authority.

    This opens the Create an Organizational Certificate Authority Object dialog box and the corresponding wizard that creates the object

  5. In the creation dialog box, specify the server that should host the Organizational CA and the name of the Organizational CA object. The server specified must have Certificate Server version 2.21 or higher installed and be up and running.

  6. Select the Import option.

  7. Click Next.

  8. Click Read from File, then select the name of the backup file in the dialog box.

  9. Click Open.

  10. Enter the password used to encrypt the file when the backup was made.

  11. Click Finish.

    The Organizational CA’s private key and certificates have now been restored and the CA is fully functional. The backup file can now be stored again for future use.

IMPORTANT:Be sure to protect your backup media.

4.1.9 Moving the Organizational CA to a Different Server

You can move your Organizational CA from one server to another by using the backup and restore procedures outlined in Backing Up an Organizational CA and Restoring an Organizational CA.

With Certificate Server 3.2 and later, in order to completely move the Certificate Authority, it is necessary to move the CRL database and the Issued Certificates database.

For other platforms, both of these databases are located in the same directory as the eDirectory dib files. The defaults for these locations are as follows:

  • Windows: c:\novell\nds\dibfiles

  • Linux/AIX/Solaris: /var/opt/novell/edirectory/data/dib

These defaults can be changed at the time that eDirectory is installed.

The files to move for the CRL database are crl.db, crl.01 and the crl.rfl directory. The files to move for the Issue Certificates database are cert.db, cert.lck, cert.01, and the cert.rfl directory.

  1. Make sure the Organizational CA is functional.

  2. Back up the Organizational CA.

  3. Delete the Organizational CA object.

  4. Restore the Organizational CA to the desired server.

IMPORTANT:Be sure to protect your backup media.

4.1.10 Validating the Organizational CA's Certificates

If you suspect a problem with a certificate or think that it might no longer be valid, you can easily validate the certificate by using iManager. Any certificate in the eDirectory tree can be validated, including certificates issued by external CAs.

The certificate validation process includes several checks of the data in the certificate as well as the data in the certificate chain. A certificate chain is composed of a root CA certificate and, optionally, the certificates of one or more intermediate CAs.

A result of Valid means that all certificates in the certificate chain were found to be valid. Certificates are considered valid if they pass a predefined set of criteria including whether the current time is within the validity period of the certificate, whether it has not been revoked, and whether it has been signed by a CA that is trusted. Only those certificates with a CRL distribution point extension or an OCSP AIA extension are checked for revocation.

A result of Invalid means that one or more certificates in the certificate chain were found to be invalid or their validity could not be determined. Additional information is provided for these certificates, indicating which certificate is considered invalid and why. Click Help for more information about the reason.

To validate a certificate:

  1. Launch iManager.

  2. Log in to the eDirectory tree as an administrator with the appropriate rights.

    To view the appropriate rights for this task, see Section B.0, Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click Novell Certificate Server > Configure Certificate Authority.

  4. Click Certificates, then select the public key certificate or the self signed certificate.

  5. Click Validate.

    The status of the certificate is reported in the Certificate Status field. If the certificate is not valid, the reason is given.

  6. Click OK.

4.1.11 Deleting the Organizational CA

Deleting the Organizational CA object should be done only if absolutely necessary or if you are restoring the Organizational CA from a backup (see Restoring an Organizational CA). The only safe way to delete the object is to do a backup first so that it can be restored later.

However, there are times when the Organizational CA must be deleted and not restored. For example, when merging trees, only one Organizational CA can be in the resulting tree; the other CA must be deleted. Or, when the Organizational CA’s host server is irreparably damaged and no backup of the CA or the NICI configuration was made, the only option remaining is to delete the CA and to begin again.

To delete the Organizational CA object:

  1. Launch iManager.

  2. Log in to the eDirectory tree as an administrator with the appropriate rights.

    To view the appropriate rights for this task, see Section B.0, Entry Rights Needed to Perform Tasks.

  3. Back up the self-signed certificate without the private key.

  4. Create a Trusted Root certificate using the self-signed certificate in the CN=trusted roots.CN=security container. For more information, see

  5. On the Roles and Tasks menu, click Directory Administration > Delete Object.

  6. Browse to and click the Organizational CA object.

  7. Click OK.

4.1.12 Rolling Over an Organizational CA

Two important issues that must be considered when replacing the Organizational Certificate Authority (CA) certificates are:

  • The types of certificates that are being managed

  • The reason that the CA is being replaced

Server Certificate objects (KMOs) contain both the public key certificate for the server and the Trusted Root certificate with which the public key certificate was signed.User certificates are stored as attributes on the user object and are not paired with the Trusted Root that signed them. Therefore, when the trusted root certificate is replaced, server certificates are still valid because the trusted root is still accessible. However, user certificates are immediately invalid unless the Trusted Root certificate is placed in the Trusted Roots container where certificate validation can find it.

There are three reasons to replace the CA:

  • The CA has reached the end of its validity (the CA is expiring).

  • The CA has been compromised.

  • You want to replace the CA certificate for some other reason (a stronger key is desired, a new security policy has made it necessary, you want to have an externally signed CA, etc.).

If the CA is expiring, the certificates that the CA signed are also going to expire. After replacing the CA, each of the signed certificates should be re-created with the new CA.

If the CA has been compromised, then replacing the CA invalidates the user certificates that were signed by the old CA. You can easily replace them by running the Create Default Certificates task in iManager. All certificates that are created by default by Certificate Server are re-created with the new CA. Any certificates that were created in a custom manner need to be manually re-created with the new CA. For more information on creating default certificates through, see Section 4.2.2, Creating Default Server Certificate Objects.

If you want to re-create the CA for some other reason, then storing the trusted root certificate in the Trusted Roots container keeps user certificates valid until you have a chance to re-create them at your convenience.

To replace the trusted root certificate:

  1. Back up the current CA in case you want to recover it later.

  2. Export the Trusted Root certificate that has been used to create the certificates. In older systems, this is most likely the self-signed certificate.

    Recently, the ability has been added to externally sign the CA certificate. If the CA is externally signed, export the public key certificate. All certificates in the chain must have their own object in the Trusted Roots container.

    If the CA has not been compromised, create a Trusted Root certificate in the Trusted Roots container. This ensures that user certificates are still valid until they can be replaced.

  3. Delete the old CA. For information on deleting the Organizational CA, see Section 4.1.11, Deleting the Organizational CA.

  4. Create a new CA. For information on creating a new Organizational CA, see Section 3.2, Creating an Organizational Certificate Authority Object.

  5. If necessary, re-create server certificates by using the Create Default Certificate task in iManager. For information on creating default certificates through iManager, see Section 4.2.2, Creating Default Server Certificate Objects.

    Re-create other server certificates that are not generated by default.

  6. If necessary, re-create user certificates by using the Create User Certificate task in iManager or by viewing the user properties, viewing certificates, and clicking New.