You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
First of all - I am not sure wether it is a bug or more a feature request.
Settings up cups 2.2.7 to use encryption with GnuTLS certificate (self-signed) and cups-filters 1.25-10 (SuSE SLES15SP5 packages) using cups-browsed to discover remote printers / CUPS servers on the net leads to error message in /var/log/cups/error_log "[Client 65] Unable to encrypt connection: An unexpected TLS packet was received.".
Using gnutls-cli accessing the CUPS server with encryption leads to "[Client 231] Connection now encrypted." which shows the connection could be encrypted.
Using curl with curl http://: shows a connection not possible, whereas curl https has success.
Same in browser while accessing CUPS web ui.
This leads to the assumption that cups-browsed cannot be forced to discover printers or CUPS servers by encrypted connection at first and always doing a unencrypted HTTP request at first.
To Reproduce
Steps to reproduce the behavior:
set up CUPS 2.2.7 with encryption
add DefaultEncrption required to /etc/cups/cupsd.conf
add CreateSelfSignedCerts no to /etc/cups/cups-files.conf
configure cups-browsed on a client
start cups-browsed
Expected behavior
Expected behavior is to use encrypted requests to discover printers / CUPS servers.
Screenshots
If applicable, add screenshots to help explain your problem.
System Information:
OS: SLES15SP5
Firefox, Chrome, Safari
Version cups 2.2.7, cups-filters 1.25-10
Additional context
Context is evaluating a CUPS cluster with cups-browsed and using encrypted connections.
The text was updated successfully, but these errors were encountered:
Is there any flowchart around showing connections and data flow of CUPS, cups-browsed and e.g. usage of implicitclass etc.? And if a link would be nice
Describe the bug
First of all - I am not sure wether it is a bug or more a feature request.
Settings up cups 2.2.7 to use encryption with GnuTLS certificate (self-signed) and cups-filters 1.25-10 (SuSE SLES15SP5 packages) using cups-browsed to discover remote printers / CUPS servers on the net leads to error message in /var/log/cups/error_log "[Client 65] Unable to encrypt connection: An unexpected TLS packet was received.".
Using gnutls-cli accessing the CUPS server with encryption leads to "[Client 231] Connection now encrypted." which shows the connection could be encrypted.
Using curl with curl http://: shows a connection not possible, whereas curl https has success.
Same in browser while accessing CUPS web ui.
This leads to the assumption that cups-browsed cannot be forced to discover printers or CUPS servers by encrypted connection at first and always doing a unencrypted HTTP request at first.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Expected behavior is to use encrypted requests to discover printers / CUPS servers.
Screenshots
If applicable, add screenshots to help explain your problem.
System Information:
Additional context
Context is evaluating a CUPS cluster with cups-browsed and using encrypted connections.
The text was updated successfully, but these errors were encountered: