The Mainframe team would like to migrate the CA XCOM for z/OS 12.0 certificates to mainframe security from its current configuration in local USS datasets.
You may use self-signed certificates or those supplied by a Certificate Authority.
They can be stored in a keyring that is maintained by CA ACF2, IBM RACF or CA Top Secret. The XCOM server or batch job must run with authority to use the appropriate KEYRING to which the certificates have been loaded. In this case, the required KEYRING is referenced in the [KEYRING] section in the configssl.cnf member. If a certificate other than the default is to be used, specify the certificate label in the configssl.cnf section [LABLCERT].
Please see: Using Certificates with your product in the CA XCOM Data Transport for z/OS - 12.0 online documentation.
Also see a sample configssl.cnf file for configuring for a keyring in the CA XCOM Data Transport for z/OS - 12.0 online documentation.
The requirement is (and has always been) that the root certificate (cassl.pem and casslkey.pem files) be the same on both partners.
Regarding a managed PKI infrastructure, the way certificate handling works today, you MUST have your certificates either
1) in local USS datasets or
2) in your security package's keyring handler.
Making calls to retrieve certificates is not a function of XCOM. Locating and loading of certificates is done by either OpenSSL or IBM's SystemSSL - depending on which you are using.
That said, there is no ability nor configuration for XCOM to use certificates in any manner other than what is currently documented.
- For CA Top Secret, see Digital Certificates in the CA Top Secret® for z/OS - 16.0 documentation
- For CA ACF2, see Digital Certificate Support in the CA ACF2™ for z/OS - 15.0 & 16.0 documentation
- For IBM RACF, see IBM's z/OS Security Server RACF Security Administrator's Guide.