If you receive a message indicating that a newer file exists from the previous installation, you should select to always overwrite the newer file.
The list of servers shown during the installation might not list servers that are configured to use only IP. You can install NetIQ Certificate Server on a server whose name is not listed by typing the name of the server in the text box.
When installing NetIQ Certificate Server, you might encounter an error stating that the Security Domain key server could not be contacted. The first server in your network that you install NetIQ Single Sign-on, NMAS, or NetIQ Certificate Server on is set up to be the Security Domain key server.
All subsequent servers that are installed with any of these products contact the Security Domain key server during their installation process. If the Security Domain key server cannot be contacted, the installation fails and a message is displayed indicating that the SAS service object could not be created.
To avoid the SAS service creation error message:
Make sure the Security Domain key server machine is up and running nicisdi.nlm.
Use a common protocol (IP and/or IPX™) between the Security Domain key server and all other servers that are installed with NetIQ Single Sign-on, NMAS, and NetIQ Certificate Server.
Make sure the network connection between the Security Domain key server and the server being installed is active.
You can determine which server is the Security Domain key server by running iManager. Open the properties page for the W0 object. This object is located in the KAP container, which is inside the Security Container. Click the Other tab. Click NDSPKI:SD Key Server DN. The value displayed is the distinguished name of the Security Domain key server.
If you receive this error one or more times during the installation, ignore it and continue with the installation.
If the installation fails during the creation of the Organizational CA or the server certificate, or during the exportation of the trusted root certificate, the installation doesn't need to be repeated. The software has been successfully installed at this point. You can use iManager to create an Organizational CA and server certificates and export the trusted root.
If a NetIQ Certificate Server installation fails during installation and you receive a -1443 error message, this means that the Security Domain key server and the server that you are installing Certificate Server on are not communicating properly. If the server cannot get a copy of the Security Domain key, the installation fails.
A likely reason is that the server that Certificate Server is being installed to fragments of the (NetWare Core Protocol) NCP™ extensions, and the fragments are not being reassembled correctly by the Security Domain key server.
One solution to this problem is to increase the MTU of both servers to greater than 576 (the default minimum size).
To increase the MTU on a server:
Enter LOAD MONITOR !h from the command line of the server.
Select Server Parameters > click Communications.
Select Maximum Interface MTU, then set this value to something higher than 576.
To work around this issue, create a libntls.so.8 symbolic link pointing to libntls.so as follows:
ln -sf /var/opt/novell/iManager/nps/WEB-INF/bin/linux/libntls.so
/var/opt/novell/iManager/nps/WEB-INF/bin/linux/libntls.so.8
Consider a scenario where eDirectory 8.8 SP8 has both IPv4 and IPv6 configured and only one of the them (for example, IPv4) has an entry in the /etc/hosts file, and the other interface is accessible from a remote machine. If you configure eDirectory to listen on both the IPs, the IP AG certificate is generated only for the IP that is listed in the /etc/hosts file. In this example, it is generated for IPv4.
While installing eDirectory 8.8 SP8, which is listening on both IP v4 and IPv6 addresses, IP AG <IPv6> certificate (KMO) is not created.
This occurs when the length of the RDN of the certificate object exceeds the maximum limit of 64 characters. To handle this, a compressed format of IPv6 address is used so that even if the length exceeds the maximum limit, the address is split to accommodate the request. The address is split from the third colon (from the reverse order) in the address.
For example, if the IPv6 address is 2508:f0g0:1003:0061:0000:0000:0000:0002, then the truncated address is 0000:0000:0002. This ensures that the host is identifiable even after the address is truncated.
Use iManager to manually change the default association.
Log in to iManager > Modify > Select the http server object > Select the httpKeyMaterialObject attribute, then change the HTTP server object association to SSL CertificateDNS.