A Forum reader recently asked:
“I found TID 3455150 and have run SDIDIAG. On one of my servers I get this error:
Server : .xxxx. display on .xxxx.yyy.xxx.TREE.: [FAILED] rc=-672
This server does not have a replica on it. I added the server to W0 and resynced the key using the RD in SDIDIAG. I am still not able to export the the Public Key Certificate – I now get error code -1409.”
And here’s the response from Klaus Gast …
If there is any kind of problem with the SDI key you would notice the NICI return code “-1418″ NICI E ENCRYPTED DATA INVALID. Because the SDI key is also used to wrap the private key belonging to a certificate, you would see this error as soon as the server hosting the CA does not have the correct SDI Key instance to unwrap the private key. In such a situation, I
have not seen the “-1409″ NICI return code. So, SDIDIAG will not help you here.
In addition, if there is any problem with the SDI key on the CA server, you also cannot generate any new certificates. That’s because access to the private key of the CA is required in order to issue a new cert.
Here are some troubleshooting steps to follow:
1. As an easy test, you can check if the CA is still operational by just creating a test certificate. If this does not work, you can continue to troubleshoot the CA server. If it does work, there’s no need to use SDIDIAG, as already mentioned.
2. To export the CA, please try to use iManager, and use the latest Certificate Server snapins for all PKI operations.
3. There is a chance that your CA was created with a NICI version before 2.XX and Certificate Server version 2.2X. In that case, the private key has been stored in a way that does not allow any exports. For quite some time, the default has been to store the key in a format that allows it to be exported (check box: allow private key to be … while creating a certificate)
4. Adding a server as trustee to the w0 object is needed in order to allow copying the SDI key from the SDI key host server during the installation process of eDirectory. If you are not dealing with a non-operational CA, you are not dealing with an SDI key problem.
5. In general, the server hosting the CA should have a copy of the security container.