Closed tresf closed 8 years ago
I think the list is rendering a bit off, but I think I can read it how it was intended.
Something I'll point out in regards to this: With the custom certificate generation, it would be very useful to be able to supply a root certificate to use for signing the generated certificate, or simply the ability to supply an existing certificate in the installer.
When I implemented this in my use case, I generated a root CA certificate and installed that on the client machines which would need to print (several Apple and a Windows). From there I used that certificate when manually rolling a certificate (for the WebSocket) for the qz-print installation, that way if I change the hostname or anything like that I don't have to redeploy the generated certificate to client machines, things will continue to work since the root certificate was already installed.
This also allows for easily adding more qz-print installations since they would all be signed using the root certificate and will work out of the box.
This also allows for easily adding more qz-print installations since they would all be signed using the root certificate and will work out of the box.
I'm going to pick on semantics here a bit (sorry) but signing is done using a private key. Would you distribute that same private key to all machines? This is what Lenovo did with the superfish blunder and it's normally frowned upon, but risk is minimal if the cert is bound to a particular hostname rather than a wildcard domain (I assume you did this?).
We'd likely keep the certificate something completely separate from what the company uses as to not encourage such a security threat, so my idea is to make the private key and certificate something that would be grabbed from the "print server" at install time and then distributed to the clients (private key distributed for signing, certificate used for allowing the HTTPS traffic). Does that make sense?
Yes, the private key for the self-signed CA certificate.
To avoid any extra confusion here, since there are two certificate/private key pairs at play here: the one used for secure traffic on the web socket (WSS) and the one used for securing print requests to qz-tray.
To make life simpler, both of those certificates in my deployment were signed with the private key of a self-signed CA certificate, and the self-signed CA certificate was distributed to any client machine wishing to print. The private key for the CA certificate has been kept private and was not distributed.
I'm not overly concerned with security in this situation since the private key of the CA certificate is not needed for day to day operations.
My suggestion for allowing providing this private key with the CA certificate during qz-tray installation is indeed a bit of a security risk, but the private key would reside on the machine temporarily (if properly deleted) and could be password protected. My alternative suggestion was to allow for the already generated WSS certificate and private key to be provided since they could be generated offline (and bound to the hostname of that machine).
The private key for the CA certificate has been kept private and was not distributed.
Oh of course because the PCs won't have the software running. :bulb:
Thanks for the explanation.
I think the list is rendering a bit off
Thanks, fixed. :+1:
Added initial support for non-localhost bindings via https://github.com/qzind/qz-print/commit/f8b273af8b6d2f8a0189a120bbae042d5afaca7d
Although an install-time approach is likely preferred, handing the different host.domain
input methods on Apple, Windows and Linux adds a complexity (fetch input via AppleScript, NSIS, bash) as well as an unnecessary prompt to our base installer that probably isn't worth it... so here's the initial support...
For secure websocket non-localhost bindings
Generating keystore and certificate on Windows (Linux support is started too but needs testing)
cmd
as AdministratorRun the following command, where host.domain
is the IP or hostname QZ Tray will be running on.
wss://
support, Firefox needs to be installed prior to running this command.cd "%PROGRAMFILES%\QZ Tray\"
cscript auth\windows-keygen.js . install host.domain
qz-tray.properties
, qz-tray.crt
and qz-tray.jks
using the provided domain.qz-tray.crt
and deploy to workstations which will connect to the supplied domain using wss:///
defaults/pref/firefox-prefs.js
firefox-config.cfg
Testing
demo
folder from QZ Tray to a separate test PC.qz-tray.crt
into Trusted Root Certificates (this process will vary depending on platform)Note
deployQZ
needs to have hostname provided... i.e. deployQZ('host.domain')
, which currently isn't in the qz-websocket.js
.deployQZ("foo.bar")
added via 6f1cd58
Apple support is done via 91487b0.
Last step is documentation.
Edit: Documentation started here: wiki/Print-Server
@klabarge to complete and publish to home page.
Documentation finished via https://github.com/qzind/qz-print/wiki/print-server.
Some Linux and Mac steps need to be added for cross-platform support, but the enhancement is completed.
Awesome!
@klabarge FYI, we'll need to fix the wiki for 2.0 as it makes specific reference to deployQZ
which is a 1.9
-only feature.
https://github.com/qzind/qz-print/wiki/print-server#deploy-qz
Documentation updated: https://github.com/qzind/qz-print/wiki/Print-Server#connect-to-qz-tray
We have a user that has taken the time to convert QZ Tray to use a hostname instead of
localhost
which may help for our Citrix enhancement (#83) via fc33512 1eb2350 005da8a.This is a placeholder to enhance the
localhost
bindings to allow an IP address or hostname similar to the aforementioned commits (we'll leavelocalhost
as default).Questions...
qz-websocket.js
to allow remote hostsAdd host to(not needed, localhost works fine forqz-tray.properties
filews://
andwss://
)WindowsLinuxApple