How can SKI and AKI for digital certificates be compared in ACF2
search cancel

How can SKI and AKI for digital certificates be compared in ACF2

book

Article ID: 234177

calendar_today

Updated On:

Products

ACF2 - z/OS ACF2 ACF2 - MISC

Issue/Introduction

The previous and new version of an Intermediate certificate have identical IDN (Issuer DN) and SDN (Subject DN) information.
How can the SKI and AKI for these certificates be compared to prove that they are different and okay to be in the same keyring without causing any concerns?

Environment

Release : 16.0

Component : ACF2 for z/OS

Resolution

The AKI Extension (Authority Key Identifier) and SKI extension (Subject Key Identifier) are not displayed on a list of the certificate under the ACF command or in the output from a chkcert comand.
However, they can be seen in the output from report SAFCRRPT using the "detail ext" parameters. 

For example:

//SAFRPTCR EXEC PGM=SAFCRRPT,REGION=64M  
//SYSUDUMP DD SYSOUT=*                   
//SYSPRINT DD SYSOUT=*                   
//SYSIN DD *                             
RECORDID(certauth.-) detail ext         
//   

the output display the following in information from each certificate listed.

           
X509v3 Subject Key Identifier                         
    088201F123456F6CB9A25F15B68367C2 *.......<.._...g.*
    6475F689                         *du..            *
 X509v3 Authority Key Identifier                       
   F2C987618F1F8528A24234516F24E2CE *.......(.G.Qo$..*
   8C61BA07                         *.a..            *

If the two certificates have identical SKI and AKI then they may be seen as identical. Both (either) of the certificates that can be considered to be the signer of a certificate in question. This can cause confusion not only with ACF2's internal utilities, but with other programs that issue the r_datalib call and now have multiple potential signing certificates that were passed back. 

For example, the SAFCRRPT report stops at the first signing certificate in alphabetical order of the record name in ACF2. This may not be the desired signer if the desired signing certificate record name falls later in the alphabet. The best practice is to always remove unwanted/expired certificates from the database if replacing them.