KCA errors when requesting or approving certificates in Administration Console
Originally Published: 2003-09-23
Last Modified: 2023-10-06
Article Number
000054229
Applies To
Keon Certificate Authority 6.5
Issue
KCA errors when requesting or approving certificates in Administration Console
One or more Jurisdiction is unable to issue Certificates from Keon Certificate Authority (KCA) Admin console
Error when trying to approve a certificate request: req-authorize.xuda: Line 518: [XrcDBUNABLE] unable to complete database operation. Unable to sign certificate [unable to complete database operation].
Cause
Possible ACL issue caused by incorrectly modifying LDAP ACL entries in the Admin console

***********************
IMPORTANT NOTE:
Modifying the LDAP ACL's can have serious consequences if not performed correctly, Please call RSA Security Technical Support for assistance in reviewing and or changing ACL entries.
***********************

Each Jurisdiction has an ACL entry that allows Keon Registration Authority (KRA) and the KCA services to interact with its objects.  For example, an ACL of the following format may be present for a KRA:

#
# The rules in this section govern access to the CA operations
# backend. The last (and possibly only) rule, for
# dn="o=ca,o=services", governs access to top level services such
# as CA creation.  By default, the Admin server and Scep server have
# write access to this service, and all other clients have none.
#
# Rules governing access to the services of individual CAs must
# appear before the top level rule.  Typically, each such rule
# permits full access to the CA's services to the Admin server and
# to one or more RAs having this CA as their target CA; access to
# all other clients is denied.  It is important that these rules
# appear before the top level rule for dn="o=ca,o=services", and
# that the Admin server be named explicitly in each one.  If the
# Admin server is excluded from one of these rules, it will lose
# access to the services of that particular CA.
#
# RA admin and scep server access to Target CA operations
# (signing) backend.

access to dn="id=1111e351151136d1f2a23790059593244c44444,md5=22222d1bea3c1d56010fe68ee555555,o=ca,o=services"
        by dn="md5=111af1b8675309bcfca1cc534db60111" write
        by dn="md5=22269338902a83ebb5817d5d2b837222" write
        by dn="md5=33383370bc4667d8332ac42ea2554333" write
        by dn="md5=44494856dfe8992b1c3d889808130444" write
        by dn=".*" none

One problem might be that the above ACL is missing the required entries to allow the KCA Administration Server to issue certificates.
Possible ACL issue caused by incorrectly modifying LDAP ACL entries in the Admin console.

***********************
IMPORTANT NOTE:
Modifying the LDAP ACL's can have serious consequences if not performed correctly, Please call RSA Security Technical Support for assistance in reviewing and or changing ACL entries.
***********************

An ACL rule that allows the KCA Administration Server access to write new certificates to the database may have been incorrectly modified.  For example, an ACL of the following format may be present that contains all clients with read only permissions:

#
# Admin server can write subject certs --
# all other XUDA clients can read them once issued.
#

access to filter="objectclass=xuda_certificate" attrs=challengepassword
        by dn="md5=aaaa09ed85f1c771661117387af4aaaa" read
        by dn="md5=bbbbbc8a38e5286753093566251bbbbb" read
        by dn="md5=ccccce7c6a8c8675309ec61564ccccc" read
        by dn="md5=dddddd57cc34a8dc088c2af4d9ddddd" read
        by dn="md5=eeeee867530943cee8b59843f03eeeee" read

Update the above rule to correctly give write permission to the KCA Administration Server.
Resolution
To correct this issue, contact RSA Security Customer Support for assistance in reviewing LDAP ACL entries.

Workaround
KCA Administrator recently modified the LDAP ACL Rules manually

Related Articles

Trending Articles

Don't see what you're looking for?