Add ability for RACDCERT to handle multiple subject alternative names

Dear users from Feb 1 and Feb 2, 2023,

I was deeply involved with certificates under z/OS during the last few years, and like you, I encountered some limitations. Fortunately, I found the following workarounds:

1) Instead of RACDCERT GENCERT, use the combination Java Keytool and RACDCERT ADD.

With the same user ID under z/OS Unix System Service, you create the key pair and certificate with the Java keytool. Therefore you ensure that your keys never leave the mainframe.

See for example the following script.

Important notes:

• Here the keystore password is stored into a file like abc.pass. Change as needed.

• Because of an issue in RACDCERT ADD, we must set the Java version to 7.1.

#!/bin/sh
KEYTOOL=/pp/java/a71/J7.1/bin/keytool
SAN="SAN:c"
SAN="${SAN}=DNS:abc1.abc.com"
SAN="${SAN},DNS:abc2.abc.com"
SAN="${SAN},DNS:abc3.abc.com"

${KEYTOOL} -genkeypair    \
  -keystore    abc.p12    \
  -storetype   pkcs12     \
  -storepass:file  abc.pass   \
  -alias       abcalias       \
  -keyalg RSA  -keysize 2048  \
  -validity 90 -ext BC:c=ca:false   \
  -ext EKU:c=clientAuth,serverAuth  \
  -ext KU:c=digitalSignature,keyEncipherment,dataEncipherment    \
  -dname 'CN=Multiple ABC systems, O=ABC, L=ABCity, S=AB, C=CD'  \
  -ext ${SAN}

${KEYTOOL} -list -v       \
  -keystore    abc.p12    \
  -storetype   pkcs12     \
  -storepass:file  abc.pass

If the verification is successful, copy the keystore abc.p12 into a z/OS data set, for example:

cp  abc.p12  "//CERTS.ABC.P12"

Then import it with RACDCERT ADD, for example:

RACDCERT ID(ABC)                  -
  ADD('ABC.CERTS.ABC.P12')        -
  PASSWORD('<password-for-abc>')  -
  WITHLABEL('abcalias')

2) Instead of RACDCERT LIST, use the combination RACDCERT EXPORT and Java keytool.

RACDCERT ID(ABC) -
  EXPORT(LABEL('abcalias')) -
  DSN('ABC.CERTS.ABC.PEM')

First line of this data set should be: -----BEGIN CERTIFICATE-----

Then copy it into z/OS USS and display it with the Java keytool, for example:

cp  "//CERTS.ABC.PEM"  abc.pem
keytool -printcert -file abc.pem

I understand that these workarounds may not be fully satisfactory, but it worked well for us.

Moreover, you can automate with JCL and shell scripts.

I just provide an alternative before any RACDCERT LIST support is available. What support has a higher priority has many considerations.

With respect to option 2 to use GSKKYMAN -- if it's that easy to do, why is IBM unable to extract such code from there and build it into RACDCERT LIST (and CHECKCERT and LISTCHAIN) command so that you can display those SANs and Attributes natively? Alternatively -- zSecure already can display all SAN entries -- you could swipe at least that code to put into LIST*.

With respect to option 1 to use PKI Services -- we previously had that installed. It took us many months to get it installed and working properly, and we used it for a number of years, before corporate decided to move to Windows based CAs and Venafi and our external vendor, so PKI Services is NOT a solution here any more. And, yes, we can tell all our CAs to add SAN entries to the signed certs when we submit our CSRs. But for completeness and self-documentation, when we do the GENCERT to build a selfsigned cert, prior to doing a GENREQ to get a CSR, we would like the ability to provide SAN entries on the Gencert (as well as extended attributes), and so that we don't accidentally forget to tell the CAs what SAN entries to add on any given cert. Further, if we were to do a Rekey on the existing (signed) cert -- we'd need all the SAN entries to be duplicated, and I really don't think it would do that either.

There are two separate requirements involving multiple domain names in the Subject Alternate Name (SAN) extension.

1) To enable RACDCERT GENCERT to create certificates with multiple domain names

2) To enable RACDCERT LIST to list certificates containing multiple domain names

For 1) IBM would like our customers to use z/OS PKI Services which provides full CA functions.

For 2) There is a workaround using a utility called gskkyman provided by another IBM component System SSL. Suppose you get back a certificate issued by some other CA and save it in a dataset call mycert.newcert.cer. You may issue this command from omvs:

cat "//'mycert.newcert.cer'" >xx | gskkyman -dcv -der xx

This will display all the certificate fields including all the extensions.

Hello Guest from Jun 20, 2022,

See my message from May 16, 2022 for two possible workarounds for your problem.

In the meanwhile, I could test the second solution with the Java Keytool and RACDCERT ADD, and it works too.

I hope one of these solutions can help you.

Best regards

Hello,

Is there any news on this?

For the AT-TLS activation of our DB2-Connects we need also the support of Certificates with multiple domain names.

AT-TLS is working with the RACF keyrings so we need the certificates inside RACF.

Today we use only RACDCERT commands and it would be better to have all the keys and certificates can be managed the same way and stored on the same location.

For using the GSKKYMAN we need an other key database for generating and extracting the certificate and private key and add it to RACF. This makes the process very complicated.

Kind regards

Hi Guest,

We had a similar problem in our test environment.

As RACF and RACDCERT are not intented to provide all options for certificate manipulation, the best method I found with RACDCERT GENCERT was:

1. Do not use option ALTNAME

2. For the CN option inside of SUBJECTSDN, do not set an hostname, but a short description of your application, with spaces but without other special characters, for example: Db2 group DSG in ABCplex. This way, the CN cannot be misinterpreted as an hostname.

3. We use KEYUSAGE(HANDSHAKE DATAENCRYPT)

4. Create the CSR with RACDCERT GENREQ

5. Write down a list of fully-qualified hostnames, and eventually a list of other extensions to modify (Key Usage, Extended Key Usage, ...)

6. Sent the CSR to your internal signing CA, with the additional request to modify the fields as listed in previous point (5.)

7. Import the signed certificate back with RACDCERT ADD

This method works because the CA can change almost all properties from a CSR.

The RACF panels do not display all certificate options, but they are still there and are used as expected by the underlying libraries such as OpenSSL. It then works as intended

If this method is not acceptable for you, for example, because your CA does not change any field (see point 6.), another colleague suggested the following:

1. Under z/OS USS, use the Java keytool to create a certificate inside of keystore in format pkcs12. This creates a file with extension .p12. With the keytool, you can add your subject altnames as you wish.

2. Copy it into a z/OS data set .

3. Use RACDCERT ADD to import the data set.

4. Create and send the CSR as usual.

I did not test this method.

Best regards

Hi IBM,

any news on this requirement? We also need this urgent, otherwise we've to create the certificates offsite. Usage of z/OS PKI is not an option, as we have a centralized CA and are not allowed to sign certificates on our system, we've to rely on the CA that is used in our company.

Regards

Thank you for submitting this requirement. Please consider using PKI Services for this function.