25.4 Managing NetIQ Certificate Server

As a system administrator, you need to perform several tasks to maintain the public key cryptography services provided through NetIQ Certificate Server. Use iManager to perform these tasks. This section provides a brief overview and specific information on completing each task.

Certificate Authority tasks:

Server Certificate object tasks:

User Certificate tasks:

X.509 Certificate Self-Provisioning:

Using eDirectory Certificates with External Applications

Trusted Root object tasks:

Certificate Revocation List (CRL) Tasks:

eDirectory tasks:

Application tasks

25.4.1 Certificate Authority Tasks

Creating an Organizational Certificate Authority Object

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

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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ 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.

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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ 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.

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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ 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.

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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ 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.

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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ 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.

Backing Up an Organizational CA

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

NOTE:The ability to back up an Organizational CA is available only for Organizational CAs created with Certificate Server version 9.0 at a minimum. 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 9.0 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: /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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ 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.

    NetIQ recommends that you select the Self Signed Certificate for RSA and ECDSA certificates separately.

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

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 Backing Up an Organizational CA.

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 9.0, in order to completely restore the Certificate Authority, it is necessary to restore the CRL database and the Issued Certificates database.

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: /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 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 NetIQ 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.

  6. Select the Import option.

    Select both RSA and ECDSA certificates. The Certificate Server requires that both certificates have the same subject name.

    IMPORTANT:The Certificate Server does not support importing external self-signed CA certificates. However, it allows you to import subordinate CA certificates.

  7. Click Next.

  8. In the dialog that opens, click Browse and select the name of the file for RSA and ECDSA.

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

  10. Click OK.

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

IMPORTANT:Be sure to protect your backup media.

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: /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. Export the CA keys

  4. Delete the Organizational CA object.

  5. Stop eDirectory on both the servers

  6. Copy the cert and crl files from the source to the destination server including the rfl logs

  7. Start eDirectory on both the servers

  8. Recreate the Organizational CA on the destination server

IMPORTANT:Be sure to protect your backup media.

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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ 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.

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

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 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 Deleting the Organizational CA.

  4. Create a new CA. For information on creating a new Organizational CA, see 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 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.

25.4.2 Server Certificate Object Tasks

Creating Server Certificate Objects

This task is described in Creating a Server Certificate Object.

Creating Default Server Certificate Objects

The Certificate Server installation creates default Server Certificate objects.

  • SSL CertificateDNS - server_name

  • A certificate for each IP address configured on the server (IPAGxxx.xxx.xxx.xxx - server_name)

  • A certificate for each DNS name configured on the server (DNSAGwww.example.com - server_name)

NOTE:eDirectory does not automatically create SSL CertificateIP. SSL Certificate DNS contains all the IPs listed in the Subject Alternative Name. When you attempt to create or repair the default certificates using the PKI iManager plug-in, the SSL CertificateIP certificate is not created or repaired by default. However, the plug-in interface provides a check box that you can select to override the default behavior and force the creation/repair of the SSL CertificateIP certificate.

eDirectory 9.0 and above automatically creates ECDSA certificates if Organization CA has a ECDSA certificate.

If these certificates become corrupt or invalid for some reason, or if you just want to replace the existing default certificates, you can use the Create Default Server Certificates Wizard, as described in the following procedure:

  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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, select NetIQ Certificate Server > Create Default Certificates.

  4. Browse for and select the server or servers that you want to create default certificates for, then click Next.

  5. Select Yes if you want to overwrite the existing default server certificates or select No if you want to overwrite the existing default server certificates only if they are invalid.

  6. (Single Server only) If you want to use the existing default IP address, select that option. If you want to use a different IP address, select that option and specify the new IP address.

  7. (Single Server only) If you want to use the existing DNS address, select that option. If you want to use a different DNS address, select that option and specify the new DNS address.

  8. Click Next.

  9. Review the summary page, then click Finish.

If you want more control over the creation of the Server Certificate object, you can create the Server Certificate object manually. For more information, see Manually Creating a Server Certificate Object.

Importing a Public Key Certificate into a Server Certificate Object

You import a public key certificate after you have created a certificate signing request (CSR) and the Certificate Authority (CA) has returned the signed public key certificate to you. This task applies when you have created a Server Certificate object by using the Custom option with the External CA signing option.

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. These files can be binary, DER-encoded files (.der, .cer, .crt., .p7b) or they can be textual, Base64-encoded files (.cer, .b64).

If the file has multiple certificates in it, it must be in PKCS #7 format in order to be imported into a Server Certificate object. Additionally, the file must contain all of the certificates to be imported into the object (the root-level CA certificate, any intermediate CA certificates, and the server certificate).

If the CA returns multiple files to you as a result of signing the certificate, each file contains a different certificate that must be imported into the Server Certificate object. If there are more than two files (one for the root-level CA, one or more for the intermediate CAs, and one for the server certificate), these files must be combined into a PKCS #7 file in order to be imported into a Server Certificate object.

There are several ways to create a PKCS #7 file. One way is to import all of the certificates into Internet Explorer. After they have been imported, the server certificate and all of the certificates in the certificate chain can be exported in PKCS #7 format by using Internet Explorer. For more information on how to do this, see External CAs.

Some CAs do not return a root-level CA certificate along with the server certificate. In order to obtain the root-level CA certificate, contact the CA provider directly or call Technical Support.

To import the certificates into a Server Certificate 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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ Certificate Access > Server Certificates.

  4. Click Import next to the Server Certificate object you want to modify.

  5. Browse for and select the certificate data file.

  6. Browse for and select the trusted root data file.

    If all certificates are contained in a single file, leave this field blank.

  7. Click OK.

Exporting a Trusted Root or Public Key Certificate

You export a certificate to a file for the following reasons:

  • A client (such as an Internet browser) can use it to verify the certificate chain sent by a cryptography-enabled application.

  • To provide a backup copy of the file.

You can export the certificate in two file formats: DER-encoded (.der) and Base64-encoded (.b64). The .crt extension can also be used for DER-encoded certificates. You can also export to the system clipboard in Base64 format so that the certificate can be pasted directly into a cryptography-enabled application.

To export a trusted root or public key certificate:

  1. Launch iManager.

  2. Log in to the eDirectory tree as a user with the appropriate rights.

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

  3. On the Roles and Tasks menu, click NetIQ Certificate Access > Server Certificates.

  4. Select the Server Certificate object the particular application is configured to use.

  5. Click Export.

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

  6. Use the drop-down list to specify which certificate to export.

  7. Choose not to export the private key.

  8. Select an export format (binary DER or text encoded base64), then click Next.

  9. Click Save the exported certificate to a file and save the file to a location of your choice.

  10. Click Close > Close > OK.

  11. Use the file as needed.

    For example, if you want to install a trusted root certificate in an Internet Explorer browser, double-click the file. This initiates a wizard that will accept the CA as a trusted root. Accepting the CA as a trusted root means that the browser automatically accepts SSL connections with services that use certificates issued by this CA.

Deleting a Server Certificate Object

You should delete a Server Certificate object if you suspect that the private key has been compromised, if you no longer want to use the key pair, or if the trusted root in the Server Certificate object is no longer trusted.

IMPORTANT:After the Server Certificate object is deleted, you cannot recover it unless you have previously made a backup. Before you delete this object, make sure that no cryptography-enabled applications still need to use it.You can re‑create a Server Certificate object, but you will need to reconfigure any applications that referenced the old object.

To delete a Server Certificate 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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ Certificate Access > Server Certificates.

  4. Select the Server Certificate object you want to delete.

  5. Click OK to delete the object.

Viewing a Server Certificate Object's Properties

In addition to the eDirectory rights and properties that are viewable with any eDirectory object, you can also view properties specific to the Server Certificate object, including the properties of the public key certificate and the Trusted Root certificate associated with it, if they exist.

To view a Server Certificate object's 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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ Certificate Access > Server Certificates.

  4. Click the nickname of the Server Certificate object 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 Cancel.

Viewing a Server Certificate Object's Public Key Certificate Properties

To view a Server Certificate object's public key certificate properties:

  1. Launch iManager.

  2. Log in to the eDirectory tree as a user with the appropriate rights.

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

  3. On the Roles and Tasks menu, click Directory Administration > Modify Object.<change the navigation>

  4. Browse to and click the Server Certificate object you want to view.

  5. Click OK.

  6. Click Public Key Certificate.

    • If a public key certificate is installed, the property page displays the subject's fully typed name, the issuer's fully typed name, and the validity dates of the public key certificate.

    • If the public key certificate has not yet been installed, the property page indicates this.

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

  8. To view additional information about a public key certificate, click the certificate’s nickname to view the Details page.

    The Details page has information contained in the public key certificate.

  9. Click Close > Cancel.

Viewing a Server Certificate Object's Trusted Root Certificate Properties

To view a Server Certificate object's Trusted Root 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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click Directory Administration > Modify Object.change navigation

  4. Browse to and select the Server Certificate object you want to view.

  5. Click OK.

  6. Click Trusted Root Certificate.

    • If a Trusted Root certificate is installed, the property page displays the subject's fully typed name, the issuer's fully typed name, and the validity dates of the trusted root certificate.

    • If the Trusted Root certificate has not yet been installed, the property page indicates this.

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

  8. To view additional information about a Trusted Root certificate, click the certificate’s nickname to view the Details page.

    The Details page has information contained in the trusted root certificate.

  9. Click Close > Cancel.

Backing Up a Server Certificate Object

NetIQ Certificate Server allows you to store certificates signed by third-party certificate authorities in server certificate objects. Often these certificates cost a significant amount of money. Unfortunately, if an unrecoverable failure happens on the server that owns the certificates, the server certificate object can no longer be used. In order to protect against such failures, you might want to back up server certificates signed by external CAs and their associated private keys. Then, if a failure should occur, you can use the backup file to restore your server certificate object to any server in the tree.

The back up file contains the server’s private key, public key certificate, trusted root certificate, and any intermediate CA certificates stored. This information is stored in PKCS #12 format (also known as PFX).

A server certificate object should be backed up when it is working properly.

To backup a Server Certificate 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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click Directory Administration > Modify Object.<change navigation>

  4. Browse to and click the Server Certificate object you want to back up.

  5. Click OK.

  6. Click the Certificates tab.

  7. Click either the Trusted Root certificate or the public key certificate. Both certificates are written to the file during the backup operation.

  8. Click Export.

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

  9. When asked whether to export the private key, select Yes, then click Next.

  10. Specify a password with 6 or more alphanumeric characters to use in encrypting the PFX file.

  11. Click Next.

  12. Click Save the exported certificate to a file. Select the filename and the location for the backup file.

  13. 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 backup media and stored in a secure place. The password used to encrypt the file should be committed to memory or stored in a vault to ensure that it is available when needed, but inaccessible to others.

Restoring a Server Certificate Object

If the Server Certificate object has been deleted or corrupted, or if the server that owned the Server Certificate object has suffered an unrecoverable failure, the object can be restored to full operation using a backup file created as described in Backing Up a Server Certificate Object.

If you were unable to make a backup of the server certificate object, the server certificate object might still be usable if NICI 2.x is installed on the server and a backup was made of the NICI configuration information. For information on how to back up and restore the NICI configuration files, see the “Backing Up and Restoring NICI” section in the Novell International Cryptographic Infrastructure Administration Guide.

To restore the Server Certificate 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 Entry Rights Needed to Perform Tasks.

  3. Delete the old server certificate object.

  4. On the Roles and Tasks menu, click NetIQ Certificate Server > Create Server Certificate.

    This opens the Create a Server Certificate Wizard that creates the object.

  5. In the wizard, specify the server that should own the server certificate object, and specify the certificate nickname of the server certificate. The server must have Certificate Server version 2.21 or higher installed and be up and running.

  6. Select the Import option, then click Next.

  7. Browse for and select the backup file, enter the backup file password, then click Finish.

The server’s private key and certificates have now been restored and the Server Certificate object is fully functional. The backup file can be stored again for future use if desired.

IMPORTANT:Be sure to protect your backup media.

Server Certificate Objects and Clustering

You can set up Server Certificate objects in a clustered environment to ensure that your cryptography-enabled applications that use Server Certificate objects always have access to them. Using the backup and restore feature for Server Certificate objects, you can duplicate the object's keying material from one node in the cluster to all nodes. Using this process for keying material signed by an external CA saves you money by allowing you to duplicate the keying material for one server certificate rather than requiring new keying material for every node in the cluster.

To set up server certificates to work in a clustered environment:

  1. Create a server certificate on a server in the cluster, using either the Organizational CA or an external CA of your choice. See Creating a Server Certificate Object.

    When you create the server certificate objects, the Common Name (CN) portion of the certificate's subject name should be an IP or DNS name that is specific to the service. Otherwise, you receive a browser warning message indicating that the IP or DNS name on the URL does not match that in the certificate.

    If different services have different IP or DNS addresses, you need to create a server certificate for each service.

  2. Back up the keying material for this server certificate object and restore it by creating a Server Certificate object with the same key pair name as the one you created in Step 1 on all remaining servers in the cluster.

    See Backing Up a Server Certificate Object.

Validating a Server Certificate

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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ Certificate Access > Server Certificates.

  4. Select the Server Certificate object you want to validate.

  5. Click Validate.

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

Revoking a Trusted Root or Self Signed Certificate

You might find it necessary to revoke a certificate if the key or the CA becomes compromised, if the certificate has been superseded by another certificate, if the certificate is removed from the CRL, cessation of operation, etc.

  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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click Directory Administration > Modify Object.

  4. Browse to and click the Server Certificate object you want to modify.

  5. Click OK.

  6. Click the Certificates tab.

  7. Click Trusted Root Certificate or Self Signed Certificate.

  8. Select the certificate, then click Revoke.

    This starts the Revoke Certificate Wizard. Follow the prompts to revoke the certificate.

  9. Click Finish.

Moving a Server Certificate Object to a Different Server

You can move a Server Certificate object from one server to another by using the backup and restore procedures outlined in Backing Up a Server Certificate Object and Restoring a Server Certificate Object.

  1. Make sure the Server Certificate object is functional.

  2. Back up the Server Certificate object.

  3. Restore the Server Certificate object to the desired server.

IMPORTANT:Be sure to protect your backup media.

Replacing a Server Certificate Object's Keying Material

The private key and certificates in the server certificate object can be replaced. They should only be replaced using an internally generated PFX file created during a backup of a server certificate object. Externally generated PFX files can also be used if they contain the private key, the server certificate, and the entire certificate chain. The key and certificates in the file need not match the ones in the object; the data in the file overwrites the key and certificates in the object.

Replacing the private key and certificates in the server certificate object is a serious matter. If the key and certificates do not exactly match the ones in the object, it is the same as deleting the current server certificate object and creating a new one. See the section Backing Up a Server Certificate Object for more information on the consequences of deleting the object.

If the key and certificates do match the ones in the object, replacing the keying material has no effect except to regenerate a few attributes used by the Secure Authentication Services (SAS).

To replace the keying material on the Server Certificate object:

  1. As a precaution, back up the server certificate object with the private key. See Backing Up a Server Certificate Object.

  2. Launch iManager.

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

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

  4. On the Roles and Tasks menu, click Directory Administration > Modify Object.

  5. Browse to and select the Server Certificate object you want to modify.

  6. Click OK.

  7. Click the Certificates tab.

  8. Click Trusted Root Certificate or Self Signed Certificate.

    The operation can be started from either page. It replaces both certificates as well as the private key and any other certificates in the certificate chain.

  9. Select the certificate, then click Replace.

    This opens a wizard that helps you specify the PFX (backup) file.

  10. Browse for and select the backup file, enter the backup file password, then click OK.

The server’s private key and certificates have now been replaced and the server certificate is fully functional. The backup file should be stored again for future use if desired.

IMPORTANT:Be sure to protect your backup media.

25.4.3 User Certificate Tasks

Creating User Certificates

This task is described in Creating a User Certificate.

Creating User Certificates in Bulk

This feature allows you to create user certificates for multiple users at the same time, using one sequence of operations.

  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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ Certificate Server > Create User Certificate.

    This opens a wizard that helps you create the user certificate.

  4. Browse for and select all users you want to create a user certificate for.

  5. Follow the wizard prompts to create the certificate for each user. For specific information on the wizard pages, click Help.

Importing a Public Key Certificate into a User Object (with or without the Private Key)

You can import any public key certificate into a user object (for example, a certificate signed by a third-party certificate authority). This certificate can appear as one of two types of files:

  • DER: Contains a public key certificate only.

  • PFX or PKCS#12: Contains a public key certificate as well as a private key.

After it is imported, the certificate is stored in the User object and appears on the list of certificates available.

NOTE:When importing a PKCS#12 certificate, only the public key certificate and private key are stored on the User object. No other certificates are stored. Other certificates in the user’s certificate chain should probably be stored in the CN=Trusted Roots.CN=Security container (create a new Trusted Root object for each certificate in the chain).

To import a Public Key Certificate into a User 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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ Certificate Access > User Certificates.

  4. Browse for and select a User object to import the public key certificate into.

  5. Click New.

  6. Specify a nickname for the user certificate.

    The nickname should be unique and should help you identify the certificate. You can enter up to 64 characters in the Certificate Nickname field.

  7. Select the import creation method, then click Next.

  8. Browse for and select the certificate to import, then click OK.

  9. (Conditional) If you are importing a certificate with a private key, enter the password for the private key, then click Next.

  10. Click Finish.

    This stores the certificate in the User object, and the certificate appears on the list of certificates available to this user.

Viewing a User Certificate's Properties

In addition to the eDirectory rights and properties that are viewable with any eDirectory object, you can also view properties specific to the user certificate, including the issuer, the certificate status, the private key status, and the validation period.

  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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ Certificate Access > User Certificates.

  4. Browse for and select a User object whose certificate properties 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 the nickname of the certificate to view its details.

  7. Click Close when you are done viewing.

Exporting a User Certificate

In order to exchange secure e-mail with another person, you must first have the other person’s public key certificate. One way of obtaining that certificate is to export it using iManager. The other person’s certificate can also be obtained by using LDAP or e-mail.

To export your own or any other user’s 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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ Certificate Access > User Certificates.

  4. Browse for and select a User object whose certificate you want to export.

  5. Select the certificate, then click Export.

    This opens a wizard that helps you export the user certificate to a file. If you are logged in as the user that owns the certificate, select No when asked if you want to export the private key. See Exporting a User Certificate and Private Key.

  6. If you want to export the private key, select Export private key and provide a password to protect the private key.

  7. Select an export format if you are not exporting the private key, then click Next.

  8. Click Save the exported certificate to a file and save the file to a location of your choice.

  9. Click Close > Close.

Exporting a User Certificate and Private Key

In order to use a certificate for secure e-mail, authentication, or encryption, both the private key and the certificate must be available to the cryptography-enabled application. You must export the user certificate and private key and place it in a location that the application has access to in order for the application to use them.

The private keys in a user’s object belong to that user. Only someone logged in as that user can export the private key. No other user, not even the network administrator, has rights to export another user’s private key.

To export your own private key and certificate:

  1. Launch iManager.

  2. Log in to the eDirectory tree as the user who owns the certificate.

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

  3. On the Roles and Tasks menu, click NetIQ Certificate Access > User Certificates.

  4. Browse for and select a User object whose certificate you want to export.

  5. Select the certificate, then click Export.

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

  6. Select Export private key, provide a password to protect the private key, then click Next.

  7. (Optional) Click Export the Certificate into the Browser.

  8. Click Close > Close.

    The encrypted file is written to the location specified. It is now ready to be imported into a cryptography-enabled application.

IMPORTANT:The exported file can be kept to provide a backup. If so, it should be 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.

Validating a User Certificate

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 in these cases about 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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ Certificate Access > User Certificates.

  4. Browse for and select a User object whose certificate you want to validate.

  5. Select the user certificate you want to validate.

  6. Click Validate.

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

NOTE:If the user certificate was signed by a third-party CA, the certificate chain must be in the Trusted Roots container in the Security container (CN=Trusted Roots.CN=Security) for the validation to succeed. Typically, the certificate chain consists of a single, root-level CA or it consists of an Intermediate CA and a root-level CA. The name of the Trusted Roots container must be Trusted Roots and each certificate in the chain must be stored in its own Trusted Root object. For instructions on how to create a Trusted Roots container and Trusted Root objects, see Creating a Trusted Root Container and Creating a Trusted Root Object.

When validating user certificates or intermediate CA certificates signed by external CAs, the external CA’s certificate must be stored in a Trusted Root object in order for the certificate validation to be successful. The Trusted Root object must be in a Trusted Root Container named Trusted Roots and it must be located in the Security container.

Revoking a User Certificate

You might find it necessary to revoke a certificate if the key or the CA becomes compromised, if the certificate has been superseded by another certificate, if the certificate is removed from the CRL, cessation of operation, etc.

  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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ Certificate Access > User Certificates.

  4. Browse for and select a User object whose certificate you want to validate.

  5. Select the user certificate you want to revoke.

  6. Click Revoke.

    This starts the Revoke Certificate Wizard. Follow the prompts to revoke the certificate.

  7. Click Finish.

Deleting a User Certificate and Private Key

If a user certificate has become invalid or you suspect the private key has been compromised in some way, you might need to delete the user certificate and private key.

Before you delete a user certificate and private key, you should revoke the user certificate. See Revoking a User Certificate.

To delete a user certificate and private key:

  1. Launch iManager.

  2. Log in to the eDirectory tree as the user who owns the certificate or as an administrator with the appropriate rights.

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

  3. On the Roles and Tasks menu, click NetIQ Certificate Access > User Certificates.

  4. Browse for and select a User object whose certificate you want to delete.

  5. Select the user certificate you want to delete.

  6. Click Delete.

25.4.4 X.509 Certificate Self-Provisioning

This section describes the X.509 self-provisioning feature.

Overview

When you create an X.509 certificate, there are many important pieces of information that must be identified and substantiated before the certificate authority (CA) issues the certificate. Two of the most important tasks are:

  • Verifying the identity of the certificate's subject (verifying the identity of the person or object the certificate is for).

  • Verifying the appropriateness of the subject name in the certificate (verifying that the subject name correctly represents the identity of the person or object the certificate is for).

These two tasks can be very time-consuming and are often performed by a separate administrative person or group.

NetIQ Certificate Server has always leveraged the secure identity management capabilities of eDirectory to reduce the time and effort needed to perform these verifications. iManager allows an administrator to create user certificates in bulk; that is, to create a certificate for a large number of users at one time. The CA checks that the identity of the certificate is tied to the eDirectory account, which verifies the identity of the certificate's subject; however, the CA has not verified the appropriateness of the subject name in the certificate. Because of this, creating certificates with NetIQ Certificate Server has always required that the person or software have administrative rights to the Organizational CA.

Self-provisioning allows a user or server to generate certificates without having administrative rights to the Organizational CA and without intervention of a separate administrative person or group, and still maintain the security of the CA.

NetIQ Certificate Server verifies the identity of the certificate's subject by checking that the identity of the certificate is tied to the eDirectory account. The CA also verifies the appropriateness of the subject name in the certificate by checking against information in eDirectory. This allows the Organizational CA to leverage the security identity management capabilities of eDirectory to reduce administrative tasks while maintaining the security of the CA.

User Self-Provisioning

In the past, creating a user certificate required administrative rights to the CA as well as rights to attributes on the User object. With user self-provisioning, administrative rights to the CA are not necessary; however, Read (R) and Write (W) rights to the userCertificate, NDSPKI:UserCertificateInfo, and SAS:SecretStore attributes are still necessary.

If the person requesting the creation of the certificate has administrative rights to the CA, the certificate creation is not affected by whether or not user self-provisioning is enabled. If the person requesting the creation of the certificate does not have administrative rights to the CA, the subject name in the request is compared to the user's eDirectory DN and any values in the sasAllowableSubjectNames attribute.

If the subject name matches, the CA checks to ensure that any Subject Alternative Names are appropriate. The CA does this by checking that there is not more than one Subject Alternative Name. If the name exists, it must be of type email name and it must match a configured email name on the User object. If all these checks succeed, the CA does not require administrative rights to the CA in order to create the certificate.

To use user self-provisioning:

  1. Ensure that you have eDirectory 9.1 and the NetIQ Certificate Server 9.1.0 or later plug-in for iManager installed.

  2. Enable user self-provisioning

    1. Launch iManager.

    2. Log in to the eDirectory tree as an administrator with administrative rights to the Organizational CA.

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

    4. Select Enable user self-provisioning.

    5. Click OK.

  3. Set up inherited rights for users by enabling the iManager “[this]” object:

    1. Log in to iManager as an iManager administrator.

    2. Click the Configure icon.

    3. Click iManager Server > Configure iManager.

    4. Click the Misc tab.

    5. Select Enable “[this]”.

    6. Click Save.

      Next, you need to add inherited rights.

  4. Log in to iManager as a Certificate Authority administrator.

  5. On the Roles and Tasks menu, click Rights > Modify Trustees.

  6. Browse for and select the object you want the rights to be inherited from (for example, the root of the tree or a container), then click OK.

  7. Click Add Trustee, select the “[this]” object, then click OK.

  8. Click Assigned Rights.

  9. Click Add Property.

  10. Select Show all properties in schema.

  11. Select the userCertificate attribute, then click OK.

  12. Select Read and Write rights.

  13. Select Inherit.

  14. Repeat Step 6 through Step 10 for the other attributes (NDSPKI:UserCertificateInfo and SAS:SecretStore).

  15. Click Done > OK.

Server Self-Provisioning

In past, creating a server certificate required administrative rights to the CA as well as administrative rights to the context the server certificate was to be created in. With server self-provisioning, administrative rights to the CA are not necessary; however, administrative rights to the context the server certificate was created in are still necessary.

To create the server certificate, you must have the administrative rights to the CA. The certificate creation is not affected by whether or not server self-provisioning is enabled. In case you do not have the required administrative rights to the CA, enable the Require read rights to operate the CA option to operate the CA from the Configure Certificate Authority task in iManager. The administrative rights to the CA are not required if any one of the following are true:

  • The subject name in the request is compared to the server's eDirectory DN and any IP or DNS addresses as determined by a DNS or eDirectory SLP lookup. If the subject name matches either, the CA does not require administrative rights to the CA in order to create the certificate.

  • Non CN components of the subject name matches non CN components of CA certificate’s subject name.

  • Subject alternative name only has IP-address/DNS name that is verified again by CA through reverse DNS lookup.

The servers are not granted write rights to the CA’s NDSPKI:Private Key attribute by default. If Require write rights to operate the CA is enabled from the Configure Certificate Authority task in iManager, you should grant servers the write rights to the CA’s NDSPKI:Private Key attribute.

NOTE:Be aware that when PKI Health Check runs on a server with server self-provisioning enabled, your server’s server certificates might be automatically created (if none exist) or replaced (if they are expired). For more information, see PKI Health Check

To use server self-provisioning:

  1. Ensure you have eDirectory 9.0 and the NetIQ Certificate Server 3.2.2 or later plug-in for iManager installed.

    Both eDirectory 8.8 and the NetIQ Certificate Server 3.2.2 plug-in for iManager are included with OES 2 and are installed automatically when you select any of the eDirectory-required components during the OES 2 installation.

  2. Enable server self-provisioning:

    1. Launch iManager.

    2. Log in to the eDirectory tree as an administrator with administrative rights to the Organizational CA.

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

    4. Select Enable server self-provisioning.

    5. Click OK.

Certificate Self-Provisioning and the Issue Certificate Task

The Issue Certificate task allows the creation of a certificate by using a PKCS#10 certificate signing request (CSR). This task allows the user to create a certificate that is not tied to any eDirectory object. If the person requesting the creation of the certificate has administrative rights to the CA, the certificate creation is not affected. If the person requesting the creation of the certificate does not have administrative rights to the CA, the certificate request is treated as a user self-provisioning request, but the person does not need to have rights to the attributes userCertificate, NDSPKI:UserCertificateInfo, and SAS:SecretStore attributes on the object. This is because the certificate is not stored in eDirectory, so rights to the object are not needed.

User self-provisioning must be enabled for a user to issue certificates without having administrative rights to the CA. Complete Steps 1 through 3 of User Self-Provisioning.

For information on the Issue Certificate task, see Issuing a Public Key Certificate.

25.4.5 Using eDirectory Certificates with External Applications

Some customers use non-eDirectory applications that require X.509 certificates and keys (for example, Apache or OpenSSL). Most of these applications are configured out of the box with self-signed (no value) certificates, which are meant only to provide a temporary solution until the application can be configured with real X.509 certificates and keys.

Unfortunately, many administrators do not replace these self-signed certificates, often because it is too time-consuming or too difficult. In addition, X.509 certificates are designed to expire regularly, so replacing them on a regular basis is an ongoing administrative task.

The following sections describe the solution to this problem:

PKI Health Check Functionality

In response to customer requests to provide non-eDirectory applications with X.509 certificates, the PKI Health Check code within NetIQ Certificate Server now provides the capability to automatically export X.509 certificates and keys to the file system, enabling non-eDirectory applications to take advantage of eDirectory-minted certificates and eDirectory-managed certificates.

When the PKI Health Check runs, it automatically overwrites any existing certificates, including the certificates’ private keys. However, to ensure that no valid certificates and private keys are deleted, the PKI Health Check determines whether the existing certificates and keys are the same as those configured in eDirectory. If they are different than those configured in eDirectory, the PKI Health Check creates a backup of these files before overwriting them. This ensures that certificates that have been acquired from an external source (for example, VeriSign*) are not deleted.

After a configuration has been created for the server on the SAS:Service Object, keys and certificates associated with the specified server are automatically exported to the file system. If the keys and certificates are replaced or updated in eDirectory (for example, if the Server Certificate object is deleted and a new one is created with the same name), the new keys and certificates are automatically exported to the file system the next time PKI Health Check runs.

NOTE:The PKI Health code within NetIQ Certificate Server runs once every time NetIQ Certificate Server loads/reloads. You can use any of the following methods to reload the NetIQ Certificate Server:

  • Restart the server

  • Restart eDirectory

  • Unload and load PKI Server manually

  • Run an eDirectory repair (NDSRepair)

    NetIQ Certificate Server shuts down during the repair and reloads after the eDirectory repair is finished.

For more information on the PKI Health Check, see PKI Health Check.

Before the PKI Health Check can automatically export X.509 certificates and keys to the file system, the SAS:Service Object must be configured. This is because the PKI Health Check reads the configuration on the SAS:Service Object. For information on how to configure the SAS:Service Object, see Configuring the SAS:Service Object to Export eDirectory Certificates.

Configuring the SAS:Service Object to Export eDirectory Certificates

Before an eDirectory Server Certificate can be exported to the file system, a configuration must first be created for the server on the SAS:Service Object. This can be done either automatically or manually, depending on what eDirectory server you are using. The following sections further explain these options:

Manually Configuring the SAS:Service Object to Enable Use of eDirectory Certificates

If you are not using OES 2 as your eDirectory server, you must manually configure the SAS:Service Object in order to export eDirectory certificates. This configuration must specify the Server Certificate name. If multiple server certificates need to be exported, you can simply create multiple configurations. You can export the same certificate to a different file path, or you can export a different certificate to a different file path.

NOTE:Each configuration must use unique file paths in order to avoid file collisions. The Public key path and the Private key path must be unique and different from each other and from any other configuration.

To create a configuration on the SAS:Service object:

  1. In iManager, in the Roles and Tasks view, click NetIQ Certificate Access.

  2. Click SAS Service Object.

  3. On the SAS Service Object page, click the Browse Roles and Tasks button icon.

  4. Browse to and select the SAS:Service object where you want to create the configuration.

  5. Click the SAS:Service object.

  6. Click New.

    The Server Certificate Synchronization window is displayed.

  7. In the Certificate field, browse for and select the certificate you want to export.

  8. In the Public key path field, specify the path where the application will find and use the certificate. For example: C:/novell/nds/servercert.pem.

  9. In the Private key path field, specify the path where the application will find and use the certificate’s private key. For example: C:/novell/nds/serverkey.pem.

  10. Select the key type that you are going to use. If you are running OpenSSL, select PKCS#8. If you are running Apache, select PKCS#1.

  11. Click OK.

    The configuration is created. The name, path, key path and key type are displayed.

To create another configuration, repeat Step 6 through Step 11.

If you are using a OES server as your eDirectory server, then you can automatically configure the server to create a configuration on the SAS:Service Object.

NOTE:If use of eDirectory certificates is enabled while installing OES 2 (default), the install code creates a configuration for the SSL CertificateDNS object, and the certificates and keys are exported to the following files:

key file - /etc/ssl/servercerts/serverkey.pem

certificate file - /etc/ssl/servercerts/servercert.pem

25.4.6 Trusted Root Object Tasks

Creating a Trusted Root Container

This task is described in Creating a Trusted Root Container.

Creating a Trusted Root Object

This task is described in Creating a Trusted Root Object.

Viewing a Trusted Root Object's Properties

In addition to the eDirectory rights and properties that are viewable with any eDirectory object, you can also view properties specific to the Trusted Root object, including the issuer, the certificate status, and the validation period.

  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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click Directory Administration > Modify Object.

  4. Browse to and click the Trusted Root object you want to view.

  5. Click OK.

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

  7. Click the nickname of the certificate to view its details.

  8. Click Cancel.

Replacing a Trusted Root Certificate

This task allows you to replace a Trusted Root Certificate that is stored in the Trusted Root object. This task should be performed if the Trusted Root Certificate has expired.

You can replace a Trusted Root Certificate from the Trusted Root object's property page.

  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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click Directory Administration > Modify Object.

  4. Browse to and click the Trusted Root object you want to replace.

  5. Click OK.

  6. Select the certificate, then click Replace.

  7. Browse for and select the new Trusted Root certificate.

  8. Click OK.

Validating a Trusted Root Object

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 in these cases about which certificate is considered invalid and why. Click Help for more information about the reason.

To validate a Trusted Root 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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click Directory Administration > Modify Object.

  4. Browse to and click the Trusted Root object you want to validate.

  5. Click OK.

  6. Select the certificate, then click Validate.

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

NOTE:If the certificate in the object is not self-signed, its certificate chain must be in the Trusted Roots container in the Security container (CN=Trusted Roots.CN=Security) for the validation to succeed. Typically, the certificate chain consists of a single, root-level CA or it consists of an Intermediate CA and a root-level CA. The name of the Trusted Roots container must be Trusted Roots and each certificate in the chain must be stored in its own Trusted Root object. For instructions on how to create a Trusted Roots container and Trusted Root objects, see Creating a Trusted Root Container and Creating a Trusted Root Object.

Revoking a Trusted Root Certificate

You might find it necessary to revoke a certificate if the key or the CA becomes compromised, if the certificate has been superseded by another certificate, if the certificate is removed from the CRL, cessation of operation, etc.

  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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click Directory Administration > Modify Object.

  4. Browse to and click the Trusted Root object you want to modify.

  5. Click OK.

  6. Select the certificate, then click Revoke.

    This starts the Revoke Certificate Wizard. Follow the prompts to revoke the certificate.

  7. Click Finish.

25.4.7 Certificate Revocation List (CRL) Tasks

NetIQ Certificate Server provides a system for managing Certificate Revocation Lists (CRLs). This is an optional system, but it must be implemented if you want to be able to revoke certificates created by the Organizational CA.

A CRL is a published list of revoked certificates and the reason the certificates were revoked.

Creating a CRL Container Manually

During the Certificate Server installation, a CRL container is created if the user has the appropriate rights to create it. If not, the CRL container can be created manually by someone with the appropriate rights after the installation is completed.

  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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, select NetIQ Certificate Server > Configure Certificate Authority.

    If a CRL container already exists, you are brought to the Organizational CA's property page.

    If no CRL container exists, this launches a wizard that creates a CRL container and a CRL Configuration object to go in the container.

  4. Follow the wizard to completion.

NOTE:If the CRL container is created in a different container other than the Security container, the ndspkiCRLContainerDN attribute has to be populated manually on the tree CA object for the CRL tab to list the CRLs.

Deleting a CRL Container

Deleting a CRL container is possible, but it is not recommended.

The general rule is to not delete a CRL container, CRL configuration object, CRL object, or CRL file until one issue date after the last certificate that contains a related distribution point has expired.

  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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, select Directory Administration > Delete Object.

  4. Browse for and select the CRL container you want to delete.

  5. Click OK > OK.

Creating a CRL Configuration Object

A CRL Configuration object can be created in the CRL container. This is an object that contains the configuration information for the CRL objects that are available in the eDirectory tree. Normally, you have only one CRL Configuration object in your tree. You might need multiple CRL Configuration objects if you are creating or rolling over a new Organizational CA, but only one CRL Configuration object can be used to create new certificates.

The CRL Configuration object resides in the CRL container.

  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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, select NetIQ Certificate Server > Configure Certificate Authority and then do one of the following:

    • If no CRL container exists, this launches a wizard that creates a CRL container and a CRL Configuration object to go in the container. Follow the wizard to completion.

    • If a CRL container exists, but no CRL Configuration object exists, this launches a wizard that creates a CRL Configuration object to go in the container. Follow the wizard to completion.

    • If a CRL container exists and a CRL Configuration object exists, you are brought to the Organizational CA's property page. Continue with Step 4.

  4. Click the CRL tab.

  5. Click New.

  6. Type the name of the new CRL configuration object, then click OK.

    NOTE:Ensure that the CRL file path which is specified here, is in respect with the eDirectory installation path.

  7. Follow the wizard to completion.

Activating a CRL Configuration Object

Only one CRL Configuration object can be active in an eDirectory tree at one time. If you have more than one CRL Configuration object, you must choose which one to activate. By default, the first CRL Configuration object created is active.

  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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, select NetIQ Certificate Server > Configure Certificate Authority.

  4. Click the CRL tab.

  5. Select a CRL Configuration object, then click Make Active.

  6. Click OK or Apply.

Viewing and Modifying a CRL Configuration Object's 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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, select NetIQ Certificate Server > Configure Certificate Authority.

  4. Click the CRL tab.

  5. Click on the name of the CRL Configuration object you want to view or modify.

  6. Click OK or Apply.

    NOTE:The CRL configuration can be disabled while validating the certificates. To disable the CRL configuration, you must set the environment variable NDSD_DISABLE_CRL_CONFIG to any value. If your eDirectory tree is already configured with CRL, ensure to remove the CRL configuration objects (objectclass: ndspkiCRLConfiguration) and CRL Distribution point objects (objectclass: cRLDistributionPoint) manually before upgrading eDirectory.

LDAP Mapping

The standard LDAP type for Certificate Revocation Lists limits the size of the CRL to 64 KB. To change this limitation, you must create the CRL directory entries with NetIQ-defined types. In order for the LDAP distribution points to be found, you must map the standard LDAP types to the NetIQ LDAP types by doing the following:

  1. Launch iManager.

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

  3. On the Roles and Tasks menu, select LDAP > LDAP Options.

  4. Click the View LDAP Groups tab, then select the LDAP group that needs to be mapped.

  5. Click the General tab, select the Attribute Map page, and make the following changes:

    1. The default mapping from Primary LDAP Attribute certificateRevocationList; binary (and secondary attribute certificateRevocationList) to the eDirectory attribute certificateAuthorityList should be changed to the eDirectory attribute ndspkiCertificateRevocationList (that is, change the eDirectory attribute from certificateAuthorityList to ndspkiCertificateRevocationList).

    2. The default mapping from Primary LDAP Attribute authorityRevocationList;binary (secondary attribute authorityRevocationList) to the eDirectory attribute authorityRevocationList should be changed to the eDirectory attribute ndspkiAuthorityRevocationList (that is, change the eDirectory attribute from authorityRevocationList to ndspkiAuthorityRevocationList).

    3. The default mapping from Primary LDAP Attribute deltaRevocationList;binary (secondary attribute deltaRevocationList) to the eDirectory attribute deltaRevocationList should be changed to the eDirectory attribute ndspkiDeltaRevocationList (i.e. change the eDirectory attribute from deltaRevocationList to ndspkiDeltaRevocationList).

  6. Click OK.

  7. On the Roles and Tasks menu, select LDAP > LDAP Options.

  8. Click the View LDAP Servers tab, then select the server that hosts the LDAP distribution point.

  9. Click the General tab, then select the Information page.

  10. Click the refresh button.

    This restarts the LDAP service, and it begins using the correct mapping for the CRL attributes.

For more information on LDAP management, see Section 14.0, Configuring LDAP Services for NetIQ eDirectory.

HTTP Distribution Point Location

When configuring Certificate Server to use an HTTP distribution point, it is important that you specify a location that is accessible to users wanting to validate certificates. If a user cannot locate a CRL for a certificate containing a distribution point, the certificate is considered invalid. The distribution point must be located in a directory that is available to the Web server specified by the HTTP address in the distribution point. If that directory is not on the same server that is hosting the Certificate Authority, the CRL must be moved manually, with a script, or created on a mounted directory.

Deleting a CRL Configuration Object

Deleting a CRL Configuration object is possible, but it is not recommended. When a CRL Configuration object is deleted, the server quits creating the CRL files. If a CRL file already exists in the location specified in the CRL object, certificate validation continues to use it until it expires. After it expires, all certificates that have a CRL distribution point that references that CRL file fail validation.

The general rule is to not delete a CRL container, CRL configuration object, CRL object, or CRL file until one issue date after the last certificate that contains a related distribution point has expired.

  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 Entry Rights Needed to Perform Tasks

  3. On the Roles and Tasks menu, select Directory Administration > Delete Object.

  4. Browse for and select the CRL Configuration object you want to delete.

  5. Click OK > OK.

Creating a CRL Object

This task allows you to create a CRL object (cRLDistributionPoint) to store third-party CRLs in eDirectory. This object can be created in any container in the eDirectory tree. But as a general rule, NetIQ CRL objects reside in a CRL Configuration object and do not need to be created manually. A CRL object is automatically created for you when you create a CRL Configuration object.

The CRL object contains a CRL file, which contains the detailed CRL information. For a NetIQ CRL object, the CRL file is automatically created and updated whenever the server issues a new one. For other CRL objects, you must import a CRL file from a third-party CA.

NOTE:The term CRL Distribution Point is used in different ways. It is the eDirectory schema object name for the CRL object and it can be used in general terms as the point where the CRL information is published.

To create a CRL 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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, select NetIQ Certificate Server > Create CRL Object.

  4. Type a name for the object and provide the context where you want the object to reside.

  5. Paste a copy of the CRL into the field or read it from a CRL file.

  6. Click Finish to create the object.

Exporting a CRL File

You can export the CRL that is contained in the CRL Distribution Point object to a file.

To export a NetIQ CRL file:

  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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, select NetIQ Certificate Server > Configure Certificate Authority.

  4. Click the CRL tab.

  5. Click the name of the CRL Configuration object, then click Details.

  6. Click Export.

  7. Select an output format, then click Next.

  8. To save the exported CRL to a file, click Save, then specify a location for the file.

  9. Click OK > OK.

To export a third-party CRL file:

  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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, select Directory Administration > Modify Object.

  4. Browse for and select the CRL Configuration object, then click OK.

  5. Click Export.

  6. Select an output format, then click Next.

  7. To save the exported CRL to a file, click Save, then specify a location for the file.

  8. Click OK > OK.

Replacing a CRL File

You can replace a CRL file, but it is not recommended.

  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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, select NetIQ Certificate Server > Configure Certificate Authority.

  4. Click the CRL tab.

  5. Click the name of the CRL Configuration object, then click Details.

  6. Click Replace.

  7. Click OK to continue.

  8. Browse for and select the new CRL file.

  9. Click OK.

If a CRL file does not exist on the CRL Configuration object, the Import button is displayed.

Extending Validity of CRL File

The administrator can extend the validity of the CRL file using iManager. To extend the validity, perform the following steps:

  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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, select NetIQ Certificate Server > Configure Certificate Authority.

  4. Click the CRL tab.

  5. Click the name of the CRL file.

  6. Select Extend validity by following hours under Next CRL Issuance and mention the number of hours in the next box. You can enter any value ranging from 1 to 12 hours in this field.

  7. Click Issue Now.

Viewing a CRL Object's Properties

To view a NetIQ CRL object's 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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, select NetIQ Certificate Server > Configure Certificate Authority.

  4. Click the CRL tab.

  5. Click the name of the CRL Configuration object, then click Details.

    You can now view the CRL object's properties.

  6. When you are finished viewing properties, click OK or Apply.

To view a third-party CRL object's 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 Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, select Directory Administration > Modify Object.

  4. Browse to and click the CRL object you want to view, then click OK.

  5. Click Edit.

    You can now view the CRL object's properties.

  6. When you are finished viewing properties, click OK or Apply.

Deleting a CRL Object

If you delete a CRL object, it is re-created the next time the server generates the CRL file. If you delete a CRL object that you created using iManager and import it, then it is gone permanently and any certificates that reference it are considered invalid.

The general rule is to not delete a CRL container, CRL configuration object, CRL object, or CRL file until one issue date after the last certificate that contains a related distribution point has expired.

  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 Entry Rights Needed to Perform Tasks.

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

  4. Browse to and click the CRL object you want to delete.

  5. Click OK > OK.

25.4.8 eDirectory Tasks

Resolving Multiple Security Containers, Organizational CAs, KAP Containers, and W0 Objects

NetIQ Certificate Server can be installed on multiple servers in an eDirectory tree. However, for NetIQ Certificate Server to function properly, only one Security container, Organizational CA, KAP container, and W0 object should exist in the tree.

If you are installing NetIQ Certificate Server on multiple servers in an eDirectory tree, you must allow eDirectory to replicate between each installation of NetIQ Certificate Server. If you do not allow eDirectory to replicate, your installation to another server might not recognize that the tree already has a Security container, an Organizational CA, a KAP container, and W0 object and might re‑create these objects on another server in the same eDirectory tree.

The items below describe possible scenarios and how to resolve them.

  • If you have two or more Security containers in the same eDirectory tree and each contains an Organizational CA, and a KAP container with a W0 object, do not issue any certificates. Contact Technical Support for help in resolving this.

  • If you have one Security container that contains two KAP containers in the same eDirectory tree, do not issue any certificates. Contact Technical Support for help in resolving this.

  • If you have one Security container that contains two Organizational CAs and one KAP container with a W0 object in the same eDirectory tree, delete every server and user certificate issued by both Organizational CAs. Then, delete both CAs and create a new Organizational CA. Issue new server and user certificates as needed.

  • If you have two or more Security containers in the same eDirectory tree and each contains an Organizational CA, but only one contains a KAP container with a W0 object, delete every server and user certificate issued by all Organizational CAs. Delete all the Security containers without the KAP container and W0 object. If the remaining Security container is not named Security, rename it to Security. Issue new server and user certificates as needed.

  • If you have two or more Security containers in the same eDirectory tree and only one contains an Organizational CA and a KAP container with a W0 object, delete all the Security containers without the KAP container and W0 object. If the remaining Security container is not named Security, rename it to Security.

Restoring or Re‑creating a Security Container

If you delete the Security container, you cannot create an Organizational Certificate Authority until you have restored or re‑created the security container.

To restore the security container, you must restore the eDirectory partition containing the Security container.

To re‑create the Security container, use one of two methods:

  • Using iManager, click Directory Administration > Create Object. Click Tree's Security Container, then click OK. The container name must be Security.

  • Reinstall NetIQ Certificate Server on any server in the eDirectory tree.

Restoring or Re‑creating KAP and W0

Do not delete the KAP or W0 objects. Doing so invalidates all previously created User certificates. If you delete one of these objects, refer to the TID #3032354, “How to Restore or Recreate KAP and W0 Objects,” for information on how to resolve this problem. You should not attempt further installations of NetIQ Certificate Server, Single Sign-on, NMAS, or eDirectory until the problems have been corrected.

25.4.9 Application Tasks

This section describes how to configure cryptography-enabled applications to use NetIQ certificates.

Some of the information in this section is dated but useful. For the latest information on using certificates with your cryptography-enabled applications, refer to the application's documentation.

The general process for enabling applications for secure e-mail is:

  1. Export your Organizational CA's self-signed certificate (see Exporting the Organizational CA's Self-Signed Certificate), your user certificate, and the matching private key to a .pfx file (see Exporting a User Certificate and Private Key).

  2. Import the .pfx file into your e-mail client.

  3. Configure your e-mail client to secure your e-mail.

In order to create an SSL connection to a server on the Internet with your browser, you must trust the CA that signed the user or server's certificates. If you do not, your application might present you with an error. Some applications provide a warning with the ability to accept or reject the user or server certificate whose CA isn't yet known to the application.Server and user certificates signed by a company's Organizational CA always generate such warnings and errors. This is because the Organizational CA is not listed as a trusted CA in your application. The warnings and errors can be prevented by installing the self-signed certificate of the Organizational CA into your application.Installing the Organizational CA into your browser automatically adds it as a trusted CA.

To accept the Organizational CA as a trusted CA in your application:

  1. Export your Organizational CA's self-signed certificate (see Exporting the Organizational CA's Self-Signed Certificate).

    NOTE:The Internet browsers recognize certificates in .der or a .crt format.

  2. Import the certificate into your browser according to the directions provided by the browser documentation.

25.4.10 PKI Health Check

NetIQ Certificate Server incorporates a process that maintains the health and integrity of the Certificate Server components. This process is called the PKI Health Check and it runs when:

  • The server reboots.

  • eDirectory comes up.

  • DSRepair finishes running.

When PKI Health Check runs, it performs the following tasks:

Table 25-1 PKI Health Check Tasks

Task

Function

Verifies the server’s link to the SAS Service object

This task checks to see if there is a link from the server object to a SAS:Service object. If the link exists, the task makes sure that the object is named correctly and is in the same context as the server. If the link does not exist, the task checks to see if a correctly named object exists in the same context as the server. If such an object exists, the task creates a link from the server to the object.

Verifies the SAS Service object

This task checks to see if a SAS:Service object exists. If it does not exist, the task creates one and creates a link from the server object to the new object. Then, the task checks to see if the SAS:Service object has the necessary eDirectory rights. If it does not, the task attempts to give the SAS:Service object the rights it needs.

Verifies the links to the KMOs

This task reads the list of Server Certificate objects (or KMOs) that are linked to the SAS:Service object. It checks whether the KMOs are all named correctly and attempts to fix their names if they are not. The task also checks whether the KMOs are all in the same context as the server object and attempts to move them to the correct context if they are not.

Checks the Server Certificates (KMOs)

This task reads all the names of KMOs that are in the same container as the server object and puts them in a list. The task then performs the following for each KMO in the list:

  • Attempts to populate the NDSPKI:Not Before and NDSPKI:Not After attributes with the validity dates of the certificate.

  • Checks whether Public has the Read right to the Host Server attribute.

  • Checks the link from the KMO to a server that is a back link. If the back link is for a different server, it ignores the KMO and removes it from its list.

  • Reads the private key and attempts to unwrap it.

Reverifies the links to the KMOs

This task reads the list of Server Certificate objects (or KMOs) that are linked to the SAS:Service object. It compares each KMO in this list to the list created in Checks the Server Certificates (KMOs). Using the checks from Checks the Server Certificates (KMOs), the task determines if there are any problems with the linked certificates and it unlinks them if the KMO is unusable. The task also determines if there are any unlinked KMOs that are usable by this server and it links them, if they exist.

Creates default certificates

This task determines if Server Self-Provisioning is enabled at the Organizational CA object. If Server Self-Provisioning is not enabled, this step is skipped. If Server Self-Provisioning is enabled, then the task calls the NPKICreateDefaultCertificates() API. This API creates or replaces the SSL CertificateDNS certificate if:

  • The certificate does not exist.

  • The certificate is not expired or about to expire.

  • The certificate’s subject name does not match the default IP and DNS address configured for the server.

NOTE:eDirectory does not automatically create SSL CertificateIP. SSL Certificate DNS contains all the IPs listed in the Subject Alternative Name.

In addition, this API acquires all of the IP and DNS addresses configured for the server and it creates and/or replaces a certificate for each one, such as IP AG ip address or IP DNS dns name if:

  • The certificates do not exist.

  • The certificates are expired or about to expire.

Synchronizes certificates for external services

This task reads the configuration from the SAS:Service object. For each configured entry, the task acquires the certificates and private key from the specified KMO object. If the specified directory does not exist, the task attempts to create it. The task then unwraps the private key and converts it to the specified raw-key format. The task compares any existing private key and certificate files to the ones from the specified KMO. If the keys and certificates are not the same, the task makes a backup of the existing private key and certificate files and then it overwrites them with the private key and certificates. The keys are written out in a PEM format.

Exports the eDirectory CA certificate to the file system

The way in which this task is accomplished depends on the operating system you are running.

The SSCert.der and SSCert.pem files contain the RSA certificate of the Organization CA. If the Organization CA has ECDSA certificate, eDirectory exports the ECDSA certificate to the SSECCert.der and SSECCert.pem files and staores them in the same directory as the SSCert.der and SSCert.pem files.

  • Windows: Checks if the SSCert.der and SSCert.pem files in the PKI working directory contain the same certificate as the Organization CA certificate in eDirectory. It attempts to replace the files if they are not the same.

    The default PKI working directory is c:\Novell\NDS\DIBFiles\CertServ\

  • Linux (Not OES Linux): Checks if the SSCert.der and SSCert.pem files in the eDirectory data directory contain the same certificate as the Organizational CA certificate in eDirectory. It attempts to replace the files if they are not the same.

    The default eDirectory data directory is /var/opt/novell/eDirectory/data

  • OES Linux: Checks if the /etc/opt/novell/certs/SSCert.der and /etc/opt/novell/certs/SSCert.pem files contain the same certificate as the Organizational CA certificate in eDirectory. If the certificates are not the same, the task attempts to replace the files by adding the Organizational CA certificate to the /etc/ssl/certs directory and then running the c_rehash program. Before replacing the files, however, the task creates backups of any existing certificates.