Unfortunately, the extremely useful netware tool, PKIDiag, is not available in Linux. However, the tasks that PKIDiag performs can be duplicated in Linux. This process is very useful if you have to update a server certificate (the default expiration time for a server certificate is two years, so this may happen often if you went with the default settings).

Background

eDirectory by default runs its own Certificate Authority (CA). A CA is nothing more than a self-signed certificate that is used to sign other certificates as being trusted by the Certificate Authority. When you trust the Certificate Authority by importing its Trusted Root Certificate (which is nothing more than a self-signed public key certificate), you automatically trust all certificates that have been signed by the Certificate Authority. The Novell Certificate Manager automates and secures the process of signing certificates, and allows these certificates to be stored in eDirectory for easy access and retrieval.

When an OES Linux server is joined to an eDirectory tree, it generates a private key and requests two certificates from the Certificate Authority:

• SSL CertificateDNS - A certificate that can authenticate the server based on its DNS name.
• SSL CertificateIP - A certificate that can authenticate the server based on its IP Address.

The SSL CertificateIP is rarely used these days as most networks use DNS and the SSL CertificateDNS has a Subject Alternative Name (SAN) property of the server's IP address(es). As of eDirectory 8.8 SP8 the SSL CertificateIP certificate is no longer created by default.

OES Linux then copies the SSL CertificateDNS and its associated private key to /etc/ssl/servercerts. These certificates are then used by all SSL-capable programs on the server, such as iPrint, Tomcat, iManager, etc.

OES Linux also copies the Trusted Root Certificate for the CA to:

For OES1/SLES9

• /etc/opt/novell/SSCert.pem - a text version of the certificate
• /etc/opt/novell/SSCert.der - A binary-formatted version of the certificate

For OES2/SLES10

• /etc/opt/novell/certs/SSCert.pem - a text version of the certificate
• /etc/opt/novell/certs/SSCert.der - A binary-formatted version of the certificate

Preparing the Server

Deleting existing SSL Certificates

First, you need to delete the SSL CertificateDNS and SSL CertificateIP certificates for the server, if they exist. This will allow the server to request new certificates to be minted and signed by the eDirectory CA. These certificates are normally located in the same context as your server object in eDirectory.

Minting New Certificates

Note: If you are install the PKIS 3.1 iManager plugin, you can use the new Create Default Server Certificate Objects iManager task instead to complete this step.

To mint (create) new certificates for the server, simply run ndsconfig upgrade. When prompted, enter your admin username and password:

Exporting the Server Certificate

After doing this step, you should have new SSL CertificateDNS and SSL CertificateIP objects for the server. Unless you access iManager and related services via IP address, such as http://192.168.1.1/nps/iManager.html, you should use the SSL CertificateDNS.

Note: This step requires iManager. Consoleone-equivalent actions can be found in the Novell Certificate Server - Managing NCS documentation.

To export the SSL CertificateDNS certificate:

1. In iManager, go to eDirectory Administration -> Modify Object
2. Select the SSL CertificateDNS - YourServerName certificate object, which should be in the same eDirectory context as your server object and click OK
3. Go to the Public Key Certificate (Self Signed Certificate) tab of the certificate object and click Validate. It should come back as Valid. If not, there is something wrong with your Certificate Authority and you should rectify this problem and regenerate the certificates before continuing.
4. Select Export.
5. Select Yes when asked if you want to export the private key with the certificate.
6. Assign the private key a password. This will be used to protect the private key while it is in transit to the new server. This password will be removed in a future step.
7. Save the resulting pkcs12 file (Personal Information Exchange format) to a secure location on your server. For this example, we will save it to /root/downloads/sslcert.pfx.

Installing the Certificate on the Server

The pkcs12 file we saved earlier contains the private key, public key certificate for the server, and the eDirectory CA Trusted Root Certificate. We now need to extract these different components and place them in their respective locations on the server. The following examples assume you saved the pfx file from above to /root/downloads/sslcert.pfx.

Extracting the files from PFX

At this point, we need to extract the following individual components from the encrypted PFX file:

• Private Key - The private key that the server uses to encrypt SSL traffic
• Server Certificate - The public key certificate that the server identifies itself with to clients
• eDirectory CA Trusted Root - The self-signed public key certificate that identifies the eDirectory Certificate Authority.

You will be prompted for a password for the following commands. This is the same password you used when you exported the certificate.

Installing the Private Key

Command: openssl rsa -in ~/downloads/servcert.pem -out /etc/ssl/servercerts/serverkey.pem

Installing the Public Key Certificate

Command: openssl x509 -in ~/downloads/servcert.pem -out /etc/ssl/servercerts/servercert.pem

Installing the Trusted Root Certificate (binary version)

Command: openssl x509 -outform der -in /etc/opt/novell/SSCert.pem -out /etc/opt/novell/certs/SSCert.der

corrected command

Command: openssl x509 -outform der -in /etc/opt/novell/certs/SSCert.pem -out /etc/opt/novell/certs/SSCert.der

Additional Steps if required

Depending on what you have installed on the server you will need to update the certificates for other services.
Linux User Management will continue to fail to start namcd until namconfig -k is run
Other services possibly effected:

• iManager - See TID# 10097841
• LDAPS - See TID#10066259
• Apache - See TID# 3911570
• Tomcat

Conclusion

At this point your server now has an eDirectory-enabled certificate. If you connect to the server using its DNS name, you should be able to view the certificate. If you import the Trusted Root Certificate into your browser, you shouldn't even get a certificate warning.

Going Further

The vast majority of these steps could be easily scripted into a single command. Here is such a script.

These steps are necessary if you ever change your CA, which can be a good idea if you want it to have a better name than the default (ugly) version of just the name of the tree. Another article on recreating your CA with a prettier name is forthcoming.

Questions

Get stuck, need clarification, or just curious about something? Please post in the Discussion Page.

Primary Author

--Justin Grote - Network Architect - JWG Networks 15:49, 21 April 2006 (MDT)

References

• OpenSSL man page - More information about how the OpenSSL commands above work.
• Novell Certificate Server Documentation

This article is best viewed with a CSS-compliant browser, such as Mozilla Firefox