If you see fewer posts. . .

it's because I don't post much anymore. This may change at any time. But PLEASE feel free to look through our Flickr stream (over on the right), which is updated almost every day.

Tuesday, March 27, 2007

June 07 i5
Tips and Techniques
Version: Ready for Morgon Mae

HEAD: Encrypted Printing via Internet Printing Protocol (IPP)
BYLINE: By Kurt Schroeder

IBM* System i* customers who need to comply with government regulations from HIPAA, Sarbanes-Oxley or the Gramm-Leach-Bliley Act may be faced with a chink in their System i armor. Spooled files, unless sent over a secure VPN connection, are sent in a clear text format that can be read by anyone using a sniffer or other packet-analysis software. Recent discoveries have led to a working Internet printing protocol (IPP) solution, and with the right hardware and the proper configuration, it can work for you.

Be on V5R2 or later with current PTFs V5R2 of IBM OS/400* introduced the IPP driver that allows for a direct connection to an IPP-capable printer. Ensure that you are on R520 or later and have applied the latest IPP PTFs. These can be found in Software Knowledge Base (www-912.ibm.com/s_dir/slkbase.nsf/slkbase) document 23383453: V5Rx PTF Listing for TCP/IP and LAN printing.

Get the Right Printer
The printer you choose is important. As with non-secure IPP communications, your printer must support chunking. Chunking is required by the HTTP/1.1 protocol that governs IPP, but many printers made for Microsoft* Windows* don't support it. OS/400 chunks transformed data as soon as it becomes available, so this support is critical. Microcode updates to enable chunking support may be available from your hardware vendor. For example, a microcode update to enable chunking support for the IBM 15xx series of printers is available from IBM printing systems.

The printer must also be capable of importing or creating a digital certificate, as they play a key role in secure IPP printing. Currently, no printers are known to support the recommended method of secure connection described in RFC2910: Internet Printing Protocol/1.1: Encoding and Transport, which is via an upgrade to transport layer security. (RFCs can be accessed at www.ietf.org.) The only known print servers to support this method are the iSeries* IPP Server, and the common UNIX* printing system. The method described in this article uses digital certificates instead.

Find Digital Certificates on the Printer
Your printer must support the importation of a signed digital certificate from a third party, or the creation and exportation of its own self-signed digital certificate. Both are equally secure, and both methods have been tested to work on System i architecture. The certificate installed on the printer must be exported and imported into the System i platform, so that the server (the printer) and the client (the System i platform) have matching certificates.

The following instructions match the screens one is likely to find on the Infoprint 15xx series of printers, and may differ greatly from your printer. Any questions regarding how a given printer manages digital certificates should be directed to the printer manufacturer.

1. Connect to the printer via Web browser.

2. Set the correct time and date on the printer.

3. Navigate to the certificate management function. On the Infoprint 1552, this is listed under Links and Index>Certificate Management.

4. Install a new self-signed certificate. I did this by clicking on “Generate a New Private Key” and then, after that had processed, clicking on “Update The Certificate Signing Request.” The reason I had to create a new certificate was that the default certificate expired in 1972.

5. Export the certificate. My printer's certificate management interface had an option to download the current certificate, and it was saved to my PC as SystemCert.pem. When displayed, the file will look something like this:


6. FTP the certificate in ASCII mode to an IFS file location. I chose to send it to my home directory of /home/kschroe/SystemCert.pem.

System i Digital Certificates
Once the digital certificate is exported from the printer and copied to an IFS file location, it needs to be imported into the System i Digital Certificate Manager (DCM).

1. Connect to your System i Tasks page by typing the system name or IP address, followed by port 2001, into your Web browser. For example, http://system_name:2001.

2. Click on Digital Certificate Manager, which will take you to the DCM Administration screen.

3. Click on Select a Certificate Store, and choose the *SYSTEM store. Click continue.

4. If you’re asked to provide the Certificate Store password, try typing “default”. If this doesn’t work, troubleshooting information for passwords and general problems is available on the iSeries Information Center (http://publib.boulder.ibm.com/iseries/).

5. After accessing the Certificate Store, click on Fast Path and choose the option to Work with CA certificates.

6. You’ll be presented with a listing of your currently installed certificates. It’s not uncommon to see several certificates already installed, including ones from Equifax, Microsoft, thawte and VeriSign. Scroll down to the bottom and click on Import.

7. The Import Dialog box will prompt you to enter the IFS location of the certificate. Enter it without quotes and click Enter.

8. You’ll be asked to provide a certificate label. You may want to use the name of your intended printer device to facilitate certificate management.

9. If the certificate is accepted, you’ll get a message that it was imported successfully, and it will show on the top of the CA Certificate list. At this point, you can configure your IPP printer device. If the certificate was not accepted, you may want to double-check the validity date of the certificate on the printer or make sure the file was transferred in an ASCII format.

Configure the Printer Device
Typically, an IPP Device Description is configured with a port number of 631, and a remote location name of http://ip-address:631/. This can slightly differ based on printer model, and a list of recommended configurations is always kept updated in the Software Knowledge Base document 27285056: Recommended Remote Location (RMTLOCNAME) Values for *LAN 3812 IPP Device Descriptions. However, the addressing scheme that works with non-secure IPP will not work for a secure IPP connection.

For a secure IPP connection, the port should be set to 443, as this is the well-known HTTPS port. In our testing and during discussions with the IPP developers, we discovered that the IPP driver will assume a secure SSL connection if the remote location name starts with https. Because the secure connection is assumed, the SECURECNN parameter is ignored, and can be left at *NO. The command string I used to create my device is similar to this:


Once the device has been configured, vary it on and start the writer.

The IPP developers incorporated an IPP trace into their code, which can be used to diagnose IPP connection and handshaking issues. To turn on this trace, set the user-defined options (USRDFNOPT) parameter in the device description to USRDFNOPT(*IBMDEBUG *IBMHEX). For IPP failures, you will want to collect an IPP trace and a communications trace concurrently. The two traces will show a clear picture of most issues.

On a side note, any communications traces taken for a secure IPP printer will only be good for diagnosing initial connection and performance issues as the data itself is encrypted. If you find an incorrect output issue, you’ll need to disable the encryption so that the data stream itself can be analyzed. It’s not possible to decrypt data in order to analyze it for output problems.

Kurt Schroeder works as a software engineer at IBM in Rochester, Minn. and would enjoy hearing from those who try this printing method. Kurt can be reached at kschroe@us.ibm.com.


Kurt Schroeder 6/06/2007 04:43:00 PM  

This article was published and I received an e-mail from the regional manager of a printing company thanking me for writing the article.