CUPS tries to auto-generate SSL key, fails

[Forest Bond]

Binary package hint: cupsys

Accessing the administrative interface causes cups to appropriately try and generate an SSL key (cupsd insists on using https). Unfortunately, it seems to lock up when doing this. On the other hand, if I generate the key manually, the adminstrative interface is happy to service me over https.

[Ante Karamatić (ivoks)]

Can you be more specific about "insisting"? If I open http://localhost:631/admin, I can use everything without going over SSL. So, it doesn't force use of HTTS.

But, if I use https://localhost:631, CUPS doesn't respond. Logs show:

Unable to create server key file "/etc/cups/ssl/server.key" - No such file or directory

OK. Solution is to create /etc/cups/ssl directory with cupsys:lp as owner:group.

[Patrice Vetsel (vetsel-patrice)]

Please read /usr/share/doc/cupsys/README.Debian.gz

"...Therefore, the cupsys packages as shipped do not support ssl..."

Thank you for your report.

[Walter Tautz (wtautz)]

Ante Karamatić wrote:

>Can you be more specific about "insisting"? If I open
>http://localhost:631/admin, I can use everything without going over SSL.
>So, it doesn't force use of HTTS.
>
>But, if I use https://localhost:631, CUPS doesn't respond. Logs show:
>
>Unable to create server key file "/etc/cups/ssl/server.key" - No such
>file or directory
>
>OK. Solution is to create /etc/cups/ssl directory with cupsys:lp as
>owner:group.
>
>** Changed in: cupsys (Ubuntu)
> Status: Unconfirmed => Confirmed
>
>
>
Even when one starts at localhost:631 and attempts to add a printer
the final step insists that one access :443 port. After adding /etc/cups/ssl
one still doesn't get a lot of success as key generation seems to take
forever. To the point that I just used command line openssl command
to generate a key. I do recall that in a previous test I waited a few
hours and it eventually appeared, however, this is clearly unsatisfactory
behaviour.

[Ante Karamatić (ivoks)]

As VETSEL said, CUPS shipped in Debian/Ubuntu doesn't support SSL due licensing issues.

[Forest Bond (forest-bond)]

> >Can you be more specific about "insisting"? If I open
> >http://localhost:631/admin, I can use everything without going over SSL.
> >So, it doesn't force use of HTTS.

> Even when one starts at localhost:631 and attempts to add a printer
> the final step insists that one access :443 port. After adding /etc/cups/ssl
> one still doesn't get a lot of success as key generation seems to take
> forever. To the point that I just used command line openssl command
> to generate a key. I do recall that in a previous test I waited a few
> hours and it eventually appeared, however, this is clearly unsatisfactory
> behaviour.

As far as I can tell, this has, in fact, been resolved. Cups no longer requires
HTTPS to change administrative settings on my machine, up-to-date as of
2006-06-05. Note that this was previously not the case (about 3 weeks? ago,
when this bug was originally filed).

-Forest

[Walter Tautz (wtautz)]

Ante Karamatić wrote:

>As VETSEL said, CUPS shipped in Debian/Ubuntu doesn't support SSL due
>licensing issues.
>
>
>
Not if you compile against libgnutls? which seems to be the case
in this package. So encryption *is* supported so long as compilation
against libgnutls is done which I believe is the case: What you guys
need to do is create /etc/cups/ssl at install time and warn the users
that they need to create a key via the command line openssl tool
which works (I've done this).

On dapper:

# ldd /usr/sbin/cupsd
        linux-gate.so.1 => (0xffffe000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7fab000)

        libgnutls.so.12 => /usr/lib/libgnutls.so.12 (0xb7f42000)

        libslp.so.1 => /usr/lib/libslp.so.1 (0xb7f32000)
        libldap_r.so.2 => /usr/lib/libldap_r.so.2 (0xb7efe000)
        libpam.so.0 => /lib/libpam.so.0 (0xb7ef6000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7ef3000)
        libpaper.so.1 => /usr/lib/libpaper.so.1 (0xb7ef0000)
        libcups.so.2 => /usr/lib/libcups.so.2 (0xb7ec3000)
        libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7eb0000)
        libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7e83000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d54000)
        libtasn1.so.2 => /usr/lib/libtasn1.so.2 (0xb7d44000)
        libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb7cf8000)
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xb7cf4000)
        libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb7cde000)
        libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb7ccb000)
        liblber.so.2 => /usr/lib/liblber.so.2 (0xb7cbf000)
        libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xb7cab000)
        /lib/ld-linux.so.2 (0xb7fc6000)

[Walter Tautz (wtautz)]

Forest Bond wrote:

>>>Can you be more specific about "insisting"? If I open
>>>http://localhost:631/admin, I can use everything without going over SSL.
>>>So, it doesn't force use of HTTS.
>>>
>>>
>
>
>
>>Even when one starts at localhost:631 and attempts to add a printer
>>the final step insists that one access :443 port. After adding /etc/cups/ssl
>>one still doesn't get a lot of success as key generation seems to take
>>forever. To the point that I just used command line openssl command
>>to generate a key. I do recall that in a previous test I waited a few
>>hours and it eventually appeared, however, this is clearly unsatisfactory
>>behaviour.
>>
>>
>
>As far as I can tell, this has, in fact, been resolved. Cups no longer requires
>HTTPS to change administrative settings on my machine, up-to-date as of
>2006-06-05. Note that this was previously not the case (about 3 weeks? ago,
>when this bug was originally filed).
>
>-Forest
>
>
>
Do you mean in Ubuntu/Dapper or the original source on www.cups.org?

[Ante Karamatić (ivoks)]

Conclusion:

README says we don't support SSL, which is partialy true. CUPS is build against libgnutls, but it's unusable. Packages at http://www.grad.hr/~ivoks/ubuntu/cups solve this issue (autogeneration of keys is done).

Licensing issues should be checked and packages fixed according to results.

[Forest Bond (forest-bond)]

> >As far as I can tell, this has, in fact, been resolved. Cups no longer requires
> >HTTPS to change administrative settings on my machine, up-to-date as of
> >2006-06-05. Note that this was previously not the case (about 3 weeks? ago,
> >when this bug was originally filed).
> >
> >-Forest
> >
> >
> >
> Do you mean in Ubuntu/Dapper or the original source on www.cups.org?

In Ubuntu/Dapper.

Agreed that the package does _support_ SSL through gnutls, but still fails to
generate its own key properly, and agreed that this should be fixed. But,
SSL no longer appears to be necessary to e.g. add a printer, so the admin
interface is not completely broken.

-Forest

[Matthias Klose (doko)]

Ante Karamatić schrieb:
> Conclusion:
>
> README says we don't support SSL, which is partialy true. CUPS is build
> against libgnutls, but it's unusable. Packages at
> http://www.grad.hr/~ivoks/ubuntu/cups solve this issue (autogeneration
> of keys is done).

didn't we change that, such that all services use the same certificate?

[WalterNicholls (walter-nic)]

How long is autogeneration supposed to take? I've waited for 5 minutes so far... would some nice person be able to post how to generate the key with openssl, or how to turn https off? (I've tried Encryption Never - did nothing)

As noted against #42802 we had troubles printing from a computer upgraded from breezy to dapper. I decided to upgrade the server to dapper as well in the belief this will simply fix the problem - and it made things worse. I now have a print job stuck with the job status reporting as "stopped at novalue" (this is on the printer status page http://vale:631/printers/Laserjet2550L where "vale" is the server's name of course). Attempting to cancel this job results in a page requesting "426 upgrade required" redirecting to the https equivalent, and clicking on this link goes nowhere- the browser waits apparently forever After this cupsd appears to hang and does not respond to any further requests of any kind (/etc/init.d/cupsys restart brings it back).
/var/log/cups/error_log shows:
I [06/Jun/2006:22:10:31 +1200] Started "/usr/lib/cups/cgi-bin/printers.cgi" (pid=4141)
I [06/Jun/2006:22:10:52 +1200] Generating server key...

I have upgraded to 1.2.1 (the packages from grad.hr as above) hoping this would solve things. It makes no difference - although the last job is reported as "stopped" rather than "stopped at novalue" which is an improvement I guess, I still can't cancel it or print anything else.

[Walter Tautz (wtautz)]

WalterNicholls wrote:

>How long is autogeneration supposed to take? I've waited for 5 minutes
>so far... would some nice person be able to post how to generate the
>key with openssl, or how to turn https off? (I've tried Encryption Never
>- did nothing)
>
>
>
Try running openssl req -new -x509 -nodes -days 365 -out server.crt
-keyout server.key
(install openssl package first)
inside of /etc/cups/ssl (you may need to make this directory) moreover
you'll need
to make the permissions something like 0600 and ownerships should
coincide with
directory...

>As noted against #42802 we had troubles printing from a computer upgraded from breezy to dapper. I decided to upgrade the server to dapper as well in the belief this will simply fix the problem - and it made things worse. I now have a print job stuck with the job status reporting as "stopped at novalue" (this is on the printer status page http://vale:631/printers/Laserjet2550L where "vale" is the server's name of course). Attempting to cancel this job results in a page requesting "426 upgrade required" redirecting to the https equivalent, and clicking on this link goes nowhere- the browser waits apparently forever After this cupsd appears to hang and does not respond to any further requests of any kind (/etc/init.d/cupsys restart brings it back).
>/var/log/cups/error_log shows:
>I [06/Jun/2006:22:10:31 +1200] Started "/usr/lib/cups/cgi-bin/printers.cgi" (pid=4141)
>I [06/Jun/2006:22:10:52 +1200] Generating server key...
>
>I have upgraded to 1.2.1 (the packages from grad.hr as above) hoping
>this would solve things. It makes no difference - although the last job
>is reported as "stopped" rather than "stopped at novalue" which is an
>improvement I guess, I still can't cancel it or print anything else.
>
>
>

[WalterNicholls (walter-nic)]

Walter Tautz: thanks. For completeness, that's
 cd /etc/cups
 mkdir ssl
 chgrp lpadmin ssl
 chmod 0600 ssl
 cd ssl
 openssl .....(what you said)
 /etc/init.d/cupsys restart

So I've cancelled all the jobs successfully now, and by deleting and recreating the printer I have my dapper laptop printing - great! Thanks all.

[Martin Pitt (pitti)]

Merely creating the directory with

  sudo mkdir /etc/cups/ssl
  sudo chown cupsys /etc/cups/ssl

was enough for me to get it running. Creating the certificate and key was a matter of seconds.

However, to integrate our snakeoil SSL certificate support, we need to do the following (as root):

  mkdir /etc/cups/ssl
  ln -s /etc/ssl/certs/ssl-cert-snakeoil.pem /etc/cups/ssl/server.crt
  ln -s /etc/ssl/private/ssl-cert-snakeoil.key /etc/cups/ssl/server.key
  adduser cupsys ssl-cert

and then restart cupsys.

[Ante Karamatić (ivoks)]

And make cupsys depend on ssl-cert.

[Martin Pitt (pitti)]

This is now fixed in cupsys_1.2.1-2ubuntu1 in edgy.

[Martin Pitt (pitti)]

Creating dapper task since it is a good candidate for dapper-updates.

[Martin Pitt (pitti)]

 cupsys (1.2.1-0ubuntu1) dapper-updates; urgency=low
 .
   * Upgrade to new upstream version 1.2.1 (backported from edgy):
     - fix for printing on Xerox IPP printers; Closes: LP#47387
     - fix for banners on single page
     - fix for custom page sizes (cups ignores them now in some cases)
     - fix for -u and -U switches for lpadmin
     - fix for printing on some Canon printers
     - fix for printing on CUPS server < 1.1.17 (RHEL3 and older)
       (partly fixes LP bug #42802)
     - couple of fixes for imagetoraster
   * Add debian/patches/00_r5643.dpatch: Pull some fixes from upstream SVN
     scheduled to go into 1.2.2:
     - The lpstat command did not use the correct character
       set when reporting the date and time (STR #1751)
     - The cupsaddsmb command and web interface did not update
       the Windows PPD files properly, resulting in corrupt
       PPD files for the Windows client to use (STR #1750)
     - The cupsd.conf man page didn't describe the Listen
       domain socket syntax (STR #1753)
     - The scheduler no longer tries to support more than
       FD_SETSIZE file descriptors.
     - The USB backend now reports a "no such device" error
       when using the old filename-based USB URIs instead of
       the "success" error.
     - Increased the HTTP and IPP read timeouts to 10 seconds,
       as 1 second was too short on congested networks (STR
       #1719)
     - Fixed another file descriptor leak when printing raw
       files (STR #1736)
     - The scheduler didn't always choose the least costly
       filter.
     - Fixed parsing of IPv6 addresses in Allow, Deny,
       BrowseAllow, BrowseDeny, and BrowseRelay directives
       (STR #1713)
     - Special cases for the "localhost" hostname did not
       work, causing printing to not work when the /etc/hosts
       file did not contain a localhost entry (STR #1723)
     - Updated the Spanish translation (STR #1720)
     - Reverse-order page output was broken when N-up or
       landscape orientations were used (STR #1725)
     - The parallel, serial, socket, and USB backends needed
       print data before they would report back-channel data,
       causing problems with several new drivers (STR #1724)
   * Ship /etc/cups/ssl directory. Closes: LP#44931
   * Removed debian/patches/svn*.dpatch, these were backported from 1.2.1 in
     1.2.0-0ubuntu3.
   * debian/cupsys.init.d: Add missing log_end_msg. Closes: LP#48116
   * Bump up shlibs to >= 1.2.1 for compatibility safety.