move "Organizational CA" from a NetWare-Server to a OES2018-Server

Hello *,

our Oranizational CA is on a NetWare56.5SP8 Server. One of the first steps to get rid of NetWare is to move or recreate an Organizational CA on OES2018.

I cannot find a hint if the NetWare-Servers are compatible with the new CA ... (pkidiag) until the NetWare-Servers are migrated to OES2018, also?

Kind regards




  • It may be easier to create a new CA... But this would depend on what
    certificates are in use and potential outages, etc.

    How many servers are in the tree?
    Any user certificates or just server based certificates?
    When does your CA expire?
    Are you using the certificates for anything other than LDAP?
    If only for LDAP, how many applications would be impacted?

  • It depends under which NICI/NMAS/PKI build the CA was initially built.

    After some version (I long ago forgot the detail) you could export the CA's private key, so you could export and import it to a new server.  However, if you have a CA built on NW65 odds are good th e10 year span of the CA is pretty darn near ending as well.

    Easiest would be to create a new CA.  You will have to recreate all existing gcerts (which is easy for servers, since iManager will recreate default certs).  But then you have to consider any OTHR certs in use somewhere.

    And any thing that trusts your CA will need to import the new CA to their truststore. So it really depends.

  • Hello *,
    the existing Certificate is Version 3 - Signature algorithm: Sha1 With RSA - 2048 bits
    The certificates expire in March 2020.
    There are six NetWare6.5-Servers, three OES-11.3-Serves and four OES2015.1-Servers in the tree.
    I would install an additional OES2018-server in the tree, first ...
    [By the way, the NetWare-Servers are holding partition-replicas ... Can we add new replicas to the OUE2018-Server (compatibility eDir8.8SP5, eDir9.1)? ]
    There are just server based certificates.
    The Certificates are used for LDAP and IDM-Driver (Identity-Management) from a separate Tree.
    Kind regards
  • You have to recreate the CA next month anyway.  Be proactive and do it early now. 

    IDM driver ones will continue to work (until March) I think, since the Cert does not have to be deleted and there is no 'live' query to the CA to validate them.  But since the CA dies in March, you would have to recreate the IDM driver ones as well.  (This means distributing the new CA public key to the Remote Loaders as well but you have to do that in March anyway).

  • Hello *,
    thanks for your reply. That's what I supposed also.
    OK - I have to recreate the CA anyway.
    But, I am scared of the compatibility: There are NetWare6.5-Servers (with eDir 8.8 SP5 IR holding rw-replicas of all partitions. The new OES2018-Server has eDir v9.1.
    Probably it woud be better to install two OES2018-Server in the tree, first; make these two OES2018-Servers to the master- and RW-replica-server; delete the replicas from the NetWare-Servers and
    Recreate then the new CA.
    Is this a good plan?
  • I do not know for certain how the compat between 885 and 91 is going. Generally eDir is ok to interoperate.

    Things to avoid:

    EBA (Enhanced Background Auth) - do not enable that. Will break 885 for sure.

    Do not enable FIPS support now either.


    Ask a better question - upgrade path from NW65SP8 with 885 to OES2019.  What do the docs say on the topic? Search for TID's as well. I do not know the answer to this one with certainty.

  • Hi,

    the eDir2eDir driver does check CRLs if your server certificates have a Certificate Revocation List Distribution Point extension in them. So be sure to keem them alive if you continue to use the old certs.

    I learned that when one customer turned off port 389 in response to a security scan but had all its certificates minted with an ldap://... CRLDP.


  • Good to know!  But if you are moving your CA and it is expiring in Marc 2020, might as well remake the eDir to eDir certs since they are about to expire regardless.


  • Hello *,

    we succeeded in creating a new Org-CA. All OES- and NetWare-server have new valid certificates (but the "*EC*" certs - they show "Invalid: CRL Decode Error"). 
    We used "ndsconfig upgrade" on Linux-Servers and "pkidiag" on NetWare-Servers.

    We hope EC-Certs are not needed  for basic usage (although we use eDir2eDir-Synch) ...?

    Then, we moved all the Partition-Replicas from NetWare6.5SP8-servers to OES2015/2018-Servers. All replicas are in sync ...

    There is only one problem left (but a big one) :
    After restarting a NetWare-Server, the users cannot map drives to this NetWare-Server (NCP).

    Error message on the NetWare-Server:
    "SSS.NLM: Cannot load SecretStore Service on a Read Only eDir Replica! SHUTTING DOWN!!! ...
    SSNCP.NLM: SecretStore Services Are Not Operational!!
    SSNCP.NLM: SecretStore NCP Plugin Unloading!!"

    We could not find a solution for this ... So - as a workaround - we added RW-Replicas to this NetWare-Server again. The mapping works now again.

    I guess this will happen to all NetWare-Servers after rebooting them ...?

    Does anyone have an idea?

    Kind regards.


  • Secret Store is not per se needed on a Read Only replica.

    You could rename the NLM files on Netware and they will fail to load.  I forget if they are autoloaded by nds, in which case hmm... Been a while since I dealt with Netware... On Linux there is a file that lists the modules to autoload, not sure I remember how it worked on Netware. 

    But the Secret Store not loading is unlikely the issue, the R/O replica is more likely the cause.