• The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
Menu
  • The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
  • Admin Alert: Renewing A Default *System Certificate

    June 5, 2013 Joe Hertvik

    In an earlier column, I described how to solve problems when loading digital certificates into your IBM i Digital Certificate Manager (DCM). This week, I’ll review another DCM problem where the default certificate in the system certificate store (*SYSTEM) expires, and the system starts refusing connections from clients that use digital certificates. This week, let’s examine what happens when a *SYSTEM default certificate expires and how to renew that certificate in DCM.

    Getting The Terminology Correct

    To untangle what’s happening here, let’s first look at some terminology regarding your partition’s DCM.

    A system certificate store, designated by *SYSTEM in DCM, is the default storage file for public Certificate Authority (CA) certificates on your system. It’s where you load public CAs from companies such as RSA, Thawte, Versign, etc. Starting with OS/400 V4R4, DCM started using a key database file (.KDB) for certificate storage and you can find the system certificate store in this IFS location:

    /QIBM/USERDATA/ICSS/CERT/SERVER/DEFAULT.KDB
    

    The system certificate store KDB is password protected for changes, but the password can be easily reset from within DCM, as needed. The DCM can also contain other types of certificate stores, such as Local Certificate Authority stores (which are used for local certificate storage), but the situation we’re discussing today involves the system certificate store, *SYSTEM.

    Your system certificate store has a default certificate associated with it that has an expiration date. When outside clients are trying to access a public CA on your system, the DCM first checks the default certificate expiration date on your system certificate store. If the certificate is still valid, it passes the request on to the public CAs on your system. If the default *SYSTEM certificate has expired, the outside client request is denied.

    Note: This article uses the Digital Certificate Manager that comes with IBM i 6.1 to demonstrate how to replace an expired *SYSTEM digital certificate. If you are using another IBM i or IBM i5/OS operating system version, the screens and steps presented here may be slightly different.

    How To Know When Your Default System Certificate Is Expired

    You can determine when your default *SYSTEM certificate is expired in one of two ways:

    1. When a requesting server application or client that can normally connect to your system, starts receiving certificate expiration notices and the connection request is rejected. You may be able to find the rejection notices in a server’s log files or when a client request is rejected.

    Or . . .

    2. You can check the expiration date on your default *SYSTEM certificate. Here’s the drill for checking whether your default *SYSTEM certificate is expired.

    To check your *SYSTEM certificates, open the Digital Certificate Manager system certificate store by clicking on the Select a Certificate Store button in the left-hand pane of the DCM interface. You’ll see a Select a Certificate Store screen that looks something like this. Turn on the *SYSTEM radio button and press the Continue button.

    DCM will prompt you to open the system store key database file (.KBD) discussed above. DCM will also prompt you to enter a Certificate store password. If you don’t know the KDB file password, DCM provides an option to change the password. Click on the Reset Password button and DCM will allow you to change the .KBD file password before you go any further. Change the password, if necessary, and then enter the new password to open the *SYSTEM certificate store file.

    After signing in, you’ll see a screen that looks like this:

    The certificate labeled as the Default Certificate Label is the default certificate for your *SYSTEM certificate store (IMS 2008, in this case).

    Checking The *SYSTEM Expiration Date

    To check the default certificate’s expiration date, click on the radio button in front of the default certificate and click on the View button. A screen will appear showing you the certificate information. Page down to the second screen and look at the information in the “Additional Information” area. It will look something like this.

    The validity period in the Additional Information area contains the dates that the certificate is valid. In this case, the certificate will expire on July 17, 2013. You’ll also want to note the Key Length in the Private Key Information area, as you’ll need that information when you go to renew the certificate.

    Extend The Certificate Expiration Date

    If you want to extend the validity period expiration date for your system store default certificate, go back to the Work with Server and Client Certificates for the *SYSTEM store, click on your default certificate radio button and select the Renew button. The DCM will ask you whether the Local Certificate Authority (CA) or Verisign or other Internet Certificate Authority (CA) will sign the certificate. For this example, let’s assume the Local Certificate Authority will be signing the certificate. DCM will show a Renew Certificate screen that copies all the information from the expiring certificate into a new certificate, except for the following fields which you will have to enter for the new certificate:

    • New certificate label–You need to specify a new label for the renewed certificate.
    • Key size–By default, DCM selects 1024 bits as the key size for this *SYSTEM store certificate. Change this value to the Key length value you retrieved when viewing the certificate.

    I’ve found that these two fields are the only items to enter when renewing a certificate. Click on the Continue button when you’re ready to renew the certificate. DCM will then create a new certificate with your new name. The new certificate will contain the exact same information as the old certificate.

    At this point, you’ve created a replacement certificate for your system certificate store default certificate. But you still need to do two things to replace your expiring certificate with the new certificate: 1) Designate the new certificate as the default *SYSTEM certificate; and 2) Assign the new certificate to be used for any IBM i applications that used the old certificate. Here’s how to accomplish these tasks.

    Step 1: Designate the new certificate as the default *SYSTEM certificate.

    Go back to the Work with Server and Client Certificates screen for the *SYSTEM certificate store. Click the radio button for your new certificate and select the Set Default button. This will change the default certificate for the *SYSTEM store to the new certificate you created.

    Step 2: Assign the new certificate to be used for any IBM i applications that used the expiring certificate.

    The last step is to find all the client applications that are still assigned to the old certificate for client authentication. You’ll need to change their authentication assignment to the new certificate. To do this, go back again to the Work with Server and Client Certificates screen for the *SYSTEM certificate store. Click the radio button for your new default certificate and then click on the Assign to Applications button. You’ll see a screen that looks something like this.

    Place a check mark next to any application that is assigned to the old certificate under the Assigned Certificate column. Once you’ve tagged all the applications that use the old certificate, go to the bottom of the screen and click on the Continue button. This will change the default certificate for the selected application to your new certificate.

    At this point, your applications should once again be able to connect to the *SYSTEM certificate and start working again.

    The 1, 2, 3s Of Replacing Your Default *SYSTEM Certificate

    Once you understand the mechanics, you can replace an expiring *SYSTEM default certificate by doing these three steps that I just outlined above.

    1. Renew your expiring or expired *SYSTEM default certificate by creating a duplicate certificate with a different certificate label.
    2. Set the new certificate as the default *SYSTEM certificate.
    3. Change any client applications that used the expired certificate for authentication to instead use the new certificate.

    And that’s how you swap out an expired *SYSTEM default certificate and keep your application working.

    Follow Me On My Blog, On Twitter, And On LinkedIn

    Check out my blog at joehertvik.com, where I focus on computer administration and news (especially IBM i); vendor, marketing, and tech writing news and materials; and whatever else I come across.

    You can also follow me on Twitter @JoeHertvik and on LinkedIn.

    Joe Hertvik is the owner of Hertvik Business Services, a service company that provides written marketing content and presentation services for the computer industry, including white papers, case studies, and other marketing material. Email Joe for a free quote for any upcoming projects. He also runs a data center for two companies outside Chicago. Joe is a contributing editor for IT Jungle and has written the Admin Alert column since 2002.

    RELATED STORY

    How Do I Load This Digital Certificate On My IBM i Machine?



                         Post this story to del.icio.us
                   Post this story to Digg
        Post this story to Slashdot

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Tags:

    Sponsored by
    Raz-Lee Security

    Protect Your IBM i and/or AIX Servers with a Free Virus Scan

    Cyber threats are a reality for every platform, including IBM i and AIX servers. No system is immune, and the best defense is prompt detection and removal of viruses to prevent costly damage. Regulatory standards across industries mandate antivirus protection – ensure your systems are compliant and secure.

    Get My Free Virus Scan

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Sponsored Links

    Profound Logic Software:  Live Webinar: How to Take IBM i Everywhere with Mobile Apps. June 26
    BCD:  Reduce the IT reporting blues with Monarch for EZ-Pickin's
    RJS Software Systems:  Replace unsupported legacy forms or upgrade to iForms.

    More IT Jungle Resources:

    System i PTF Guide: Weekly PTF Updates
    IBM i Events Calendar: National Conferences, Local Events, and Webinars
    Breaking News: News Hot Off The Press
    TPM @ The Reg: More News From ITJ EIC Timothy Prickett Morgan

    TMW Delivers Web Interface for IBM i Trucking App IBM Rolls Out PureFlex-IBM i Bundle With Decent Discounts

    Leave a Reply Cancel reply

Volume 13, Number 11 -- June 5, 2013
THIS ISSUE SPONSORED BY:

ProData Computer Services
WorksRight Software
System i Developer

Table of Contents

  • When Is A Source Member Not A Source Member?
  • Conditional SQL I/O
  • Admin Alert: Renewing A Default *System Certificate

Content archive

  • The Four Hundred
  • Four Hundred Stuff
  • Four Hundred Guru

Recent Posts

  • POWERUp 2025 –Your Source For IBM i 7.6 Information
  • Maxava Consulting Services Does More Than HA/DR Project Management – A Lot More
  • Guru: Creating An SQL Stored Procedure That Returns A Result Set
  • As I See It: At Any Cost
  • IBM i PTF Guide, Volume 27, Number 19
  • IBM Unveils Manzan, A New Open Source Event Monitor For IBM i
  • Say Goodbye To Downtime: Update Your Database Without Taking Your Business Offline
  • i-Rays Brings Observability To IBM i Performance Problems
  • Another Non-TR “Technology Refresh” Happens With IBM i TR6
  • IBM i PTF Guide, Volume 27, Number 18

Subscribe

To get news from IT Jungle sent to your inbox every week, subscribe to our newsletter.

Pages

  • About Us
  • Contact
  • Contributors
  • Four Hundred Monitor
  • IBM i PTF Guide
  • Media Kit
  • Subscribe

Search

Copyright © 2025 IT Jungle