Your journey to secure IPP printing begins with a digital certificate. Mine, on the other hand, began with a phone call. For almost nine years, I've worked as a printing specialist in the iSeries Support Center, and I've loved every minute of it. Educated to be an English teacher, I wound up at IBM supporting printers. And when a customer calls, the teacher in me kicks in. Guiding my students through to a resolution, I try to educate them along the way, often asking questions to make sure they follow the logic of what we are doing. In this way, we reach the solution to the problem together, and they go away better able to help themselves next time. The only part of my job that I dislike is saying "no." Whenever a customer runs up against a wall, I try to find a solution or alternate resolution to get them going. Usually, we can come up with something, but when I have to tell the customer something is impossible, I feel like I've failed.

Now, I have said "no" to secure printing for the last time. I met my match when I got a phone call from Gary Barnett at Arkansas Data Services (ADS).

ADS had recently purchased an IBM 1532 and wanted to print via Internet Printing Protocol (IPP). ADS has an ASP offering for its DOCS/400 medical practice management application. ADS customers use their personal computers and printers at their clinics, but they access the DOCS/400 application on the iSeries located at the ADS office. When ADS wanted to move its application to browser-based from green-screen, there was a need for secure remote printing. The HIPAA medical industry standards dictate that all data transmissions be encrypted because of confidential patient data. With the green-screen mode, secure printing can be accomplished with the SSL support in iSeries Access, but when ADS wanted to move to browser screens, they needed another simple way to send secure AS/400 print to the users' remote LAN printers, and Gary called me to find out about IPP.

In the wild world of iSeries print, IPP is its own animal. Typically, a laser printer is set up as a remote output queue or a PJL/SNMP device description. If the print job fails, a communications trace or joblog will show that it is either configured incorrectly or the printer doesn't support the desired protocol. There is almost always a way to get the printer working. But with an IPP device description, it's just not that easy. While the printer may support the initial IPP connection, it may not support the subsequent requests or the method in which the data is transmitted. But Gary was determined to get encrypted IPP working. In the end, I believe we did much more than get encrypted print data flowing to his printer. When we were done, we had transcended the defined IPP protocol and arrived at an elegant solution that can now be implemented by anyone with a need to print encrypted data and the luck to own the right printer.

The Dawn of iSeries IPP Support

When IPP was first announced at V5R1, Internet printing seemed very promising. The initial role of IPP on the iSeries was as a server, to allow clients to print to iSeries-attached printers through the Internet. Though I initially believed that many customers would call to get help implementing IPP, I was wrong. As with most products, the low call volumes could be attributed to ease of use or unpopularity. Though most likely the latter, the IPP server is easy to implement and could replace NetServer printing for many customers. (Perhaps that would be a good topic for another article.)

At V5R2, iSeries IPP support was enhanced to allow the iSeries to act as an IPP client and to print to IPP-capable printers. To do this, you need to make sure you have the latest IPP PTFs. These can be found in the Software Knowledge Base document 23383453: V5Rx PTF Listing for TCP/IP and LAN printing. After Gary said that he needed to set up an IPP printer, I made sure he had the latest PTFs applied and led him through the initial configuration, which failed. That didn't surprise me.

Chunking Leads to Clunking

While many customers with IPP-capable printers are able to get them to work, some fail to find a working solution. The reason for this is that many IPP-capable printers do not support IPP "chunking," even though RFC 2068: HTTP/1.1 states, "All HTTP/1.1 applications must be able to receive and decode the 'chunked' transfer-coding, and must ignore chunk-extension extensions they do not understand." Instead, many printers require that a byte-count of the expected data stream be sent in the initial IPP connection. This lack of chunking support may be due to the fact that most printers are made for the Microsoft Windows environment, which transforms print data completely before it is sent to the printer.

To improve speed and efficiency on the iSeries, as Host Print Transform converts a spooled file into the printer's required data stream, transformed portions are sent to the printer as they become available to the writer. Because we do not know how large the fully transformed spooled file will be, IPP servers (in this case, actual printers) that do not support chunking will fail to work on the iSeries. Usually, a printer that does not support the chunking transfer-coding will fail with the message CPD6F83 ("Could not establish Internet Print Protocol (IPP) communications with device") with a reason code of 2. This reason code means that the device didn't understand the IPP request.

If your printer does not provide chunking support, you need to contact the printer vendor and seek a firmware or microcode fix. Gary was able to get a microcode fix from IBM Boulder for his Infoprint 1532, and we were advised that the same patch could be applied to my 1552, as well as any other monochrome printer in the Infoprint 15xx series.

Once we had Gary's printer patched to enable IPP chunking, the configuration worked flawlessly, and I thought we were done. That was when he told me that he wanted to use the secure IPP connection provided by the SECURECNN parameter on the device configuration. I told him that we knew of no known printer that supported that option but that a couple of servers did: the iSeries IPP server and the UNIX Common UNIX Printing Solution (CUPS) server. My idea was that he could place a Linux server in each location and print through CUPS to his printers, but Gary didn't share my enthusiasm for that solution. It was cost-prohibitive and bulky. I agreed, but I didn't know what else to do. Here's why:

When the IPP driver was programmed, the iSeries developers chose to follow the guidelines of RFC 2910 - Internet Printing Protocol/1.1: Encoding and Transport, which describes the recommended method of secure IPP printing via an upgrade to TLS/SSL:

8.1.2 Transport Layer Security (TLS) IPP Printers should support Transport Layer Security (TLS) [RFC2246] for Server Authentication and Operation Privacy. IPP Printers may also support TLS for Client Authentication. If an IPP Printer supports TLS, it must support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246 [RFC2246]. All other cipher suites are optional. An IPP Printer may support Basic Authentication (described in HTTP/1.1 [RFC2617]) for Client Authentication if the channel is secure. TLS with the above mandated cipher suite can provide such a secure channel.

The iSeries IPP developers decided to follow the suggested secure upgrade method (TLS), as it seemed to be the one that the printer vendors would standardize on. In reality, we know of no printer vendors that did, and we were left with a secure connection that worked to other iSeries machines and CUPS, whose developers also chose to implement TLS, but not directly to a real printer. Traces taken to IPP-configured printers with the SECURECNN parameter set to *YES would inevitably fail with the message CPD6F84: "Could not establish secure connection with device." Up until now, each customer that had contacted me about secure IPP printing received the same answer: "It won't work."

In all honesty, if IBM's developers did choose to program to a non-standard IPP implementation—say, one favored by Hewlett-Packard or Microsoft—it could look like favoritism. And programming to a non-standard protocol means that we would have to adapt to any changes in that protocol and be subject to the whims of other programmers. It also would go against the ways we have chosen to support other printing protocols, such as LPR and PJL, where we stick to the standards and expect printer vendors to do the same.

Still, Gary was dissatisfied with my response, and he made a good point to back up his case. He pointed out that the help text for the SECURECNN parameter in the CRTDEVPRT command says, "Specifies whether a secure connection is established with the printer" and asked why the word "printer" was used if it had never actually worked to a real printer. He had us there. I contacted my developers and relayed Gary's concerns. They gave me the well-known story about lack of printer support for the recommended TLS/SSL upgrade method, which I knew already. Lucky for us, that developer shared the problem with a co-worker over lunch. That ingenious fellow suggested that, even though the IPP specification refers only to port 631, perhaps the printer manufacturers allowed secure IPP traffic over port 443, the default HTTPS port.

After hearing this, I quickly reconfigured my own printer device to use that port and address (https://9.10.11.12:443/) and traced the driver. It failed again, but this time I got a new message, CPD6F84: "Secure connection failed-6000-Certificate is not signed by a trusted certificate authority." It did not complain that the upgrade to TLS/SSL had failed, as I had bypassed that requirement. This was the first time I had seen a digital certificate error on the iSeries. I knew what they were but hadn't thought of them as having anything to do with print.

My Infoprint 1552 was IPP-capable, so I accessed the printer via its secure HTTPS URL. It prompted me to accept a digital certificate, which I did. Then, I could see the online configuration. The Links and Index>Certificate Management menu showed the available options, including Generate a New Private Key and Update The Certificate Signing Request. After talking to a digital certificate expert in our support center, I decided to download a trial certificate from Verisign and load it into the printer. Then, I exported the certificate from the printer and loaded it into the iSeries Digital Certificate Manager (DCM). The next time I sent a spooled file to the printer, it printed. That was the first successful test of secure IPP.

I decided to test out the printer's capability to generate its own self-signed certificate. After a cold reset and a reload of the microcode, I tried to export the digital certificate and load it into the iSeries. The process worked, but the printer writer failed because the shipped digital certificate had expired in 1972. I set the correct date and time on the printer and clicked Generate a New Private Key, followed by Update the Certificate Signing Request. This time, the certificate I imported into DCM worked fine, and my spooled file printed successfully. That proved that we could offer a complete solution to customers, without having to recommend third-party digital certificate providers. This is important because, although some customers may choose to purchase certificates from a third party, self-signed ones are free and equally secure.

I contacted Gary and led him though the steps to create and export a self-signed certificate into DCM and reconfigure his printer device description. It worked the first time, and Gary had a solution.

Making Secure IPP Work for You

System i customers that need to comply with regulations from HIPAA, Sarbanes-Oxley, or the Gramm-Leach-Bliley Act may find secure IPP printing to be a useful and important tool for data transmission. If you want to take advantage of secure IPP, follow these simple steps:

Make sure you are at V5R2 or higher and have the latest IPP PTFs applied.

Ensure that the printer you choose is IPP-capable, supports chunking, and can export its digital certificate. On my 1532 and Gary's 1352, the certificate was exported as SystemCert.pem and then FTPed in ASCII mode to the IFS. The certificate, when displayed, will resemble the following:

-----BEGIN CERTIFICATE-----
A large, incomprehensible chunk of data
A large, incomprehensible chunk of data
A large, incomprehensible chunk of data
-----END CERTIFICATE-----

Import the certificate into DCM. This will be done via the System i Tasks page located at http://systemname:2001. You will open the DCM, click on Select a Certificate Store, and choose the *SYSTEM store. If you are prompted for a password, type default. Troubleshooting information for these types of problems is on the iSeries Information Center. Once you are in the Certificate Store, find the option to Work with CA Certificates and click on the Import button. Enter the IFS location of the certificate and provide a certificate label. The successfully imported certificate will appear at the top of the list of installed certificates.

Configure your IPP device description. Set the port number to 443 and the remote location name to https://printeraddress:443/. Interestingly enough, our testing showed that the SECURECNN parameter is ignored when the well-known HTTPS port 443 is specified. Vary the device on and start the writer.

Troubleshooting

If the configuration fails, troubleshoot it. Change the User Defined Options (USRDFTOPT) parameter on the device description to *IBMDEBUG *IBMHEX and recreate the problem. This will generate a trace that shows the IPP driver messages. You should also take a concurrent communications trace and gather the joblog for complete problem diagnosis. Finally, it is worth noting that any problem with printer output cannot be diagnosed over a secure connection, because the data sent to the printer is encrypted, making it unreadable!

Kurt Schroeder works as a System i printing specialist at IBM in Rochester, Minnesota, but the views expressed in this article are his own, not necessarily those of IBM. He can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it. and would appreciate feedback on this article, which can be provided directly via email or through the forums discussion associated with this article.

Also Read

Partner TechTip: End the Scourge of Ugly Forms!

Partner TechTip: The Pursuit of a Paperless Process

It's Just Another Day, But Do You Know What Your Reports Are Doing?