Novell Home

Cleaning Up after Losing Your CA

Novell Cool Solutions: AppNote
By Greg Riedesel

Digg This - Slashdot This

Posted: 17 Jan 2007
 

This AppNote provides information about recovering services on NetWare and Open Enterprise Server - NetWare after losing your eDirectory tree's Certificate Authority. There are many Novell services that depend on eDirectory provided certificates, and each has its own way of handling the change. In most cases losing the CA is not an immediate problem requiring immediate fixes; changes required by creating a new CA can be rolled out over a number of days, or even weeks and months.

Introduction
Setting Up the New CA
  Creating the new root CA
  Exporting the new CA's Public Key
Backing Up the New CA
The RootCert.Der File
Reconfiguring Applications
  NDLAP
  iPrint
  iManager
  OpenSSH
  NetStorage
  iFolder
  VirtualOffice

Introduction

The worst has happened. The server that held your eDirectory tree's root Certificate Authority certificate has died, and the backups of your certificate that you thought you had are no good, or you can't remember the password you used when you exported the certificate. Or, your old tree's certificate has expired, you were an early adopter of NDSPKI, and you need to replace it. Your only choice is to create a new certificate and pick up the pieces. Unfortunately, there are quite a lot of pieces to pick up.

Happily, unless you were using your CA quite a lot, you have some breathing room. Existing certificates will still be valid until they expire. The problems start cropping up when you need to start generating new certificates.

NetWare has several services that depend on SSL. Each of those can have different ways if interacting with SSL, some of them you didn't even know were using SSL. My hope is to provide a checklist of system services that depend upon SSL and how to update them to new certificates or a new CA.

Setting Up the New CA

Creating the New Root CA

This process is well documented, and in all likelihood is the easiest part of the procedure for getting a new CA into a tree.

Exporting the new CA's Public Key

When you get your certificate created, you will want to export the public key for the new certificate.

In ConsoleOne,

1. Go into the new certificate object's properties.

2. Go to the Certificates tab, Public Key Certificate.

3. Click on the Export button.

4. When asked to include the private key, say "no."

5. Select a location, and export in DER format. Don't use base64 format for this.

In iManager,

1. Go to the eDirectory Administration section.

2. Select Modify Object.

3. Browse to the newly created CA object.

4. Go to Certificates -> Public Key Certificate.

5. Click the Export button.

6. When asked to include the private key, say "no."

7. Select 'binary DER' format (the default) and click Next.

8. Click on the 'Save the exported certificate to a file' link.

Backing up the new CA

This process is very similar to the one you just went through to get the public key.

In ConsoleOne,

1. Go into the new certificate object's properties.

2. Go to the Certificates tab, Public Key Certificate.

3. Click on the Export button.

4. When asked to include the private key, say "yes."

5. Enter a password, this is required. It can't be blank.

6. Select a location, and hit Next.

7. Click Finish to complete the export.

8. Repeat steps 2-7 with the 'Self Signed Certificate'.

In iManager,

1. Go to the eDirectory Administration section.

2. Select Modify Object.

3. Browse to the newly created CA object.

4. Go to Certificates -> Public Key Certificate.

5. Click the Export button.

6. When asked to include the private key, say yes.

7. Enter a password, this is required. It can't be blank.

8. Click on the 'Save the exported certificate to a file' link.

9. Repeat steps 5-8 for the 'Self Signed Certificate'.

Put this file somewhere physically secure, and make sure you have well documented the password used to export the certificate. If you ever need to restore your CA from this backup, you will need the password you exported it with.

The RootCert.Der File

Sitting in SYS:/Public is a file called RootCert.der. It was optionally created when you either installed the Certificate Server onto your server, or the server was installed into the tree. There are some services that depend on the presence of this file, so it is a very good idea to always create it.

This file contains the public key for the eDirectory tree root CA. It is:

  • The file you created when you exported the CA's public key after creating the CA
  • The file you import into browsers to allow them to trust certificates signed by the tree CA
  • Used by some system processes to validate that SSL certificates for things like LDAP are really the correct key

Different products handle this file differently, so there is no hard and fast rule about when to update it to be the new CA's public key.

Reconfiguring Applications

NDLAP

Many, many services depend on SSL-enabled LDAP. Getting the newly signed key into NLDAP is relatively simple, but this change will affect any LDAPS using services. Here are some of the services that depend on LDAPS for correct functioning:

  • iPrint
  • iManager
  • OpenSSH

Here's how to find out which certificate a NetWare server is using with NLDAP.

In ConsoleOne,

1. Browse to the LDAP Server- [servername] object and go into Properties.

2. Select the 'SSL/TLS Configuration' tab.

3. Note the entry in 'Server Certificate'.

In iManager,

1. Go to the LDAP section.

2. Enter 'LDAP Options'.

3. Select the View LDAP Server tab.

4. Select the LDAP Server object you want.

5. Go to the Connections section.

6. Note the entry in 'Server Certificate'.

By default the LDAP Server object uses the SSL CertificateDNS '[Servername]' object, though this can be changed. To update this one, you need to delete the old object and create a new SSL key named the same and with the same properties. If the default certificate was used, the defaults in the Create New Certificate dialog screens are appropriate.

To make the change apply, you will have to run the following commands on the server screen.

NWLDAPSRV1:unload nldap
Module NLDAP.NLM unloaded
NWLDAPSRV1:load nldap
Loading Module NLDAP.NLM

Loading Module LBURP.NLM
Loading Module LDAPXS.NLM
Loading Module NMASLDAP.NLM
Loading Module SASL.NLM
NWLDAPSRV1:

This forces NDLAP to-reread the key. At this point, all SSL communication to NDLAP will be using the new key. Make sure services that use secure LDAP are aware of the new certificate authority.

iPrint

Novell iPrint uses SSL in two places: on the front end between the end user and the iPrint server, and on the back end between the LDAP source and the iPrint server. The back end is affected by a change in NLDAP certificate; the front end is affected by certificate expirations. The text file used to configure the web-server portion of iPrint can be found in SYS:/Apache2/iprint/ipp.conf

The file will contain a line similar to this one:

NWSSLUpgradeable 192.168.202.110:631 "CertificatePrint"

This is what determines which SSL certificate is used to present to end-users connecting via HTTPS. The name in quotes is the name of the certificate object in eDirectory, and it is located in the same context as the server object. As with all Apache-related SSL changes, to update that to a new certificate you need to delete the old one, generate a new certificate with the same name, and then restart the Apache web-server.

The back end of iPrint is affected by changes in NLDAP certificates. There are two lines in the ipp.conf file that impact how iPrint communicates with the LDAP source: Here is the first one:

AuthLDAPURL "ldaps://[DNS name of NDLAP server]/O=org'cn''(objectClass=user)"

This tells iPrint how to contact the back-end LDAP server. In this case it is clearly using ldaps, so the NLDAP SSL certificate used by that server will impact how iPrint functions.

Here's the other line:

LDAPTrustedCA "SYS:/PUBLIC/rootcert.der"

This line tells Apache where to look for public-keys of trusted CA's. The config-file can have multiple LDAPTrustedCA lines, which allows you to specify more than one key file. Until you are done rolling out new SSL certificates, it is probably a good idea to modify this file to read as follows:

LDAPTrustedCA "SYS:/PUBLIC/rootcert.der"
LDAPTrustedCA "SYS:/PUBLIC/RootCertNew.der"

When you created your new CA, you should have exported the public key for the new CA. This DER file is the 'rootcert.der' file. Copy that file to the iPrint server's SYS:/Public directory and name it 'RootCertNew.der'. This will allow iPrint to use ldap sources with keys signed by the old and dead CA and the new and live CA. As with the front end certificate, this change takes effect by restarting Apache.

Warning: The ipp.conf file gets overwritten during service packs and some iprint patches. If you apply a service-pack, check this file to make sure it is still valid for your environment.

iManager

By default, iManager uses the 'SSL CertificateDNS' certificate for that server. It also does back-end authentication over secure LDAP. Unlike iPrint, iManager depends on Tomcat4 to perform the authentication phase.

Changing the SSL certificate used by iManager is a simple process. As with all Apache-related SSL changes, to update that to a new certificate you need to delete the old one, generate a new certificate with the same name, and then restart the Apache web-server. Now iManager is serving https traffic with a valid SSL certificate.

The back-end processing is a bit more complex. By default, iManager uses the local NLDAP for authentication, though this can be changed by modifying the SYS:/tomcat/4/conf/server.xml file on the 'connectionURL' line. In order for iManager's user-login process to handle the new NLDAP key, you have to import the new key into Tomcat. Doing NLDAP was covered in a previous section, but one more step needs to be taken before you can import:

Copy the new CA's private-key to SYS:/Public/RootCert.der

This will overwrite the previous one, so be aware of the other applications that are name-locked to that file (OpenSSH is one). Once that's done, run the following command on the console of the server:

NWIMANSRV1: tckeygen
NWIMANSRV1: 

Details will be posted on the Logger screen, if you care to watch them. In order for this to take effect, you need to stop and start Tomcat.

NWIMANSRV1: tc4stop
NWIMANSRV1: tcadmdn
NWIMANSRV1: tomcat4
NWIMANSRV1: tcadmup

This stops the Admin-server and regular Tomcat instances, and it restarts both with the new key-file in place.

OpenSSH

OpenSSH on NetWare uses a hard-coded authentication method for locating and verifying users. It uses the Secure LDAP port on the local server, and uses SYS:/Public/RootCert.der as the key-file for that conversation. When the NLDAP certificate for the OpenSSH server gets updated, OpenSSH needs to have the SYS:/Public/RootCert.der file replaced with the new CA's public-key file.

NetStorage

NetStorage uses insecure LDAP and is not affected by NLDAP-certificate changes. Authentication Domains within NetStorage are queried over normal, clear-text LDAP, which is why NetStorage Authentication Domains are frequently pointed at the NetStorage server's own NLDAP.

However, if you have configured NetStorage to use SSL, there is another certificate that you need to look at. Open the SYS:/Apache2/conf/httpd.conf file (or which ever file launches your NetStorage web-server) and look for a line that looks like this:

<ifModule mod_nw_ssl.c>
    SecureListen 192.168.202.224:443 "CertificateNetstorage"
</ifModule>

The name in quotes is the certificate being used by NetStorage to serve SSL. This certificate object is in the same container as the server object. When it comes time to replace that certificate, delete the old one, create a new one with the same name (and whatever options you desire for that certificate, if any), and then shut down and restart the web-server instance.

iFolder

Like iPrint, iFolder has a back-end use of SSL. The back end may use SSL to query an LDAP source for user data. The front end provides a non-SSL form of encryption to secure data, so is unaffected by changes in eDirectory Certificate Authority.

If you are using secure LDAP for iFolder,

1. Open the SYS:/Apache2/ifolder/server/httpd_ifolder_nw.conf file.

2. Locate the 'LdapRootCert' directives. This tells you where iFolder is expecting to find the key-file for the secure LDAP server. These key files are functionally identical to the 'rootcert.der' file used by other NetWare services.

3. Once the secure LDAP server is updated with a new certificate, replace this file with one that has the new CA's public key in it (procedure described above).

4. Once this file is replaced, restart the iFolder service to make the change take effect.

VirtualOffice

Like iPrint, Virtual Office may use SSL in two places: on the front end to secure communication with end-users, and on the back end to both authenticate and access services such as NetStorage. As with iPrint and NetStorage, the front-end SSL configuration can be found in the httpd.conf file stored in SYS:/Apache2/conf.

SecureListen 443 "SSL CertificateDNS"

The above line tells Apache to listen on all bound IP addresses on port 443, and serve the 'SSL Certificate DNS ' [servername]' certificate to any client that connects to that port. The above line is the default configuration; some organizations may segregate services onto additional IP addresses. In that case, you may see a line that reads similar to this:

SecureListen 192.168.202.121:443 "SSL CertificateVO"

As with all Apache-served SSL certificates, the name in quotes is the name of the certificate object in the same context as the server object that will be used to provide the certificate. To update that to use the new CA, delete the old certificate, create a new one named the same as the old one, and then stop and restart the Apache web-server.

Authentication is handled through the same mechanism as iManager. You will have to update the NLDAP certificate on server hosting Virtual Office to use a certificate created by the new CA. The procedures for that are lined out in the NLDAP section of this document. Be aware that many applications potentially use that NLDAP, so plan accordingly.

Once that is done, copy the new CA's private-key to SYS:/Public/RootCert.der

This will overwrite the previous one, so be aware of the other applications that are name-locked to that file (OpenSSH is one). Once that's done, run the following command on the console of the server:

NWVOSRV1: tckeygen
NWVOSRV1: 

Details will be posted on the Logger screen, if you care to watch them. In order for this to take effect, you need to stop and start Tomcat.

NWVOSRV1: tc4stop
NWVOSRV1: tcadmdn
NWVOSRV1: tomcat4
NWVOSRV1: tcadmup

This will stop the Admin-server and regular Tomcat instances, and it will restart both with the new key-file in place.

Additionally, some gadgets also store the CA public key. TID 10086735 describes the procedure to allow HTML gadgets to communicate with HTTPS-based services, such as NetStorage, that are signed by the new Certificate Authority. The command mentioned in the TID can also be used to store more than one public-key, which will enable you to have HTML gadgets to communicate with services signed by multiple certificate authorities. This may come in handy during your transition.

keytool -import -alias <aliasName> -file <C:\TrustedRootCert.der> -keystore <H:\java\lib\security\cacerts> -storepass changeit

Example:

keytool -import -alias oldrootcert -file Z:\public\rootcert.der -keystore F:\java\lib\security\cacerts -storepass changeit
keytool -import -alias newrootcert 'file C:\TrustedRootCert.der -keystore F:\java\lib\security\cacerts -storepass changeit

Where F: and Z: have been mapped to NWVOSRV1/SYS:, this will store both the old and new public keys in the cacerts file.

For this to take effect, tomcat will have to be stopped and started again. The procedure for this is identical to the one following 'tckeygen'.


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

© 2014 Novell