Quick Start: How to setup eDirectory Certificate Server self-provisioning

  • 7017359
  • 11-Mar-2016
  • 24-Mar-2016


NetIQ eDirectory 8.8 SP8 Patch 7
NetIQ eDirectory 9.0
NetIQ iManager 2.77
NetIQ iManager 3.0
Novell Open Enterprise Server 11 (OES 11) Linux Support Pack 2
Novell Open Enterprise Server 2015


Server certificates are expiring, disrupting services.

The task of maintaining all the server certificates for the tree and manually creating new ones before they expire is becoming too large of a job.

Administrative rights are required on the CA for the iManager user in order to manually generate server certificates.

Errors are being made verifying the identity and appropriateness of the certificate's subject name.


The answer to this is to implement Certificate Server's built-in server self-provisioning feature.  When turned on, eDirectory's Certificate Server has the ability to automatically re-mint server certificates before they expire when the PKI health check runs. 

Prerequsites:  to avoid any issues it is recommended that the minimum versions be used:
- eDirectory 8.8 SP8 Patch 7 or the OES 11\2015 January 2016 update. 
- iManager 2.7 SP7 Patch 6.  Both can be obtained at dl.netiq.com - patches. 
(If using eDirectory 9.0 and iManager 3.0 the steps are the same except there is no need to patch first.)
Below are the basic steps involved:
1. Update eDirectory and iManager to the minimum recommended version or higher.
2. Install the latest eDirectory and PKI plugins
3. Setup Certificate Server in iManager so that self-provisioning is on.
4. Force a PKI health check to recreate the server certificates and export them to the file system.
5. Refresh NLDAP

Detailed Steps
1. Upgrade eDirectory to the recommended version.
Patches can be found at: https://dl.netiq.com/patch/finder/

2. Install the new eDirectory & Certificate Server plugins in iManager.
The plugins can be found in the eDirectory patch.  They are named eDir_88_iMan27_Plugins.npm and pki.npm.   Alternately, and recommended especially if on OES, use iManager's built in updater to pull down the latest plugins.  Once the plugins are updated logout of iManager and restart Tomcat.

3. Backup the CA to a pfx file - Save to filesystem (cert.pfx)
Now would be a good time to backup the CA if this has not already been done. 

From the Roles and Tasks menu in iManager , click Novell Certificate Server > Configure Certificate Authority. 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. Click Export. This opens a wizard that helps you export the certificates to a file. 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.
On the following screen select to save to a file.  This is a complete backup of the CA "just in case".
4. Setup CA to enable self provisioning.
Once this is set all server certificates will be recreated and sent to the file system once the Certificate Server health check is run if the certificates are due to expire 30-60 days out.
Select NetIQ Certificate Server - Configure Certificate Authority - General.  Enable the following:
- Enable: Require read rights to operate the CA
- Enable server self-provisioning
- Health Check - Force default certificate creation/update on CA change
- Health Check - Follow CA's Signing Algorithm
Then select OK.
(Note: if the server is running eDirectory 9.0 as this one is the :Follow CA's Signing Algorithm" option will not be seen.  eDirectory 9.0's Certificate Server mints server certificates with a signing of SHA256 by default even for 8.8 SP8 servers in the tree.  If this server is running 8.8 SP8 see note at the end of this TID about SHA-2 signing in that version.)

5. Force the PKI health check on a server close to its expiration time. 
The PKI Health check will run whenever
a) the machine is rebooted
b) eDirectory is started
c) eDirectory's DIB is closed and re-opened
d) PKI Server is unloaded and re-loaded.
Also, the PKIHealth Check code will automatically update the files if the CA is changed.

Run the following commands from the command line:
ndstrace -c "unload pkiserver"
ndstrace -c "load pkiserver"
If close to expiration the server's certificates have now been recreated and exported to the file system.
6. Refresh NLDAP
In order for LDAP to use the new certificates the LDAP server must be restarted.
ndstrace -c "unload nldap"
ndstrace -c "load nldap"
This will allow the LDAP service to begin using the new certificate that is now associated to it's LDAP server object.
7. Optional: disable SSLv3
If the LDAP clients are capable of TLS it is recommended to disable SSLv3 in the LDAPS protocol:
- In iManager click on LDAP > LDAP Options > View LDAP Server, select the LDAP Server.
- Click the Connections tab, enable the Disable SSLv3 option and click Apply.
    NOTE:In non-English environment you cannot access the Disable SSLv3 option. To access this option change the preferred display language to English.
- Refresh LDAP
8. Test the new certificate
- If on eDirectory 8.8.8:
/opt/novell/eDirectory/bin/ldapsearch -x -h x.x.x.x -p 636 -e /var/opt/novell/eDirectory/data/SSCert.der -D cn=admin,o=novell -w novell -b o=novell -s base -LLL GUID
- If on eDirectory 9.0:
LDAPTLS_CACERT=/var/opt/novell/eDirectory/data/SSCert.pem ldapsearch -H ldaps://x.x.x.x:636 -D cn=admin,o=novell -w novell -b o=novell cn=admin

Note about SHA-2 signing: if the CA resides on an eDirectory 8.8 SP8 server it is recommended to also setup the Certificate Server for SHA-2 signing.  To perform this function on an 8.8 SP8 CA server please refer to TID 7016877.  (Nothing need be done if the CA is on 9.0.  A CA residing on an eDirectory 9.0 server will, by default, mint server certificates with a SHA-2 (SHA256) signature.)

If the 9.0 CA was upgraded from 8.8 SP8 the Root CA's certificate in the server certificate chain will still have a SHA-1 signed certificate.  The SHA-1 depreciation policy should not impact Root CA's signed with it.  The root certificate is self-signed and is not signed by another entity that has been given authority.  Therefore, the signature is not used to validate a Root certificate within a server's KMO certificate chain.  This is only required on the server certificate itself.

For more information please refer to NIST Special Publication 800-57.