Printer SSL certificates are added but never removed, resulting in "no suitable destination host found by cups-browsed"

[Valentijn Sessink]

If a printer preferrably prints through ipps, Cups will store the printers (self signed) certificate in /etc/cups/ssl/

However, if this certificate becomes outdated or invalid, or if it changes, it will *not be removed* and Cups only complains that the "backend returned status 4", "No suitable destination host found by cups-browsed". Even removing the printer manually will not remove the old certificate, rendering the printer invalid for life: when te printer re-appears, the old, invalid certificate is still there, resulting in the printer still not working.

Steps to reproduce:
- use a printer that prefers ipps, let's call it printer_bob
- let this printer appear in your printer list
- make a test print
- Now remove the printer and check that the certificate will survive:
lpadmin -x printer_bob; ls -al /etc/cups/ssl/*bob*crt

What happens:
- certificate is still there

What should happen:
- a removed printer should not have a certificate left

Now in this example, it's rather harmless because the certificate is probably still valid. But a printer update, rename or otherwise will render it invalid and printing will become impossible.

You could simulate a name change for printers:
mv /etc/cups/ssl/printer-carol.local.crt /etc/cups/ssl/printer-bob.local.crt

Or simply mess up the certificate:
sed -i '2s/./a/g' /etc/cups/ssl/printer-bob.local.crt

After this, you will *not* be able to print to printer-bob, because bob has the wrong certificate (obviously). Removing printer-bob does not help. You will need to manually remove the certificate in order to make bob print again. /var/log/cups/error.log will only say that "no suitable destination host found", which is not true: there *is* a destination but the SSL certificate does not match and Cups will only try the first printing method, ipps.

[Paride Legovini (paride)]

Hello Valentijn and thanks for this bug report, it really helped me figure out an otherwise obscure printing issue.

However I don't agree with the suggested solution: the security model of cups for ipps is TOFU (trust on first use): the certificate is accepted the first time and then expected to be the same in the future. This is why the printer certificate is saved to file in the first place. (This approach is similar to what SSH uses: the first time you connect to a host the pubkey is saved in authorized_keys; if at some point the key changes ssh will refuse to connect and require manual deletion of the old key from authorized_keys.)

I think this is a UI issue: from the cups web interface or cups logs it was not clear at all that the issue was with ipps certificate validation. Cups (or maybe the ipps backend? I'm not that familiar with cups internals) should log a proper error message instead.