How can I replace an expiring or expired user digital certificate signed by a third party CERTAUTH, keeping same key pair.

Document ID : KB000026820
Last Modified Date : 14/02/2018
Show Technical Document Details


The process to replace or update an expiring certificate differs slightly depending on whether the certificate is self-signed, signed by a CA, or is a third-party CERTAUTH.

The following process documents the replacement of an expiring user certificate that has been signed by a third-party CERTAUTH such as Verisign, or by a company CERTAUTH that is not maintained locally (a CHKCERT of the CERTAUTH on the keyring does not show a private key).

These expiring certificates have to be sent off to the Certifying Authority to be renewed. In this process the original public/private key pair is retained.


Example: Replace expiring/expired user certificate signed by a generally recognized CA, keeping the same public/private key pair:


  1. CHKCERT the user certificate you want to renew. Save for future reference.

  2. EXPORT the user certificate to a dataset to save it---just in case.

    1. If the private key is non-ICSF, use PKCS#12 format to save the certificate and its public/private key pair.

    2. If the private key is ICSF, consider using the IBM freeware utility called KEYXFER to backup the private key in conjunction with a non-PKCS#12 format (CERTDER) to backup the certificate and public key.

  3. Issue a GENREQ against the existing CERTDATA record for the expiring/expired certificate. Output will contain the Subject DN and the public key. You will get an ACF68068 message indicating the certificate request has been placed in the designated dataset.

  4. Send the output to the CA site to be renewed (get new 'not valid after' date).

  5. When it is returned, issue CHKCERT against the dataset to verify the new certificate looks valid (Has the 'not valid after' date been extended? How does the output compare to the initial CHKCERT output?)

  6. INSERT the renewed certificate from the dataset, replacing the existing CERTDATA record.

  7. Issue CHKCERT against the CERTDATA record to verify the replacement certificate looks like the output of the original CHKCERT---except that the 'not valid after' date has been extended. There should be a private key. It should have TRUST.



  10. Bounce any address spaces that reference the keyrings to which a replaced certificate is connected.

ACF Commands

  1. CHKCERT userid.cert1

  2. EXPORT userid.cert1 DSN('saved.userid.cert1') FORMAT(PKCS12DER) PASSWORD(pkcs12 password)

  3. GENREQ userid.cert1 DSN('userid.cert1.req')

  4. - send to Certification Authority -

  5. CHKCERT DSN('renewed.userid.cert1')

  6. SET PROFILE(USER) DIV(CERTDATA) INSERT userid.cert1 DSN('renewed.userid.cert1') TRUST

  7. CHKCERT userid.cert1