From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030922 Description of problem: - Configure cups to use SSL: In cupsd.conf: SSLListen 127.0.0.1:631 SSLListen 192.168.200.150:631 ServerCertificate /etc/cups/certs/ipp-hostCert.pem ServerKey /etc/cups/certs/ipp-hostKey.pem In client.conf: ServerName ipp Encryption Always - View the web portal via https://ipp:631, this works 100%. - Try and view print queues via lpq: [minfrin@gatekeeper minfrin]$ lpq lpq: Unable to contact server! - Look in the cups error logs: E [23/Mar/2004:18:17:27 +0200] EncryptClient: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request E [23/Mar/2004:18:17:27 +0200] Bad request line "/1.1"! Due to the vagueness of the above error (it does not include what the source IP address attempted to make the unencrypted connection above) it is not clear as to whether this error is involved or not. Nett result: CUPS can be a secure print server, but cannot be used as a secure print client. Version-Release number of selected component (if applicable): cups-1.1.17-13.3.6 How reproducible: Always Steps to Reproduce: xxx Additional info:
Some more investigation: If an strace lpq is done, the following steps are evident: - The clients.conf file is opened and read. - An attempt is made to write a _non encrypted_ request to the server defined in clients.conf, when client.conf stipulates "encryption always". - The response comes back from the server: "HTTP/1.0 400 Bad Request" - lpq alternates between two responses: [minfrin@gatekeeper minfrin]$ lpq lpq: Unable to contact server! [minfrin@gatekeeper minfrin]$ lpq no entries In the case of "unable to contact server", it seems the initial write to the server fails immediately. In the case of "no entries", it seems this is what is returned if the server says "400 Bad Request". CUPS seems to alternate between one response and the other.
This issue has been opened as STR #653 at http://www.cups.org.
Any update on this bug? This is a showstopper for RHEL being deployed as a printserver. The latest version of CUPS as supplied www.cups.org is broken out the box on RHEL: [root@gatekeeper root]# service cups start cupsd: Child exited on signal 11! cups: unable to start scheduler. So: is there any hope for a secure RHEL printserver, or is RHEL a dead loss in this application?
Direct link is: http://www.cups.org/str.php?L653 (Despite being on the CC field for it I've had no email from it. :-( )
Do you need a binary package set to test, or can you try the pseudo-patch from my comment to STR #653 yourself?
FWIW, Fedora development will shortly have cups-1.1.20-8, which includes this patch.
With cups-1.1.17-13.3.12, I'm still seeing: E [17/Aug/2004:22:43:34 -0400] EncryptClient: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request E [17/Aug/2004:22:43:34 -0400] Bad request line "1.0"! in the error log. Am I just dumb with cups configuration?
This seems to be due to STR #434: http://www.cups.org/str.php?L434 but I think it is comparatively harmless. The corresponding Red Hat Bugzilla report is bug #114999.
It seems the latest fedora development version of cups-1.1.21-1.rc1.9 has a dependancy list a mile long, including the need to upgrade python. When will this patch be made available officially to RHEL3?
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2004-228.html