Moving certificate from SHA1 to SHA2

Answer

Moving an end-entity certificate from SHA1 to SHA2.

Using RACF,

a. Create a new 2048-bit end-entity certificate

RACDCERT ID(cert-owner) GENCERT SUBJECTSDN(...) SIZE(2048) WITHLABEL('new-label-name')
or
RACDCERT SITE GENCERT SUBJECTSDN(...) SIZE(2048) WITHLABEL('new-label-name')

b. Create a certificate request for this new 2048-bit end-entity certificate

RACDCERT ID(cert-owner) GENREQ(LABEL('new-label-name')) DSN('request-dsname')
or
RACDCERT SITE GENREQ(LABEL('new-label-name')) DSN('request-dsname')

c. Send the request to an internal/external CA and request to have this certificate signed with SHA2.

d. Identify the root and intermediate certificates that the CA used this time to see if they already exist in the RACF database.

RACDCERT CHECKCERT('CA-returned-dataset-n')

If they already exist, change them from NOTRUST to TRUST

RACDCERT CERTAUTH ALTER(LABEL('label-name')) TRUST

e. Add all certificates returned by the CA to the RACF database

If the certificates are all in one single file (i.e. new root, new intermediate & new SHA2 certificates),

RACDCERT ID(cert-owner) ADD('CA-returned-dataset') WITHLABEL('new-label-name') TRUST
or
RACDCERT SITE ADD('CA-returned-dataset') WITHLABEL('new-label-name') TRUST

RACF adds all certificates that are found in the dataset with the corresponding ownership:
It makes the new non-existing SHA2 root and new SHA2 intermediate certificates owned by CERTAUTH, and
also gives them a label name of LABELnnnnnnnn ;
It updates the new SHA2 end-entity certificate with the signed back information.

If the certificates are in multiple files,

For the new root, and each new intermediate certificates which does not exist in the RACF database,
starting from the top signer,

RACDCERT CERTAUTH ADD('CA-returned-dataset-n') WITHLABEL('whatever-you-choose') TRUST

For the new SHA2 end-entity certificate,

RACDCERT ID(cert-owner) ADD('CA-returned-dataset-n') WITHLABEL('new-label-name') TRUST
or
RACDCERT SITE ADD('CA-returned-dataset-n') WITHLABEL('new-label-name') TRUST

Note: Regardless of the error you get, at any time, 'do not' issue RACDCERT DELETE command to delete the certificate.

f. Find out the label names for the entire certificate chain

RACDCERT ID(cert-owner) LISTCHAIN(LABEL('new-label-name'))
or
RACDCERT SITE LISTCHAIN(LABEL('new-label-name'))

g. Connect the new root and new intermediate certificates to the keyring

Start from the top of the chain (i.e. the root),

RACDCERT ID(ring-owner-userid) CONNECT(CERTAUTH LABEL('label-name') RING(ring-name) USAGE(CERTAUTH))

h. Connect the new SHA2 end-entity certificate to the keyring

RACDCERT ID(ring-owner-userid) CONNECT(ID(cert-owner) LABEL('label-name') RING(ring-name) USAGE(PERSONAL)) DEFAULT- DEFAULT should be in the CONNECT parm.
or
RACDCERT ID(ring-owner-userid) CONNECT(SITE LABEL('label-name') RING(ring-name) USAGE(PERSONAL)) DEFAULT

The DEFAULT parameter is optional depending on the requirement of the application.

i. Check that the entire certificate chain has SHA2 certificates and they are all connected to the keyring

Simply repeat step #f

j. Refresh DIGTCERT class

SETR RACLIST(DIGTCERT) REFRESH

k. May need to re-customize the application to point to the new SHA2 certificate label name (e.g. z/OSMF & OpenSSH)


l. Export the new root certificate to the remote parties

RACDCERT CERTAUTH EXPORT(LABEL('root-cert-label')) DSN('dsname') FORMAT(CERTDER) or FORMAT(CERTB64)

m. Optionally export the new SHA2 end-entity certificate to the remote party.

This step is needed only when the remote party is also running on z/OS and performing certificate mapping (e.g. CICS).

RACDCERT ID(cert-owner) EXPORT(LABEL('new-label-name')) DSN('dsname') FORMAT(CERTDER) or FORMAT(CERTB64)
or
RACDCERT SITE EXPORT(LABEL('new-label-name')) DSN('dsname') FORMAT(CERTDER) or FORMAT(CERTB64)

n. Refresh/recycle the application on z/OS

o. Refresh/recycle the remote parties

Using GSKKYMAN,

a. Create a 2048-bit certificate request

GSKKYMAN Option 2 (Open key database), then sub-option 4 (Create new cert request)

b. Confirm the request is generated properly

GSKKYMAN Option 2 (Open key database), then sub-option 3 (Manage cert requests)

c. Send the request to an internal/external CA and request to have the certificate signed with SHA2

d. Add the certificates from the CA to the KDB

If the certificates are in one single file,

GSKKYMAN Option 2 (Open key database), then sub-option 5 (Receive requested certificate or a renewal certificate)

GSKKYMAN adds all certificates that are found in the file into the corresponding sections in the KDB.
It puts the new SHA2 root and new SHA2 intermediate certificates under the list displayed by
GSKKYMAN option 2 (Open key database), sub-option 2 (Manage certificates),
and also uses the subject DN value inside the certificate as the label name.
It puts the new SHA2 end-entity certificate under the list displayed by
GSKKYMAN option 2 (Open key database), sub-option 1 (Manage keys and certificates).

If the certificates are in multiple files,

For the root, and each intermediate certificates, starting from the top signer (i.e. the root),

GSKKYMAN Option 2 (Open key database), then sub-option 7 (Import a certificate)

For the end-entity certificate,

GSKKYMAN Option 2 (Open key database), then sub-option 5 (Receive requested certificate or a renewal certificate)

e. Mark the new SHA2 end-entity certificate as DEFAULT (if this is required by the application)

GSKKYMAN Option 2 (Open key database), then sub-option 1 (Manage keys and certificates),
then sub-option 3 (Set key as default)

f. May need to re-customize the application to point to the new SHA2 certificate label name (e.g. z/OSMF & OpenSSH)

g. Export the new root certificate to the remote parties

GSKKYMAN option 2 (Open key database), then sub-option 2 (Manage certificates),
then sub-option 4 (Export certificate to a file)

h. Optionally export the new SHA2 end-entity certificate to the remote party.

This step is needed only when the remote party is also running on z/OS and performing certificate mapping (e.g. CICS).

GSKKYMAN option 2 (Open key database), then sub-option 1 (Manage keys and certificates),
then sub-option 6 (Export certificate to a file)

i. Refresh/recycle the application on z/OS

j. Refresh/recycle the remote parties




Moving a root certificate or an intermediate certificate from SHA1 to SHA2.

Using RACF,

a. Ask CA for the new SHA2 root/intermediate certificate

b. Remove the old SHA1 certificate from the keyring

RACDCERT ID(ring-owner-userid) REMOVE(CERTAUTH LABEL('label-name') RING(ring-name))

c. Identify all certificates that the CA used this time to see if they already exist in the RACF database.

RACDCERT CHECKCERT('CA-provided-dataset')

If they already exists, change them from NOTRUST to TRUST

RACDCERT CERTAUTH ALTER(LABEL('label-name')) TRUST

d. Add the new non-existed SHA2 certificate to the RACF database

RACDCERT CERTAUTH ADD('CA-provided-dataset') WITHLABEL('new-label-name') TRUST

If you are replacing more than 1 certificate, start with the root certificate.

e. Connect the new SHA2 certificate to the keyring

RACDCERT ID(ring-owner-userid) CONNECT(CERTAUTH LABEL('new-label-name') RING(ring-name) USAGE(CERTAUTH))

f. Check that the entire certificate chain has SHA2 certificates and they are all connected to the keyring

RACDCERT ID(cert-owner) LISTCHAIN(LABEL('end-entity-cert-label-name'))
or
RACDCERT SITE LISTCHAIN(LABEL('end-entity-cert-label-name'))

g. Refresh DIGTCERT class

SETR RACLIST(DIGTCERT) REFRESH

h. Refresh/recycle the application on z/OS

i. If this is a new SHA2 root certificate, export the new SHA2 root certificate to the remote parties

RACDCERT CERTAUTH EXPORT(LABEL('root-cert-label')) DSN('dsname') FORMAT(CERTDER) or FORMAT(CERTB64) or FORMAT(PKCS7B64)

and refresh/recycle the remote parties.

Using GSKKYMAN,

a. Ask CA for the new SHA2 root/intermediate certificate

b. Add the new SHA2 certificate to the KDB

GSKKYMAN option 2 (Open key database), then sub-option 7 (Import a certificate)

If you are replacing more than 1 certificate, start with the root certificate.

c. Check signature algorithm

GSKKYMAN option 2 (Open key database), then sub-option 2 (Manage certificates),
then sub-option 1 (Show certificate information)

d. Export new SHA2 root certificate to the remote parties

GSKKYMAN option 2 (Open key database), then sub-option 2 (Manage certificates),
then sub-option 4 (Export certificate to a file)

e. refresh/recycle the application on z/OS