000019587 - XudaCASetCertificateStatus() returns error 97  XrcXUDAUNABLE

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

Article Content

Article Number000019587
Applies ToKeon Certificate Authority 6.0 API
IssueXudaCASetCertificateStatus() returns error 97, XrcXUDAUNABLE
A call to XudaVerifyCertificate() function immediately before calling XudaCASetCertificateStatus() works without errors
CauseThe new SSL cert does not have appropriate permissions to access the backend signing services of KCA Secure Directory Server (Xudad). XudaCASetCertificateStatus() function runs a backend service in Xudad, and thus the LDAP rules must be modified to allow the KCA API application using the new SSL cert/key (other than admin.cert/key) the appropriate access.
ResolutionAccess LDAP rules on KCA through the Admin interface, System Configuration workbench -> LDAP rules. Find the LDAP rule that looks like the following:

 access to dn="o=ca,o=services"
   by dn="md5=d16aeeb02fb816b087abbbb75894a3e1" write
   by dn="md5=e147794bdea4afcd4debbbbe416285e6" write
   by dn="md5=fa229b0aaefc163b51b1bbbe949d01d0" write
   by dn="md5=5ef47557ff98c0e6ff0aa6bbb4e52fe9" write
   by dn=".*" none

Add a line to the above rules to grant access to the new SSL client certificate. You will need to know the MD5 hash of the certificate through Certificate Operations workbench and selecting to view the SSL client certificate. The updated LDAP rule will look like the following:

 access to dn="o=ca,o=services"
   by dn="md5=d16aeeb02fb816b087abbbb75894a3e1" write
   by dn="md5=e147794bdea4afcd4debbbbe416285e6" write
   by dn="md5=fa229b0aaefc163b51b1bbbe949d01d0" write
   by dn="md5=5ef47557ff98c0e6ff0aa6bbb4e52fe9" write
   by dn="md5=<md5-hash-of-new-SSL-cert>" write
   by dn=".*" none

If there are additional rules that appear prior to the above rule (i.e. in case KRA is installed), add the new line shown above in all those rules so the new cert has access to signing engine for all CAs. An example of additional LDAP rule in case KRA is installed may look like the following:

 access to dn="id=<jurisdiction-id-hash>,md5=<CA-md5-hash>,o=ca,o=services"
   by dn="md5=054ea6161ddc4bebbbbb0f151bfa6c7a" write
   by dn="md5=d16aeeb02fb816b087abbbb75894a3e1" write
   by dn="md5=e147794bdea4afcd4debbbbe416285e6" write
   by dn="md5=fa229b0aaefc163b51b1bbbe949d01d0" write
   by dn="md5=5ef47557ff98c0e6ff0aa6bbb4e52fe9" write
   by dn=".*" none

And after adding the required line, the updated rule will look like the following:

 access to dn="id=<jurisdiction-id-hash>,md5=<CA-md5-hash>,o=ca,o=services"
   by dn="md5=054ea6161ddc4bebbbbb0f151bfa6c7a" write
   by dn="md5=d16aeeb02fb816b087abbbb75894a3e1" write
   by dn="md5=e147794bdea4afcd4debbbbe416285e6" write
   by dn="md5=fa229b0aaefc163b51b1bbbe949d01d0" write
   by dn="md5=5ef47557ff98c0e6ff0aa6bbb4e52fe9" write
   by dn="md5=<md5-hash-of-new-SSL-cert>" write
   by dn=".*" none

Replace <md5-hash-of-new-SSL-cert> above with the actual hash value.
WorkaroundA new SSL certificate and key (other than admin.cert / admin.key) was generated and used with the KCA API client application. The same application worked fine when admin.cert/key was used.
Legacy Article IDa10554

Attachments

    Outcomes