RDATALIB CERTAUTH.IRR_VIRTUAL_KEYRING.LST Control Access Violation in Top Secret

Products

• Top Secret

Issue/Introduction

Noticing a number of violations requiring access "Control" to the "RDATALIB  CERTAUTH.IRR_VIRTUAL_KEYRING.LST " resource.    The jobs do not fail and everything seems to be working as it should.  It appears the  job is trying to access the private key.  How can I determine which certificate in CERTAUTH the ACID is looking to retrieve the private key?

Here are examples from the violation report:

  DATE     TIME   SYSI ACCESSOR JOBNAME  FFM VC PROGRAM  R-ACCESS A-ACCESS SRC/DRC SEC RESOURCE (TYPE & NAME)       
-------- -------- ---- -------- -------- --- -- -------- -------- -------- ------- --- ---------------------------- 

04/16/23  22:33:51  SYS1  CICS1    SYS13A6  STC       FAIL  01  BPXPTATT  K        UPDATE    *08*-97       S790200  
                    RESOURCE  TYPE & NAME :   RDATALIB  CERTAUTH.IRR_VIRTUAL_KEYRING.LST                              
04/16/23  22:33:51  SYS1  CICS2    SYS23A6  STC       FAIL  02  BPXPTATT  K        UPDATE    *08*-97       S790200  
                    RESOURCE  TYPE & NAME :   RDATALIB  CERTAUTH.IRR_VIRTUAL_KEYRING.LST             

 

Environment

Release : 16.0

Resolution

This error will occur when using a Virtual keyring and one or more of the Certificates on the Virtual Keyring has a private key.  In this case the virtual keyring is CERTAUTH.  Every certificate owned by Certauth is read: just like every certificate on a keyring is read.  If a Certauth certificate has a private key it will check for a permit for RDATALIB(CERTAUTH.IRR_VIRTUAL_KEYRING.LST) with ACCESS(CONTROL).  If it does not find the authority/permit it will not present the private key and the error will occur.  The error doesn't cause a problem because the user doesn't have a need for the private key.

The error messages can be ignored.  The only way to get rid of them would be to give the permit for RDATALIB(CERTAUTH.IRR_VIRTUAL_KEYRING.LST) ACCESS(CONTROL).