000025679 - Keon: Cannot issue certificates on KRA; get XrcXUDAUNABLE error

Document created by RSA Customer Support Employee on Jun 16, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000025679
Applies ToKeon Registration Authority 4.5.1
Sentry RA 4.5.1
Keon Certificate Authority 4.5.1
Sentry CA 4.5.1
Sun Solaris 2.6
IssueKeon: Cannot issue certificates on KRA; get XrcXUDAUNABLE error
Cannot issue certificates on Keon RA/Sentry RA. When the KRA administrator clicks the "Issue Certificate" button, the following error appears:

        Program Error
        x-signer-passphrase.xuda: Line 112: [XrcXUDAUNABLE]
        unable to contact directory server!  XrcXUDAUNABLE:
        Unable to get PIN prompt status for CA md5=xxxxxxxxxxxx
The KRA administrator can see other issues certificates through the Certificate Operations workbench, so there is no communication problems between the KRA and Keon CA/Sentry CA
Certificates and CRLs can be issued successfully for the same CA through the KCA Admin interface
CauseAlthough the LDAP ACL rules set in the KCA contain the md5 of the admin.cert, the KCA database no longer has this certificate being presented by the KRA Admin server, and therefore refuses access to the KCA signing engine
ResolutionTo correct this issue, restore the KCA database to the one containing the deleted KRA admin.cert. If KCA database restoration is not possible, the deleted certificate can be manually copied from the KRA database to the KCA database. After adding back the deleted certificate, the KRA can issue certificates normally. To do this, follow the steps below:

1. Note the md5 of the deleted KRA admin certificate. One way to obtain this is to view the KRA LDAP rules - the md5 that appears in all the rules is the md5 of the admin certificate.

2. Stop KRA Services

3. Make a full backup of the KRA installation

4. On the shell prompt, change current working directory to <KRA-install-dir>/Xudad

5. Run the following command to generate an ldif (a text file) of the KRA database:

        bin/ldbmcat -n db/id2entry.tdbm > temp.ldif

6. Use a text editor to open the file "temp.ldif" (generated in the above step and found in the <KRA-install-dir>/Xudad directory). Then, search for the md5 noted in step #1 above and copy the complete object corresponding to the admin cert to another temporary file.

NOTE: The objects in the ldif files are separated by one or more than one blank lines

Copy this file to the KCA installation - it will be needed to update the KCA database. The file "temp.ldif" can now be removed.

7. Stop KCA Services

8. Make a full backup of the KCA installation

9. On the shell prompt, change current working directory to <KCA-install-dir>/Xudad

10. Run the following command to generate an ldif (a text file, which can be removed after the complete solution has been followed) of the KCA database:

        bin/ldbmcat -n db/id2entry.tdbm > temp.ldif

11. Use a text editor to open the file "temp.ldif" (generated in the above step and found in the <KCA-install-dir>/Xudad directory). Then, add the certificate object saved in step #6 above to the end of this ldif file (make sure that there is a blank line between this newly added object and the object immediately above it). Then, save and close the ldif file.

12. Delete db/*.tdbm and db/NEXTID files

13. To generate the database and indexes, run the following command (assuming the current working directory is <KCA-install-dir>/Xudad):

        bin/ldif2ldbm -i temp.ldif -f conf/xudad.conf -e bin

14. Start KCA Services

15. Start KRA Services

The certificates can now be issued from the KRA.
WorkaroundThe KRA Administration Web server's client certificate (the one in the <KRA-install-dir>/WebServer/ssl/certs/admin.cert directory) was inadvertently deleted from the KCA interface. The certificate no longer exists in the KCA database, but exists in the KRA database.
Legacy Article IDa14527

Attachments

    Outcomes