How to generate a vettor certificate from a PKCS#10 (CSR) request
2 years ago
Originally Published: 2015-06-05
Article Number
000067292
Applies To
RSA Product Set: Digital Certificate Solution
RSA Product/Service Type: RSA Certificate Manager
RSA Version: 6.9
Issue
The vettor/administrator request page only allows browser generated keys.  There is no option available to submit a vettor request based on PKCS#10 (CSR).  A PKCS#10 (CSR) based vettor request, for example, may need to be submitted when keys are generated in a Hardware Security Module (HSM) for the purpose of using those keys/certificate with a REST API client application.
Tasks
RSA Certificate Manager's (RCM) default request page for vettors/administrators does not have an option to submit PKCS#10 / CSR.  As a workaround, the following steps can be taken to submit a PKCS#10 (CSR) request (generated by an HSM such as nCipher/Thales) and then generate a vettor certificate:

1.  Before proceeding with the procedure below, make a full backup of your RCM installation.  The steps include manually modifying the request object in RCM database.

2.  Generate a keypair protected by HSM, and create a PKCS#10 / CSR using HSM provided tools.

3.  Submit the PKCS#10 request to any available jurisdiction on RCM Enrollment Server.
(Note that Administrative CA jurisdiction is NOT listed on the Enrollment Server request page so the PKCS#10 request cannot be submitted directly to Administrative CA.  Vettor certificates are issued by Administrative CA.)

4.  Make a note of Admin CA jurisdiction’s ID and Admin CA’s MD5.  Those ID’s can be obtained by viewing the Admin CA and its jurisdiction through CA Operations workbench.
(For example, the steps below assume that the Admin CA jurisdiction ID is 7aefd4f9d0f842ce82e137003c48c997e8e7fb0c, and the Admin CA MD5 is 1c2bf6347137826634e2aba4486947e3.)

5.  Update the recently submit request object in RCM db so that (i) the request belongs to the Admin CA jurisdiction (instead of the jurisdiction it was originally submitted to), and (ii) the request type is changed to make it a vettor request.
 
a.  Use listuclass.xuda tool to view the request object.  Go to https://<RCM-hostname>:444/ca/admin/listuclass.xuda, click on ‘list’ against xuda_cert_req, look up the recently submitted request in the list (usually latest request shows at the bottom of the list), click ‘edit’ against the request submitted in step 3.
(For example, the request DN may look like: “req-id=C0A816830000027C0000000700000001, dn=request_queue”)

b.  Update DOMAINID attribute to that of Admin CA jurisdiction ID.
(For example, using sample values in step 4, replace the DOMAINID value with 7aefd4f9d0f842ce82e137003c48c997e8e7fb0c.)
 
c.  Update ISSUER-CA-MD5 attribute to that of Admin CA MD5.
(For example, using sample values in step 4, replace the ISSUER-CA-MD5 value with 1c2bf6347137826634e2aba4486947e3.)
 
d.  Update ADMIN-TYPE attribute to add the value “vettor” (without enclosing quotes), so the request is marked as a vettor request.
 
e.  Click ‘REPLACE Object’ button at the bottom of the page, to commit the changes to db.
 
6.  Go to Administrator Operations workbench, select ‘request-active’ under ‘Vettor’ section.  The recently submitted request that was tweaked through listuclass.xuda tool, should show up on the page.  Click on the request, and approve to generate the vettor certificate.
 
Notes
The listuclass.xuda tool must be used very carefully exactly as guided by RSA Customer Support.  Changes made to RCM database using listuclass.xuda can render the db in a bad state and cause RCM to not function as expected.

Related Articles

Trending Articles

Don't see what you're looking for?