How to import a Production VeriSign External Certificate into eDirectory using iManager

  • 3033173
  • 03-Apr-2008
  • 06-May-2015


VeriSign Certificate
Globalsign Certificate
RapidSSL Certificate
Novell NetWare 6.5
Novell eDirectory 8.7.3
Novell eDirectory 8.8
Novell Certificate Server 2.x
Novell Certificate Server 3.x
Novell iManager 2.7


How to import a Production VeriSign or Globalsign External Certificate using iManager.
How to import a Production RapidSSL External Certificate


These steps document how to import a production VeriSign external certificate into eDirectory using Novell's Certificate Server and Novell iManager. These steps are based on the versions of Certificate Server, iManager and NICI contained in eDirectory 8.7.3. It also references the links found on VeriSign's site on the date of this Solution Document.

1. First a CSR (Certificate Signing Request) must be created. To do so, create a KMO (eDirectory Object class NDSPKI:KeyMaterial Object - this is also known as a Server Certificate) with the appropriate key information. We will then send VeriSign our CSR which they will sign and send back to us. This will be ourSigned Certificate.

2. To complete the KMO, the signed certificate received from VeriSign must be imported.

3. Services need to be configured to use the new KMO.

Together these items create the certificate with the proper certificate chain and allow for services to use the certificate for SSL enabled communications.


A. Creating the CSR using iManager.

1. Make sure that you are running iManager 2.7 Certificate Server Plug-in version 3.320.20081118 or greater.  You can do this by logging into iManager, selecting the Configure button and selecting the "Installed Novell Plug-in Modules" task under "Plug-in Installation". If "Novell Certificate Server Plug-ins for iManager" do not show up, then you need to download the latest PKI plug-in and install it.

2. From iManager select "Create Server Certificate" within the"Novell Certificate Server" role. Browse to the server for which you are creating the certificate.

3. For the Nickname field, give the certificate a descriptive name such as "VeriSign".

4. For Creation Method choose Custom and select Next. Specify "External Certificate Authority" in Step 2 of the wizard and select "Next".

5. Accept the defaults of 2048 (bits) for the Key Size and be sure to check the option to "Allow private key to be exported" then select "Next".
NOTE: Selecting to allow the private key to be exported allows you to later export the keys into a PKCS#12 file for disaster recovery purposes.

6. In Step 4 of the wizard you need to specify the subject name. This part is VERY IMPORTANT! The subject name is permanent. It should reflect the name or URL that will be used to access this server. If your organization will access secure services on this server using the URL then that will be the "cn" part of the subject name. In our test, we will use Select the "Edit" button (looks like a pen) next to Subject name. The"Edit Subject Name" window will pop up. Click on the 2 revolving arrows button to the right of it. This puts our server name at the beginning instead of the end. For our example, use the following subject name ".CN=server1.OU=finance.O=headquarters.L=provo.S=utah.C=us" replacing the fields with your site specific information. The OU and O values are not that important. If you need to go through the exercise again you will need to modify the context slightly as each CSR must be unique in Subject Name. Example "CN=www.". Again the O and OU names are not critical but Novell recommends that they reflect this server's eDirectory context. Click OK when the subject name is the way you want it and click Next.

NOTE: For VeriSign you will need to make sure and include the L, S and C (Location, State, Country) or else you will get an error requesting the certificate in step B. Some vendors
may drop the OU as they do not support those in the subject name, others like Verisign currrently, will add additional OU fields to your subject name.  The critical part is the cn=_____.  As stated earlier, it must match the name that will be used to access the service that will be using the certificate.  If the names do not match, you will always get a Security Alert warning each time the certificate is accessed.  SeeTID 3028260

NOTE: Some certificate vendors expect certain site specific information in uppercase.  In particular, the country value needs to be uppercase when using  Using the above example, the subject name needs to be

7. You will see a summary screen. Verify the subject name once again and then select Finish.

8. The next screen will present the text of the certificate in ASCII format on the screen as well as a link to "Save Certificate Signing Request" underneath the block of text. Select this link and Save the CSR file somewhere in a safe place on your workstation and Close the wizard.

B. Provide VeriSign or Globalsign with the generated CSR.

Following the instructions from your chosen third party vendor -- VeriSign in this example -- send the CSR request file generated to them. Some companies will include the Trusted root in the returned certificate, but most will not anymore.  The instructions for the next step are for the case where they did not include any intermediate or root certificates in the returned signed package.  This is the method that VeriSign currently uses, for example.  In the return email that contains your signed certificate, there are links for getting the intermediate certificate, and root certificate.  Follow the links and instructions to save those certificates as files on your local system.  We will assume you have done that, and named the files "VeriSign Intermediate CA.der" and"VeriSign Root CA.der".  The email with your signed certificate may have either a file attached that contains your signed certificate, or in many cases, it is just contained in the body of the email. In this case, you must copy all the text starting with the “-----BEGIN CERTIFICATE-----” up to the “-----END CERTIFICATE-----” lines, inclusive. Save that data in a file locally, typically named the same as your CSR file name, with a .der extension. Actual name doesn't matter, but if you use the .der (or .cer) extension, then Windows recognizes the file type and can interpret it for you if you are curious. Just remember the name for when you start the import process.

C. Import the Signed Certificate into the KMO

Once you have received your email from VeriSign containing the Signed Certificate you are ready to import it into the KMO object created during the CSR creation (Step A above).

1. Using iManager, select the "Server Certificates" role under"Novell Certificate Access". You should see your the certificate name you created in step A.  In our example it is called VeriSign.  If you don't see it, make sure you have the right server selected in the blue header.  There is a magnifying glass browse button that will let you browse to a different server.  The Certificate Status of the certificate should provide an "Import" link.  Select this link.

2. You will need the intermediate and root CA files to complete the import process, as mentioned in step B above.  If you haven't saved them where you can browse to and open them, you should do so now before continuing.  If you are running any Windows operating system, double clicking on those files will give you the details for each certificate.

3. Now you need to import the actual signed certificate.  In iManager, check the box next to the certificate to be imported, in this case, VeriSign, then click the "Import..." link, Click New menu item and browse to the .DER file you saved your signed certificate as in Step B above, then click OK.  You should now see the your certificate name added to your list with type CSR.

4. Now you must supply the rest of the certificate's validation chain.  This is where we use the intermediate (if given) and root certificates you saved from step B above.  Click the New menu item again, and browse to the intermediate certificate (for this example VeriSign Intermediate CA.der”) and click OK.  You should see the certificate's name listed.  If you only have a root certificate directly signing your certificate, you are done adding certificates.  If that was just the intermediate certificate, we must do the same step again, clicking New, browse to the root certificate file name, and click OK.  You should now have the full chain of certificates for you new certificate.  If for some reason you need more than one intermediate certificate, you can continue adding as many as necessary by repeating this step as needed.

5. Typically, VeriSign and other certificate vendors will modify the subject name of the signed certificate they return back to you and add some additional information embedded in your certificate with additional OU fields.  If the subject name does not exactly match that of the one you specified in Section A, the import may fail.  To overcome this, check the box next to the "Waive subject name in certificate" before continuing to the final summary screen.

6. Once you see the summary page, click Finish. You should see a success message.

7. Click once again on the "Server Certificates" task and your new VeriSign certificate will now show up with a Certificate Status of"Unvalidated".  Place a check next to the certificate and click the Validate link. If everything imported correctly, it should return a Valid status.   NOTE: The certificate validity status is not saved in iManager.  Each time you launch iManager the certificate status will return to "Unvalidated".  This is normal and does not mean that the certificate is bad.  Note that to validate a certificate, the server hosting the certificate MUST be able to access the Internet to contact the Certificate signer's web site using the OCSP (Online Certificate Status Protocol).   If internet access is not available, the validation attempt will fail with an invalid OCSP error.

D. Enabling the application to use the new KMO

You must now replace the old certificate in your web server or other application with the new one. You will need to consult the documentation on how to do this for your specific web application whether it be Apache, Tomcat or LDAP. You must reload the application for it to begin using the new certificate.

For example, if you have an Apache based web application, e.g. GroupWise Webmail, you would update Apache's configuration file to point to the new certificate.  On a NetWare server, this would be modifying the sys:Apache2/conf/httpd.conf file.  Find the line that says SecureListen 443 "SSL CertificateDNS", and replace the certificate name with your new certificate object name in eDirectory.  This assumes the default certificate is still present in the httpd.conf file.

Additional Information

In rare situations, the certificate may look completely valid from iManager's point of view, but the certificate still does not work. Typical symptoms of this scenario include the ability to use the new certificate with LDAP, but not with Apache or the Enterprise Web Server. The reason behind this is because all newer versions of LDAP use NTLS instead of SAS. Apache on NetWare and other web servers still use SAS and NILE for SSL communication.

Note, if at any time the "Certificate status" begins to show "import" rather than "Unvalidated" when selecting any server to view its certificates, you may have to restart tomcat on the server that is running iManager to resolve that faulty status.

If the third party certificate is to be used in a Cluster or LDAP load balancing environment, do the following:

1) Create a KMO (Key Material Object, a new server certificate) for one server using the verisign certificate. Follow all of the steps above.

2) When finished with the above steps, create a backup (pkcs12) of that new certificate that was just imported. Go to the certificate and choose to export it. Include the private key and provide a complex password. Keep this exported file in a safe place for disaster recovery situations.

3) For each of the servers in the cluster, create a new KMO using the import method and using the backup just created. It will ask you for the password that you provided on the export. Then configure the services that will be using the new server certificates. If using LDAP services, you will need to have each LDAP server in the cluster point to the new certificates. If you are using an apache website, such as NetStorage, you will need to modify the httpd.conf file to reference the server's certificate. Make sure to only specify the nickname in the httpd.conf file, the certificates eDirectory object's RDN is not required.

Making a Backup of your certificate:

Once you have successfully imported your certificate, it is a good idea to make a backup of the certificate, for disaster recover purposes. This is done again from the "Server Certificates" role under"Novell Certificate Access". You should see your the certificate name you created in step A.

1 . Check the box next to your certificate name, and click the Export function below the blue title bar.

2.  A new screen will appear with a drop-down box labeled Certificates: Click on the arrow, and all the certificates in your certificate chain will be listed. Highlight your Certificate name (not the intermediate or root authority certificates), and press enter.

3. Default is to have the check box for export private key checked. If it isn't checked, then check it. Also check the box to Include all certificates in the certification path. Enter a complex password in the two prompt boxes, then click next

4. The next page has a link to save your exported certificate. Click on that link, and specify a file name to save your certificate. Once saved, you should copy this to a removable media and store in a safe location. Make sure you remember the password used to export the certificate, as it will be required if you ever need to import it again.

Restoring the backup copy of your certificate:

Should you need to restore your certificate, you can do that from the same "Server Certificates" role under "Novell Certificate Access". This is done by clicking the New function below the title bar.

1.  If your certificate was deleted, you can use the same name. Otherwise you must enter a new certificate name in the nickname box.

2. Select the Import radio button in the Creation Method box, and click next

3. Browse and find the saved .pfx file you have from the backup step above. Enter the password you gave when you saved the certificate originally, then click next

4.  A summary screen showing the file name you are about to import is shown. Click Next again.

5.  Another summary screen showing the certificate name to be created and file being imported to create it is shown. Click Next again.

6.  Next screen should show your certificate name, and a success result. The newly imported certificate will now show up in the list of certificates on this server, and can be used, validated, etc just as any other certificate.

Other helpful TID's
Formerly known as TID# 10089761

Change Log

4/16/2010 - Updated importing section for  iManager 2.7 with latest plugin,  added some info on backing up and restoring certificates.
3/11/2015 - Updated Additional Information section for Note about iManager 2.7 faulty "import" status.