A virtual keyring allows System SSL to automatically check all CERTAUTH or SITECERT certificates in an ESM keystore when verifying a certificate that was received during the SSL handshake. A virtual keyring can be used by FTP/TLS by specifying:
KEYRING *AUTH*/*
or
KEYRING *SITE*/*
Release: 16.0
ACF2 supports virtual Keyrings. With Virtual Keyrings all CERTAUTH certificates (ie CERTAUTH.suffix) will be returned with the KEYRING from the R_datalib calls. When referencing the virtual Keyring the application/server's parameter file should specify *AUTH*/* or *SITE*/* to point to the CERTAUTH or SITE virtual Keyring. With Virtual Keyrings all valid (not expired) CERTAUTH/SITECERT certificates (i.e. CERTAUTH.suffix or SITECERT.suffix) will be returned with the KEYRING from the R_datalib calls.
Details on Keyrings can be found in the CA ACF2 for z/OS documentation in section 'KEYRING User Profile Records'.
Note: it is not necessary to create a physical keyring in the ACF2 database.
ACF2 Virtual Keyring Authorization
There are two ways of authority checking for the R_datalib callable service:
- global profile checking in the FACILITY class.
- ring-specific profile checking in the RDATALIB class.
With Global profile checking a resource with the format IRR.DIGTCERT.<function> is used. For the Keyring owner READ authority is required to the Resource class FACILITY resource: IRR.DIGTCERT.LISTRING. For other's Keyring UPDATE authority is required to the Resource class FACILITY resource: IRR.DIGTCERT.LISTRING.
For example:
$KEY(IRR.DIGTCERT.LISTRING) TYPE(FAC)
UID(serverUID) SERVICE(READ) ALLOW <-gives access to Owner
UID(serverUID) SERVICE(UPDATE) ALLOW <-gives access to Other's
With ring-specific profile checking, a resource with the format <ringOwner>.<ringName>.LST is used to provide access control to a specific Keyring on R_datalib READ functions, that are, DataGetFirst, DataGetNext, and GetUpdateCode. For virtual keyrings the ring owner user IDs for the certificates under CERTAUTH and SITE are in the form of *AUTH* and *SITE*. READ authority to Resource class FACILITY resource: SITECERT.IRR_VIRTUAL_KEYRING.LST for SITECERT or CERTAUTH.IRR_VIRTUAL_KEYRING.LST for CERTAUTH.
For example:
$KEY(SITECERT.IRR_VIRTUAL_KEYRING.LST) TYPE(RDA)
UID(serverUID) SERVICE(READ) ALLOW
$KEY(CERTAUTH.IRR_VIRTUAL_KEYRING.LST) TYPE(RDA)
UID(serverUID) SERVICE(READ) ALLOW
Note: If a certauth certificate with a PRIVATE KEY is in the ACF2 database it will be validated for DELETE authority against CERTAUTH.IRR_VIRTUAL_KEYRING.LST instead of READ authority due to the power of having a private key.