KCA errors when requesting or approving certificates in Administration Console

3 years ago

Originally Published: 2003-09-23

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

Don't see what you're looking for?

Related Articles

Trending Articles