Moving the Organizational CA to a Different Server



By: florianz

March 26, 2008 8:03 am

Reads: 199

Comments:0

Rating:0

Problem

Here is what I tried at first, to move the organizational CA to a different server:

1. Back up the object as explained in the Novell Certificate Server 3.3 documentation.

2. Copy the CRL and Cert objects as in the documentation.

3. Delete the ca-object.

4. Shut down the target server, edir-wise.

5. Copy the CRL and Cert objects to the target server.

6. Configure Novell Certificate Server and import the .pfx.

The result was:

- The CA is the (new) target server.
- No certificates were listed when I browsed in iManager to Configure Certificate Server > Certificates.

Solution

1. Start dstrace.dlm from the NDS console.

2. Enable just the PKI options for DSTrace.

3. Enable logging of DSTrace to a file.

4. Work through option II of TID 3618399 (http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=3618399&sliceId=SAL_Public&dialogID=428677&stateId=1%200%20430577), which deletes and creates a new CA.

5. Once you have completed this process, attempt to create a new certificate.

6. Check: w0.kap.security attribut: ndspki:sd key server dn

7. Via dhost (Bsp.: https://10.1.19.133:8030/dhost), restart the Novell Certificate Server and check ..\novell\nds\dibfiles\pkihealth.log

8. Delete and recreate the CA, solely with ConsoleOne.

The advantage was that ConsoleOne produced different error codes. One of them was -678 while creating a new CA object, which led to TID 10082074 (http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=10082074&sliceId=&dialogID=428704&stateId=1%200%20430601) and solved the problem.

Tips

- The CA-Server needs to have a replica of the security container. Some versions of novell certificate server need to successfully configure the ca-object, and one may need to temporarily replicate the [Root] and the partition the server (to be the CA)
resides in.
- The CA object needs to have the host-server attribute filled in correctly.
- The security container needs the attribute NDSPKI:Tree CA DN with the correct server.
- The security container must not have more than read-rights configured for public. Essentially, the reason for the problem was that [public] also held supervisor rights (see step 5 above.)

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Categories: Uncategorized

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Comment