Novell is now a part of Micro Focus

AppNote: How to Renew a Novell Certificate that was issued by an External CA

Novell Cool Solutions: AppNote
By Patrick Coomans

Digg This - Slashdot This

Posted: 2 Sep 2004

Patrick Coomans
Senior Consultant
4all NetWorks


Certificates expire, that's a fact. Another fact: certificates can be boring, interesting, and very frustrating at the same time. PKI is a complex matter, and if my hair turns grey one day PKI will be to blame.

Once certificates expire it is often one, two, or maybe even three years since the previous installation or renewal of the certificates. So it is very important to document this procedure very well, since this is an extremely important task that only seldom needs to be executed.

In a Novell environment (e.g. using Novell's iChain software) you can create certificates that are signed by an external CA.

What is a secure server certificate?

A secure server certificate is a pack of bits (512, 1024, 2048 ?) that is used to secure data (SSL) in a transmission channel and/or in order to prove the identity of the party you are dealing with. Anyone who has the proper software can generate secure server certificates, but in order to give those certificates "public trust" they need to be signed by a well-known official root Certificate Authority, such as GlobalSign, VeriSign, Thawte, etc. The relationship between a certificate and its CA is usually shown as the certificate chain. The certificate chain shows all CA's that are hierarchically responsible for providing authenticity to the secure server certificate. A root CA is only considered "trusted" if its self-signed certificate is present in the local trusted root certificate's repository on the computer or in the browser.

How is a secure server certificate requested?

  1. In your software you create a public/private key pair together with a Certificate Signing Request (C.S.R.)

    A signing request looks like this:

  2. You then have to send this signing request with proof of identity to your Certificate Authority of choice, which will in turn validate the request and create a signed counterpart, a signed certificate envelope that contains the certificate subject, key usage, your identity, the CA's identity, etc., and also the validity period (valid from ? until ?). If it is the first time you've work with a CA the procedure for validating your identity and authority can take a few days.

  3. When you receive back this signed counterpart (certificate) you will have to attach this counterpart to the already created public/private key pair. In a Novell environment you would typically do this with ConsoleOne, iManager or the iChain GUI.

  4. Your public and private key pair is now ready for use

All will work fine until one day your certificate is about to expire and your CA sends you an e-mail to warn you about this. When you accept to renew this certificate and pay the costs involved, the CA will simply send you a new almost identical signed counterpart with new expiration dates in it, often in the form of a .PEM file. In order to create a new valid key pair you need to detach the old signed counterpart from the certificate and attach the new signed counterpart. Once done, the certificate is renewed and ready for use.

Sadly enough, this operation is not available in any of the Novell management tools, so I will try to describe as well as possible how all this can be done in a very simple way. In my example I will use Novell iChain, but my example applies to any Novell certificate that is represented as a certificate object in eDirectory and is signed by a third-party Certificate Authority.

What attributes are added when adding the certificate counterpart signed by the CA?

Let us first look at the difference between a certificate that is in the phase of "CSR available but signed counterpart not yet installed" and a fully functional certificate.

As you can see, the second certificate object has more attributes than the first one.

Differences between the attributes:

Functional certificate "C.S.R.-phase" attributes present:
NDSPKI:Certificate Chain (not present)
NDSPKI:Given Name NDSPKI:Given Name
NDSPKI:Key File (not present)
NDSPKI:Private Key NDSPKI:Private Key
NDSPKI:Public Key NDSPKI:Public Key
NDSPKI:Public Key Certificate (not present)
NDSPKI:Subject Name NDSPKI:Subject Name

So, the whole point of returning a valid certificate back to its state of "waiting for a signed counterpart" is to delete the following eDirectory attributes from the object:

  • NDSPKI:Certificate Chain
  • NDSPKI:Key File
  • NDSPKI:Public Key Certificate

This is a task, however, that you cannot perform with regular Novell tools because the snap-ins of iManager, ConsoleOne or NWadmin32 will prevent you from doing this. An excellent tool I use for this purpose is Karl Bunnel's NDS Snoop, available for download from the Novell Cool Solutions web site. However there are many other tools that permit the editing of the individual attributes of an eDirectory certificate object, in fact you can even use an LDAP browser if you want.

URL: NDS Snoop:


Another approach could be to disable the PKI snap-in in Consoleone. This is something you can do by renaming pki.jar to something else before starting Consoleone. This .jar file can be found in .\consoleone\1.3\snapins\Security. Don't forget to rename it back to pki.jar after you're done deleting these attributes.

Example: renew a certificate that is on an iChain appliance

Suppose a certificate of a web site is about to expire and this certificate is on the iChain box. What we will do is create a backup of the current certificate and import it again as a new certificate with a different name, so that we still have the old one in case something goes wrong and also reduce the required number of reboots from 2 to 1. Then we will delete the old public certificate from the object and store the new public certificate to it, reboot the iChain appliance and verify if the change was successful. Finally, when all looks OK, we will change the certificate used by the accelerator into the renewed one.

Step 1: make a copy of the current certificate using the iChain GUI


    backup certificate to e.g. "old.pfx"
    rename backup file to e.g. "renewed.pfx"
    restore "renewed.pfx" into iChain

Access the iChain GUI using a web browser such as IE using Microsoft's JVM at http://n1.n2.n3.n4:1959/appliance/config.html. Go to the "Certificate Maintenance" page in the "Home" section. Now select the certificate that is about to expire. Click "Backup".

Don't forget to click "Apply" in order to confirm the backup process.

You can choose to backup the certificate to floppy (A:) or to disk. If you backup to disk the certificate will be on the volume of the iChain appliance. If you don't know how to NCP-enable an iChain appliance, check out TID 10065889. The backup certificate will be found in SYS:\ETC\proxy\appliance\config\user\cert\backup in a .PFX format.

In our example we will backup to disk since we will need a NCP connection to the iChain appliance later anyway. Map a drive to the iChain appliance MAP F:=\\n1.n2.n3.n4\sys and log in as user "ichainadmin".

Rename the filename to something that does not exist in your iChain appliance as a certificate name yet, and restore it using the iChain GUI. (Don't forget to click "Apply")

At this moment you will have a new certificate in your iChain appliance with the same name you just changed the name of the backup file to.

Step 2: delete the public key certificate from the key pair


    make sure you have an NCP connection to the iChain box
    set the ICS_SERVER as your primary server (prerequisite for using NDS SNOOP)
    delete the correct attributes from the key material object

Start your NDS Snoop tools (or whatever you prefer to work with) and delete the following attributes from the imported certificate material object:

  • NDSPKI:Certificate Chain
  • NDSPKI:Key File
  • NDSPKI:Public Key Certificate

Do this in "Object Editor". Select the eDirectory object that represents the copy of your certificate. In the pull-down menu "Attribute" select each of the above three attributes and choose "Remove Attribute" as modification operation each time.

When the tree attributes are selected to be removed, click the "Modify Object" button.

Step 3: retrieve the new public key certificate from the CA's repository


    retrieve the new public key certificate; how this is done depends of your CA
    save the public key certificate including the whole certificate chain

The next step is to obtain the renewed certificate, including the whole certificate chain. Usually this is done using the CA's web site. In our example we use GlobalSign as the CA.

Here are some URL's of CA Repositories:

URL: GlobalSign
URL: VeriSign

Always make sure that with certificate manipulation you don't have expired root or intermediate certificates stored on your computer!

Search the certificate by name (e.g.

Select the right certificate (the one that is the most recent)

Finally export the certificate; preferable format is PKCS7.
Make sure it includes the whole certificate chain (all signing certificates). Then select the whole certificate as shown below and copy it to the clipboard (or save it to a local ASCII file).

Important: do this INCLUDING the ----BEGIN CERTIFICATE --- and ----END CERTIFICATE ----.

Sometimes your CA is not able to provide you with such a certificate that includes the whole certificate chain. If this is the case you can import the certificate as well as the root and intermediate CA certificates, and then use mmc.exe to export the certificate to a PKCS7 format file (.P7B) including all certificates in the certification path.

Step 4: store the new public key certificate to the key pair


    make sure you still have an NCP connection to your iChain box
    start ConsoleOne
    select the correct key material object and import the new public certificate
    restart iChain

Now start ConsoleOne with up-to-date PKI snap-ins and double-click the certificate that you are renewing. Click on the tab 'Certificates' and choose 'Public Key Certificate'. You will notice that ConsoleOne reports: "There are no certificates present for this object. Use the import button below to import certificates."

Now click on the "Import" button. You will get a screen that asks you for the Trusted Root certificate; however, nowadays most secure server certificates are no longer signed directly by the root CA but instead by a number of intermediate CA's that act as a layer between the root CA and the final certificate. Since the interface of ConsoleOne doesn't allow us to import first the root CA certificate and then all individual intermediates, the easiest way to do this is to include all intermediates and the root CA certificate in the server certificate.

You do this by clicking "No Trusted Root Certificate available". (remember: when we exported our public key certificate from the CA's repository we choose to include the whole chain of signing certificates with the server certificate !!) For more information on importing certificates with several intermediate CA's, check out TID 10073709.

Click "Next". Now paste the certificate that was in your clipboard into the space for the Server Certificate, as shown below.

Now click "Finish". The certificate should now be valid and renewed; however, iChain doesn't know this yet. The iChain appliance needs to be restarted in order to read in the correct (renewed) certificate.

Step 5: switch the accelerator certificate to the renewed one


    start the iChain GUI
    change the accelerator properties in the "Configure" tab
    choose the correct certificate and apply

This concludes the example of renewing a certificate in a Novell environment using a certificate stored on an iChain appliance.

Conclusion and additional resources

To conclude, you see that renewing a certificate doesn't necessarily mean "replacing" a certificate. It is really very easy to strip off the signed part from a certificate and attach an updated (renewed) signed part.

A big challenge, however, is to make sure that the correct root certificates and intermediate certificates are present, especially when the CA just renewed one of the intermediates.

Here you can find some additional reading on this subject:

SSL and TLS Essentials, Securing the Web
By Stephen A. Thomas
Wiley Computer Publishing
ISBN 0-471-38354-6

Network Security, Private Communication in a Public World
By Charlie Kaufman, Radia Perlman and Mike Speciner
Prentice-Hall, Inc.
ISBN 0-13-061466-1

Secure Electronic Commerce, Building the Infrastructure for Digital Signatures and Encryption, second edition
By Warwick Ford and Michael S. Baum
Prentice-Hall, Inc.
ISBN 0-13-027276-0

The web site RSA Labs has an extensive coverage of all the PKCS standards etc. Check out this URL if want to learn more about what exactly means PKCS# 12 and so on.


Also very interesting is the RSA FAQ, Frequently Asked Questions about Today's Cryptography which can be found at the following location:


Appendix: File formats used in certificate handling


X.509 DER (*.cer)
X.509 PEM (*.pem)
PKCS#7 DER (*.p7b)
PKCS#7 PEM (*.pem)
PKCS#12 DER (*.p12, *.pfx)


X.509 DER (*.crl)
X.509 PEM (*.pem)
PKCS#7 PEM (*.pem)
PKCS#7 DER (*.p7b)
PKCS#12 DER (*.p12, *.pfx)

Certificate Signing Requests (CSR)

PKCS#10 DER (*.p10)
PKCS#10 PEM (*.pem)

Private Keys

PEM (*.pem)
PKCS#8 PEM (*.pem)
PKCS#8 DER (*.)
PKCS#12 DER (*.p12, *.pfx)

Please note that the .PEM format is not standardized at all, for example Microsoft Windows uses .CER even if the format is PEM.

BER stands for Basic Encoding Rules, CER stands for Canonical Encoding Rules and DER stands for Distinguished Encoding Rules.

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© Copyright Micro Focus or one of its affiliates