RSA Certificate Manager 6.9 build 557 and earlier
The requirements are to create one Root CA and two Sub CAs, where one sub CA would issue end-entity certificates with SHA1 and the other sub CA would issue end-entity certificates with SHA2 (say, SHA-256). Each of the sub CA certificates (issued by Root CA) should use the same hash type (SHA1 or SHA2) as they would use for signing end-entity certs.
For RSA Certificate Manager 6.9 build 557 and eariler deployments that do not allow a CA to choose a hashing/signature algorithm different than the one chosen during its creation, the following workaround can be used to setup a CA hierarchy as mentioned above. For simplicity, RSA-2048bit keys are chosen in the example below.
1. Create a new self-signed CA, called "RootCA", RSA-2048bit key, using SHA1
2. [The first sub CA] Create a new CA, called "SubCA1-SHA1", RSA-2048bit key, using SHA1, choose "RootCA" as its signer.
3. [The second sub CA] Create a new self-signed CA, called "SubCA2-SHA256", RSA-2048bit key, using SHA-256. Note that we are temporarily creating a self-signed sub CA, it will be soon resigned by "RootCA".
4. Temporarily update "RootCA" CA object in RCM to sign using SHA-256. Use the tool listuclass.xuda (https://RCM-hostname/ca/admin/listuclass.xuda) => click 'list' against XUDA_CA => click 'Edit' button for the "RootCA" object => update the attribute 'CADIGESTTYPE' value from "sha1" to "sha256" => click on Replace button. Restart RCM services.
5. Go to RCM admin interface and click Refresh link so the interface is reloaded. View the CA "SubCA2-SHA256" from CA Operations workbench, click on "Re-sign" button, choose "RootCA" as the signer/issuer and follow the prompts to complete the resigning operation.
6. Undo the temporary changes made in step #4. Use listuclass.xuda (https://RCM-hostname/ca/admin/listuclass.xuda) => click 'list' against XUDA_CA => click 'Edit' button for the "RootCA" object => update the attribute 'CADIGESTTYPE' value from "sha256" back to "sha1" => click on Replace button. Restart RCM services.
7. Go to RCM admin interface and click Refresh link so the interface is reloaded.
After completing the above steps, you end up with:
(a) "RootCA" that has its own cert based on SHA1 and it will sign all other certificates using SHA1,
(b) "SubCA1-SHA1" that has its own cert based on SHA1 (issued by "RootCA") and it will sign all other certificates using SHA1, and
(c) "SubCA2-SHA256" that has its own cert based on SHA-256 (issued by "RootCA") and it will sign all other certificates using SHA-256.
Related Articles
How to create and configure certificates for HTTPS access when using intermediate CA certs in RSA Identity Governance & Li… Number of Views When signing a SHA256 CA off a SHA1 Root CA it does not have a SHA256 signature algorithm in RCM Number of Views Password authentication fails for unchallenged users on AIX after changing to SHA256 password hashing when RSA Authenticat… Number of Views How to import a Root CA or public key Certificate into an Authentication Manager (or AMIS) java key store .jks with keytool Number of Views How to create an Extended Validation (EV) compatible Root CA? Number of Views
Trending Articles
How to manipulate imported RSA SecurID Software Token(s) on an iPhone or iPad device Reporting on RSA Authentication Manager 8.x users with On-Demand Token, a fixed passcode or a hardware/software token assi… How to Download OTP Token Seed Files from myRSA Anomalix idGenius - SAML Relying Party Configuration - RSA Ready Implementation Guide RSA MFA Agent 2.5 for Microsoft Windows Installation and Administration Guide
