Bug 118240 - If CUPS is listening on an SSL socket, then all connections to other IPP printers are forced to SSL
Summary: If CUPS is listening on an SSL socket, then all connections to other IPP prin...
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: cups   
(Show other bugs)
Version: 3.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-03-14 09:15 UTC by Graham Leggett
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-19 19:28:58 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Graham Leggett 2004-03-14 09:15:54 UTC
Configure CUPS to support encryption, by doing the following:

- Set ServerName to the cert CN
- Set ServerCert and ServerKey for cert
- Bind by saying SSLListen

In client.conf set ServerName and Encryption Always

Set up a printer that uses the IPP protocol, or HTTP (same effect).

See that the URL printed to by CUPS is encrypted, when the printer
does not support encryption, nor has the user expressed any desire to
make a secure connection to the printer:

Device URI:

The error message given when printing is attempted is the very

"Unable to connect to IPP host: Success"

The result: printing to non-SSL IPP printers is impossible when CUPS
is configured to support SSL.

Comment 1 David Lawrence 2004-03-15 20:22:37 UTC
Changing product and version.

Comment 2 Tim Waugh 2004-05-12 17:11:59 UTC
Is 'Encryption IfRequested' any better?

Comment 3 Graham Leggett 2004-06-18 23:51:48 UTC
Encryption IfRequested leaves the option open for printing to occur
without encryption, which is against our access policy for services
that are accessible over the internet :(

Comment 4 Tim Waugh 2004-06-25 11:54:56 UTC
But you wanted printing to occur without encryption: "printing to
non-SSL IPP printers" is exactly that, surely?

I think maybe I'm not understanding the set-up you have.  Can you give
the various devices in the scenario names, so that I can see more
clearly what you mean?

Comment 5 Graham Leggett 2004-06-25 14:20:56 UTC
Client XXX --IPP+SSL--> CUPS Server --IPP--> Ricoh IPP enabled printer

The connection right now this minute client XXX is talking to the CUPS
server using IPP+SSL (Specified using Encryption Required).

The connection right now this minute CUPS server is talking to the
Ricoh printer via LPR, because this works at the moment.

The minute you try to change the protocol that CUPS uses to talk to
the Ricoh printer from LPR to IPP (non secure IPP, as the Ricoh
printer to our knowledge does not support SSL) CUPS insists on using
IPP+SSL to talk to the Ricoh printer. The Ricoh printer cannot
understand IPP+SSL, and the job never arrives on the printer.

It seems that if the IPP connection between client XXX and CUPS is SSL
enabled, CUPS wants to make the IPP connection between the CUPS server
and the Ricoh printer SSL enabled as well, even though SSL for the
connection to the printer is neither enabled in the config of CUPS,
nor supported by the Ricoh printer.

Comment 6 RHEL Product and Program Management 2007-10-19 19:28:58 UTC
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

Note You need to log in before you can comment on or make changes to this bug.