How to import a Production VeriSign External Certificate into eDirectory 8.7.3 using ConsoleOne

  • 3920370
  • 23-Jul-2007
  • 26-Apr-2012


Novell eDirectory 8.8 SP1 for All Platforms
Novell eDirectory 8.7.3 for All Platforms
Novell ConsoleOne 1.3.6


These steps document how to import a production VeriSign external certificate into eDirectory using Novell's Certificate Server. These steps are based on the versions of Certificate Server, ConsoleOne and NICI contained in eDirectory 8.7.3 and NetWare 6.5. They 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 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 our Signed 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 in ConsoleOne.

1. Make sure the ConsoleOne workstation is using the following:
ConsoleOne 1.3.6 or higher
Certificate Server snapin Version 2 (2.23 Build 34 or higher) Verify by selected Help - About Snapins.
Server NICI 2.6 or higher. Verify with Control Panel - Add/Remove Programs

2. Open ConsoleOne. From the server's container create a new object - NDSPKI:KeyMaterial object.

3. On the first Create Certificate dialog screen select the server this certificate will be tied to. Give it a descriptive name (e.g., VeriSignCert).

4. For Creation Type choose Custom and select Next. On the specify Certificate Authority page select "External Certificate Authority" and select "Next".

5. On the RSA key size screen accept the defaults of 2048 bits and 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. The next screen is the Certificate Parameters screen. Only modify the subject name here. 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 community will access secure services on this server using the URL www then that will be the "cn" part of the subject name. In our test, we will use www. Select the "Edit" button next to Subject name then click on the 2 arrows to the right of it. This puts our server name at the beginning. 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 thru 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.

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. VeriSign will drop the OU as they do not support this in the 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. See KB 10081133 - What causes the security alert when using https and Internet Explorer?

7. Also on the Certificate Parameters screen use the SHA1 algorithm (strongest authentication).

8. Then select "Next" and "Finish". The keys will be generated.

9. Select to save the CSR to the System clipboard in Base64 format and select "Save".

B. Provide VeriSign with the generated CSR.

Following VeriSign's instructions, send the CSR request file generated to them. Be sure that at the appropriate point during the exchange with VeriSign that you select Novell as the Server Platform. This will indicate to Verisign that you want the Trusted Root included with your signed certificate. Once you receive back the signed certificate via email you may proceed to the next step.

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). There are two import screens presented during this process. The first screen can be left blank if you selected Novell for the Server platform in Step B. If VeriSign did send you a separate Trusted Root in addition to your signed CSR, make sure that you use it during the first import screen. The second requires the Signed Certificate emailed to you from VeriSign.

1. Using ConsoleOne, open the properties of the server KMO. Select the Certificates tab - Trusted Root Certificates page - Select Import. Make sure you DO check the box labeled"No Trusted Root Available" (unless VeriSign did send you a separate Trusted Root). Select Next.

2. You are now at the second import screen. It is here that the Signed Certificate received from VeriSign is pasted in. Open your email client. In the last part of the email body you will see a section that has a header of BEGIN CERTIFICATE followed by many characters that is terminated with an END CERTIFICATE line. Highlight and copy all characters between the Begin and End statements including the Begin and End statements as well. Back on the ConsoleOne screen left click once in the Certificate Import dialog then simultaneously press the"Control" and "V" keys to paste in the information. Select Finish.

3. If all the information looks correct on the Trusted Root Certificates page on the Certificates tab, then click the Validate button to make sure that the certificate chain is correct. You will also want to try to Validate the Public Key Certificate as well. If you get an error about the revocation list, give your servers some time to synchronize and then go back and try to validate theh Public Key again. This is also trueif the public key validates but the private key does not. Alternately, if using Console One, you could modify it's shortcut and append -ForceMaster after the ConsoleOne.exe statement. This will only read from the master replica. NOTE: Both the F and M need to be capitalized.

D. Enabling the application to use the new KMO

1. Test the new KMO by unloading PORTAL.NLM and HTTPSTK.NLM from the server's console. You may have to unload some other dependencies depending on your NetWare version. If you have LDAP SSL working, it might be easier to just point your LDAP SERVER object to the new KMO and try to bind via SSL to your LDAP server.

2. Reload HTTPSTK with the new KMO (Example., load HTTPSTK.NLM /SSL /keyfile:"VeriSignCert"
NOTE: The certificate name is case sensitive. The -SERVERNAME may be excluded.

3. Load PORTAL.NLM on the console.

4. Open a browser on a workstation and connect to Remote Manager via SSL ( Example., https://server_ip:8009 )

5. If you are prompted to accept a certificate then the new KMO is working.

6. If you are using GroupWise Web Access, you'll need to change the certificate that Apache is pointing to if running NetWare 6.x or you'll need to modify the Netscape Enterprise Webserver config files if running NetWare 5.1 The following are the files you need to modify. Just do a search for the"SSL CertificateDNS" (the default certificate) and replace with the name of the new SSL certificate you created for VeriSign. You DO NOT need to include the name of the server after the certificate name even though ConsoleOne displays it that way.

NetWare 5.1 - Enterprise Web Server

Restart the Web Server by typing NSWEBDN and then NSWEB

NetWare 6.0 - Apache

Restart the Apache Webserver by typing NVXADMDN and then NVXADMUP

NetWare 6.5 - Apache2

Restart the Apache2 Webserver by typing AP2WEBDN and then AP2WEBUP

In rare situations, the certificate may look completely valid from ConsoleOne'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 reson behind this is because all newer versions of LDAP use NTLS instead of SAS. Apache and other web servers still use SAS and NILE for SSL communiation.

A simple way to regenerate the SAS/NILE key that an SSL certificate uses is to export the SSL certificate along with the Private key and then reimport it. This should be done after a successful import as a matter of caution so that the certificate can be backed up and stored offsite for disaster recovery.

Follow these steps:

Make sure you are running the latest ConsoleOne snapins (See Step A above).

1. Open ConsoleOne | Browse to the new SSL certificate object | Properties

2. Go to the Certificates tab and select Export. You want to export the certificate to a pkcs#12 file.

3. You should be prompted to export the Private Key. If you are not, make sure you are running the latest snapins and are logged in as a user with Supervisor rights.

4. Choose a location for the .PFX file and specify a password.

5. Verify that the .PFX file has been created and in the proper location.

6. Now re-import the keys into the KMO object. Properties - KMO Object - Certificates - Replace.

7. Choose to point to a file and locate the .PFX file generated in step 5.

8. Enter the password and then select Finish

9. Test the certificate against your preferred web server.

The steps to perform these procedures in iManager as well as other helpful TID's can be found in TID 3033173 : How to import a Production VeriSign External Certificate into eDirectory using iManager.