If PKI operations in iManager are not working, it could be because NetIQ PKI Services are not running on the Linux. Start the PKI Services by entering npki -1.
If you cannot create certificates, you need to ensure that the NICI module has been properly installed. See Initializing the NICI Module on the Server
in the NetIQ eDirectory Administration Guide. To verify if NICI is initialized, see Verifying Whether NICI Is Installed and Initialized on the Server
in the NetIQ eDirectory Administration Guide.
To complete the operation, change the Key Server DN attribute in the W0 object under Security Container > KAP to another server in the tree that has downloaded the treekey from this server.
In NetIQ iManager, click the Roles and Tasks button .
Click eDirectory Administration > Modify Object.
Specify the name and context of the W0 object (usually W0.KAP.Security), then click OK.
In the Valued Attributes column, select NDSPKI:SD Key Server DN, then click Edit.
Specify the name and context of a different server in the Security Domain Key Server's DN field, then click OK.
Click Apply, then click OK.
You should re-create the CA and KMOs for the tree. See Creating an Organizational Certificate Authority Object
and Creating a Server Certificate Object
in the NetIQ eDirectory Administration Guide for more information.
We recommend that you do not uninstall the eDirectory server where the CA for the tree has been created.
PKIDiag is a utility designed to diagnose and fix Certificate Server objects. PKIDiag can be used to do the following:
Rename or move server-related objects so that they conform to the correct naming and containment scheme if a server has been moved.
Create required objects if they do not exist.
Grant the necessary rights between objects.
Link objects if they are not linked.
Create the SSL CertificateIP and the SSL CertificateDNS certificates if they do not exist.
Fix the SSL CertificateIP and the SSL CertificateDNS certificates if either has an incorrect name, is out of date, or is close to expiring.
The PKIDiag functionality is used by two other processes, the server auto health check and the Create Default Certificate task in iManager.
The server auto health check is run whenever a server is restarted or whenever DSREPAIR is run. Create Default Certificate is a process you use to replace the default certificates created when you install Certificate Server. See Creating Default Server Certificate Objects for more information.
See TID #3640106 for more information about PKIDiag and how it can be used.
Occasionally, after the user certificate has been created, the client is unable to refresh the view to include the new certificate. A dialog box is shown with the message “Waiting for servers to synchronize.” At this point, the user certificate has been created but the servers involved in the creation have not yet synchronized. You can close the dialog box without impacting the creation of the user's certificate.
If an error occurs during user certificate creation, try using a different nickname for the certificate. The nickname that was specified might not be available for reuse.
All servers with replicas of the partition in which the User object resides should have the same level of cryptography (U.S./Worldwide NICI or Import Restricted NICI). If they do not, an error of -1426 might appear when exporting the user's private key if the key size is too large.
To export the user's private key after a -1426 error has occurred, you must either upgrade the cryptography on the servers with replicas of the partition or remove the replica from those servers that have exportable cryptography.
eDirectory 9.0 does not support the SSL CertificateIP certificate. If you upgrade to eDirectory 9.0 from a previous version, the SSL CertificateIP certificate remains associated with the server. When the certificates in your environment expire, the SSL CertificateIP certificate does not renew automatically.
Any time after you upgrade to eDirectory 9.0, you can start using the SSL CertificateDNS certificate instead of the SSL CertificateIP certificate.
Some third-party CAs such as VeriSign use an intermediate CA to sign server certificates. In order to import these certificates into a Server Certificate object, the server certificate as well as the Intermediate CA and the trusted root certificate must be in a single PKCS #7 formatted file (.P7B). If your CA cannot provide you with such a file, you can create one yourself by following these steps on a client machine with Internet Explorer 5.5 or later installed.
Import the server certificate into Internet Explorer. You can do this by double-clicking on the file or by selecting File > Open and selecting the filename.
If the external CA's certificate is not already listed as a trusted CA in Internet Explorer, import the Intermediate CAs as well as the root level CA in the same manner.
In Internet Explorer, select Tools > Internet Options. Select the Content tab, then select the Certificates button.
On the Personal tab, find the server certificate. Select it and click Export.
Accept the defaults in the wizard until you get to the Export File Format page, then select the Cryptographic Message Syntax Standard - PKCS #7 Certificates (.p7b) format.
Continue with the wizard.
The PKCS #7 file can now be imported into the Server Certificate object.
If a Server object is moved, the LDAP objects, SAS service object, and Server Certificate objects (Key Material Objects) for that server should also be moved. But the server auto health check will move the objects for you the next time you restart the server.
If DNS is configured for the server, the default subject name for a server certificate will be:
.CN=<Server's DNS Name>.O=<Tree Name>
Otherwise, the default subject name is the fully distinguished name of the server. You can modify the default subject name by selecting Custom during the certificate creation process.
When removing a server from eDirectory™ and then reinstalling it into the same context with the same name, a successful reinstallation occurs only if the SAS Service object representing the removed server is also deleted, if it existed.
The process should go like this:
Determine if the default certificates need to be backed up. If so, back them up.
Delete the default certificates.
Delete the SAS object.
For example, for a server named MYSERVER, a SAS object named SAS Service - MYSERVER could exist in the same container as the server. This SAS object must be manually deleted (using iManager) after the server is removed from the tree, but before the server is reinstalled into the tree.
If the server is the Organizational CA or the SD Key server, you must complete some additional steps. These steps are documented in TID #3623407.
The default server certificates created for the server should also be removed so that they are re-created when the server is reinserted.
These certificates are SSL Certificate IP - MYSERVER and SSL Certificate DNS - MYSERVER. You should be careful when deleting these certificates. If data has been encrypted by using either of these certificates, the data must be retrieved before the certificates are deleted.
Server certificates with an @ character in their subject names might cause SSL connections to fail. Contact Technical Support for a resolution of the problem.
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.
Validating the information in a certificate and its associated certificate chain is not a time-intensive process. However, there are occasions where the validation might take longer:
If the certificate was signed by an external CA and one or more of the certificates has a CRL distribution point extension.
In order to validate the certificate, the CRL for each applicable certificate in the chain must be retrieved. The CRL must then be examined to determine whether or not the certificate has been revoked.
If the CRLs are large or if the server operating the CRL distribution point is busy, it might take some time to validate a certificate. The time required can be decreased by doing one or more of the following:
Upgrade the speed of the connection being used to check the revocation status of the certificate.
Contact your CA provider.
If one or more of the certificates has an OCSP AIA extension. If the OCSP responder is busy, it might take a significant amount of time to validate.
If you are validating a user certificate.
For server certificates, the entire certificate chain is stored along with the server certificate in the Key Material object. Therefore, when a server certificate is validated, the client can get all of the certificates necessary by simply reading one object. User certificates, however, are stored differently. Only the user certificate itself is stored in the User object. Thus, the client must retrieve the certificate chain from other objects stored in the Security container in order to validate the user certificate.
In order to validate a user certificate signed by the Organizational CA, the client must read the Organizational CA’s object in order to retrieve the CA’s certificate. In order to validate a user certificate signed by an external CA, the client must read the Trusted Roots container in the Security container in order to compose a certificate chain that matches the user certificate. In the latter case, an Administrator must have already imported the certificates of the external CAs into the Trusted Roots container in order for the validation of the User certificate to succeed.
The time required to validate a user certificate can be decreased by removing expired certificates that are no longer trusted from the Trusted Roots container.
If you delete the Organizational CA (other than during a backup and restore procedure), you should export the self-signed certificate and create a new trusted root in the trusted roots container. If you don't, you will experience the following behavior when validating these certificates:
User certificates signed by the deleted CA are invalid. This is because the certificate of the CA that signed the user certificate could not be found in the Organizational CA object or in the Trusted Roots container. If you want those user certificates to remain valid, you must add the previous CA’s self-signed certificate to the Trusted Roots container.
Server certificates signed by the deleted CA continue to be valid. This is because the CA’s certificate is stored in the Key Material object along with the server certificate.
If you deleted the Organizational CA because the key had been compromised or because of some security breach, you should immediately revoke all user and server certificates that were signed by the CA. If you cannot revoke them, you should delete them and create new certificates to take their place. You should also tell all users who might have imported your Organizational CA’s certificate into their browsers to delete the certificate.
You cannot rename the security container.