Admin Alert: Renewing A Default *System Certificate
June 5, 2013 Timothy Prickett Morgan
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:
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:
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.
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.
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.