Server 5.1.5 Shared Printing No Longer Works w/ 10.11.5

I've also had this problem since upgrading my server to Sierra and the latest version of Server app.

Sierra clients can only connect to shared printers using http, https, or ipp. Using ipps, which is the default, fails.

I haven't tried the certs thing above, which I will do. But it does seem to be some sort of authentication issue.

I've also had this problem since I replaced the server's primary SSL certificate as Steve Rhyne described in his reply.

Tracked back to /var/log/cups/error_log, cupsd logged "Unable to encrypt connection". And

I saw securityd logging "displaying keychain prompt for /usr/sbin/cupsd" in Console.app.

I thought they are related, so I check the ACL of the server's primary SSL certificate's private key, and found the cupsd not being on the list. Since I couldn't add the cupsd to the list manually, I changed the Access Control of the private key to "Allow all applications access to this item", and the problem was gone.

Hi, I had the same issue. It was an expired certificate issue. In Keychain Access, in the "Keys" category, the xxx.local certificate had expired under CUPS Self-Signed Certificate. Also the localhost certificate had under CUPS Self-Signed Certificate. I changed them both to "Always Trust", turned off printer sharing, rebooted, turned back on printer sharing. I didn't need to reinstall and printers they just started working.

I hope this helps, attempt at own risk.

Robert

I am sorry if a notification about this issue gets your hopes up, but I am experiencing the same issue with a freshly deployed 10.11.6 Mac mini with Server 5.1.7.

Any printer/copier I setup and share with CUPS 2.1.0 will happily negotiate and add to any deployed device with the same driver version.

The devices are a mix of OS X 10.9.x-10.11.x but every print job will stall with "The printer is not responding." a split second after "Connecting to printer."

Did you find your way out of your issue?

I would greatly appreciate an update.

Unfortunately, Apple Support did not provide a solution. I ended up having to do a clean install and start over.

Our shared HP LaserJet printers recently stopped working in exactly the same way you describe, i.e. "Not responding" message in the client's queue and the same CUPS log entry on the server. The printers are shared on a 10.11.6 system with Server.app 5.1.7. The shared printers had been working fine for months. I tried the following troubleshooting steps, in order, without success:

• stopping and restarting "Printer Sharing"

• stopping and restarting CUPS

• un-sharing and re-sharing each printer in "Printers & Scanners"

• restarting the entire server

• deleting and re-creating the printers on both the server and the client

One possible lead: In our case, the problem started on the same day we replaced our server's primary SSL certificate. I can't be certain that that's related, but since the CUPS error message mentions encryption, my current theory is that this has something to do with it.

I still don't have a solution, so I've had to resort to reconfiguring all clients to print directly to the printers instead of queuing through the server.

I had this same error, I eventually tracked it back to the /etc/cups/certs and /private/etc/cups/certs folders being empty. I couldn't get terminal to make the new certs so I just downloaded Sierra, made a USB and nuked the install. It works fine now.

Basically if you try https://localhost:631 and you get a unable to connect message it means it can't establish a TLS/SSL connection which in turn means that CUPS can't authenticate any print jobs. Even if you use DefaultEncryption Never it still needs something in the certs folder.

Can you give instructions of where and how you did this?

The CUPS "user" is "_lp", fwiw.

Ah. Found it: Keychain Access.

Is there any security implication for allowing all applications access?