The error_log shows:
Unable to encrypt connection: Unable to create server credentials.
I tested this issue on 4 different systems with the exact same error.
Using the cups web interface only works without encryption.
Hi Thomas - Welcome to the IPFire Community!
I just installed CUPS via Pakfire on IPFire 2.27 (x86_64) - Core-Update 170 Development Build: master/ef7d41ef and all works OK.
I looked in the /var/log/httpd/error_log and did not see anything. So I am guessing you see this after you’ve installed CUPS and you tried to use it.
Where did you see this error?
Can you post a screenshot or a picture of what you see?
(I am going on a tangent AND I am thinking out loud)
I wonder if this has anything to do with messagebus not running (and can not be started)?
The error occurs as soon as you open the admin part of the webinterface, so using cups without an encrypted connection does not reproduce this issue here.
The messagebus error does not interfere here, since cups still works on the latest stable build even with this error.
please send a screenshot of what you see.
And please send a screenshot of the error_log
Browser:
error_log:
E [01/Sep/2022:00:08:42 +0200] [Client 606] Unable to encrypt connection: Unable to create server credentials.
E [01/Sep/2022:00:08:44 +0200] [Client 608] Unable to encrypt connection: Unable to create server credentials.
E [01/Sep/2022:00:08:45 +0200] [Client 609] Unable to encrypt connection: Unable to create server credentials.
[…]
There were recent changes to CUPS.
I opened a bug report:
https://bugzilla.ipfire.org/show_bug.cgi?id=12924
3 Likes
Just for the record: a downgrade on version 2.4.1 works 
I am curious - How did you downgrade?
Just use pakfire in IPFire’s webfrontend and switch back to the stable repo first, uninstall cups, hit the refresh button and install it again. You now have a working 2.4.1 release installed again 
1 Like
Ahh! got it!
I noticed an update for cups today with encryption deactivated, but it is still broken since the necessary encrypted connections to the printer cannot be established. So turning off encryption is not a working workaround.
And again in the current 174 build. Please fix cups again
Sorry, I wasn’t on the copy list of the bug and didn’t realise that the previous update had been reverted.
I had just noticed that there was a newer cups available and so created a patch to update. Unfortunately it looks like no one tested it in the Core Update 174 Testing stage.
I can’t do any testing of cups myself as I have no printers connected to my IPFire vm testbed.
I will create a new patch that will revert cups back to version 2.4.1
EDIT:
Have found the cause for this bug was a change made in cups-2.4.2
A fix for this has been committed in the cups github repo but a new version has not yet been released.
I am therefore creating an update patch that will include the fix patch from cups.
I will also add myself to the copy list of the bug so I will know the status of it in the future.
2 Likes
After some struggles I have eventually succeeded to build version cups-2.4.2 with two patches that fix the problems with certificates that prevented https working.
I have successfully tested https access to the administration pages with the updated build on my vm testbed.
I will be submitting a patch for this update into the dev mailing list tomorrow and it should end up in Core Update 175.
4 Likes
I managed to downgrade the package
Thomas -
a fix for the CUPS issue reported in this thread was added to CU 175 (testing). Can you give it a try and lets us know if it solves your issue?
https://blog.ipfire.org/post/ipfire-2-27-core-update-175-is-available-for-testing
https://bugzilla.ipfire.org/show_bug.cgi?id=12924#c36
Best regards,
Jon
1 Like