Closed tresf closed 9 years ago
@sjennison per e466811, 165cdb9 Windows support should be finished. Can you take a look at implementing the Java portion?
@robertcasto is @sjennison planning on tackling this still?
Yep - I'll be working on it today
Great! :+1:
@sjennison FYI, updated the GitHub checklist to illustrate task completion of Ubuntu cert generation and installation.
To try out the windows self-cert portion, you'll have to:
make nsis
using ANTout
directorywindows-keygen.js
file from out\build
and run in in an Admin CMD window which will have the same effect. Of course, the install location would be unknown at that point, so it won't know where to put it, but you can tweak the file as needed. It's run via cscript.exe path\to\windows-keygen.js
As always, please email me if you need any assistance with this.
-Tres
@tresf - is there a good way to reference that properties file from the Java code? Not sure where it would end up from the code in the .js file :)
@sjennison,
It should be in the install directory. For the installed-version (not running through IntelliJ), this should be the same directory as ShortcutUtilities.getJarPath()
.
For when running through IntelliJ, the properties won't necessarily be available, but we can discuss that later.
@robertcasto @bberenz, FYI, Firefox didn't like the .crt
unless I enabled a CA flag on it via. https://github.com/qzind/qz-print/commit/87dd86b5f5a10df14c090b8dd31b95407007c9fb
Not sure if jetty needed this flag too, so FYI.
So it's importing successfully into Firefox?
On Wed, Apr 22, 2015, 23:08 Tres Finocchiaro notifications@github.com wrote:
@robertcasto https://github.com/robertcasto @bberenz https://github.com/bberenz, FYI, Firefox didn't like the .crt unless I enabled a CA flag on it via. 87dd86b https://github.com/qzind/qz-print/commit/87dd86b5f5a10df14c090b8dd31b95407007c9fb
Not sure if jetty needed this flag too, so FYI.
Reply to this email directly or view it on GitHub https://github.com/qzind/qz-print/issues/15#issuecomment-95407122.
@sjennison, only manually at the moment. The NSIS stuff is still giving me a hard time per #18.
I'm tempted to look into a JNI approach because Firefox is a very difficult beast as it simply won't read from the OS certs by design.
But back on topic... yes, it will import into Firefox now via manual method. That CA flag passed into Java's keystore generator was the ticket.
Steven said he left a note, but just to be sure: the installed qz-tray certificate needs the common name (CN) to be pointing to localhost for the secure websockets to work correctly.
@bberenz This is defined here:
https://github.com/qzind/qz-print/blob/1.9/qz-print/ant/self-sign.properties#L19
We should be able to just change this from -dname \\"CN=${jks.company},
to -dname \\"CN=localhost,
.
Want me to do that now, or are you comfortable trying it?
@bberenz @sjennison do we have a way of detecting an invalid cert in JavaScript for the wss:// stuff? If so, perhaps we can provide manual instructions to the user to import the cert into Firefox until we develop an automated way.
@sjennison @bberenz what was the trick to get the cert working with Chrome? I finally have IE working, but Chrome won't connect.
I've changed CN=localhost
vi 21425a6 and Internet Explorer works, but Chrome Version 42.0.2311.90 m
is still giving me a hard time. Here's a copy of the cert...
CERT
-----BEGIN CERTIFICATE-----
MIIDaTCCAyegAwIBAgIELL8xhzALBgcqhkjOOAQDBQAwfDELMAkGA1UEBhMCVVMxCzAJBgNVBAgT
Ak5ZMRIwEAYDVQQHEwlDYW5hc3RvdGExGzAZBgNVBAoTElFaIEluZHVzdHJpZXMsIExMQzEbMBkG
A1UECxMSUVogSW5kdXN0cmllcywgTExDMRIwEAYDVQQDEwlsb2NhbGhvc3QwHhcNMTUwNDI3MDQw
NjM3WhcNMzUwNDI3MDQwNjM3WjB8MQswCQYDVQQGEwJVUzELMAkGA1UECBMCTlkxEjAQBgNVBAcT
CUNhbmFzdG90YTEbMBkGA1UEChMSUVogSW5kdXN0cmllcywgTExDMRswGQYDVQQLExJRWiBJbmR1
c3RyaWVzLCBMTEMxEjAQBgNVBAMTCWxvY2FsaG9zdDCCAbgwggEsBgcqhkjOOAQBMIIBHwKBgQD9
f1OBHXUSKVLfSpwu7OTn9hG3UjzvRADDHj+AtlEmaUVdQCJR+1k9jVj6v8X1ujD2y5tVbNeBO4Ad
NG/yZmC3a5lQpaSfn+gEexAiwk+7qdf+t8Yb+DtX58aophUPBPuD9tPFHsMCNVQTWhaRMvZ1864r
Ydcq7/IiAxmd0UgBxwIVAJdgUI8VIwvMspK5gqLrhAvwWBz1AoGBAPfhoIXWmz3ey7yrXDa4V7l5
lK+7+jrqgvlXTAs9B4JnUVlXjrrUWU/mcQcQgYC0SRZxI+hMKBYTt88JMozIpuE8FnqLVHyNKOCj
rh4rs6Z1kW6jfwv6ITVi8ftiegEkO8yk8b6oUZCJqIPf4VrlnwaSi2ZegHtVJWQBTDv+z0kqA4GF
AAKBgQDyXs6wiYxW/gxTjqgZkN4tumetN4x9suJIj417TrOO3BVTiCwDGvh0ZiCYOa/9zER48tup
667iVLct4IrSpwILYQBCogzXmprcKF7KuBsTNNvlmfj1XFGwOs1ugFGD+fuSF+0I7mE9tJef+aIc
tB53vTua28ODKAbc2s/5ytgMk6M1MDMwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUAnVO
PmD1FqVAxXY8zfnuOQSh5tEwCwYHKoZIzjgEAwUAAy8AMCwCFDkdULIY6GD55uWgzk40yz2CTmUV
AhQ+/FXTbJRLXNoSAGGhbuEoN+dYCQ==
-----END CERTIFICATE-----
So it turns out the certificate wasn't complex enough. I bumped it to RSA 2048 via 5dd5011 and it seems to be in much better shape now.
Chrome is working now, but Firefox is not unless I hand-allow the cert exception via https://localhost:8181
.
The Firefox error is: mozilla_pkix_error_ca_cert_used_as_end_entity
Edit: Somewhat related, here's a decent conversation about it: https://bugzilla.mozilla.org/show_bug.cgi?id=1034124
From what I'm reading, Firefox is smart enough to know that the HTTPS is running from a CA generated cert, which is taboo (but overridable). @sjennison does this mean we'll have to issue an End-Entity certificate from the CA to circumvent this Firefox behavior?
So I've been looking for a valid way to generate a certificate chain for a web server, and came across this, specifically the section Generating Certificates for a Typical SSL Server
http://docs.oracle.com/javase/7/docs/technotes/tools/windows/keytool.html
A couple of questions...
Do we need all three components:
Or can we get away with two:
I've begun adapting the tutorial to a batch file to wrap my head around everything... Its not working yet, so I'm calling it a night, but this is what I have so far:
@echo off
del ca.jks root.jks server.jks
set keytool="C:\Program Files (x86)\Java\jre1.8.0_31\bin\keytool.exe"
set dname="CN=MyCompany, OU=MyCompany, O=MyCompany, L=City, S=State, C=US"
set dnameserver="CN=localhost, OU=MyCompany, O=MyCompany, L=City, S=State, C=US"
%keytool% -genkeypair -noprompt -keystore root.jks -alias root -keyalg RSA -keysize 2048 -dname %dname% -storepass 123456 -keypass 123456 -ext bc:c
%keytool% -genkeypair -noprompt -keystore ca.jks -alias ca -keyalg RSA -keysize 2048 -dname %dname% -storepass 123456 -keypass 123456 -ext bc:c
%keytool% -genkeypair -noprompt -keystore server.jks -alias server -keyalg RSA -keysize 2048 -dname %dnameserver% -storepass 123456 -keypass 123456
%keytool% -keystore root.jks -alias root -exportcert -rfc -storepass 123456 -keypass 123456 > root.pem
%keytool% -storepass 123456 -keystore ca.jks -certreq -alias ca | %keytool% -storepass 123456 -keystore root.jks -gencert -alias root -ext BC=0 -rfc > ca.pem
%keytool% -keystore ca.jks -importcert -alias ca -file ca.pem -storepass 123456
%keytool% -storepass 123456 -keystore server.jks -certreq -alias server | %keytool% -storepass 123456 -keystore ca.jks -gencert -alias ca -ext ku:c=dig,kE -rfc > server.pem
copy /b root.pem+ca.pem+server.pem | %keytool% -keystore server.jks -importcert -alias server
So I'm still struggling to get past the end_entity
Firefox error.
I believe this is possible if we can chain a separate server
certificate just for jetty, but I'm struggling to find a way to do this on-the-fly as I can't figure out a way for Java to process a CSR in order to make a certificate chain.
I've read quite a few tutorials and they all seem to be under the assumption that the CSR is processed by a 3rd party CA using something like OpenSSL, but we don't necessarily have OpenSSL at install time so I'd like to rule out Java's keytool
first, prior to distributing the installers with OpenSSL binaries....
Initial Firefox support on Windows has been added via 8d61a68
Awesome! Anything you need me to do on this now?
On Thu, Apr 30, 2015, 00:04 Tres Finocchiaro notifications@github.com wrote:
Initial Firefox support on Windows has been added via 8d61a68 https://github.com/qzind/qz-print/commit/8d61a688c64265214c6a14f92025ed1177f41d6c
Reply to this email directly or view it on GitHub https://github.com/qzind/qz-print/issues/15#issuecomment-97654359.
A better understanding of the feasibility of HTTP fallback support would be a plus although that may be a @bberenz task.
Also, were you able to reproduce the installer problem you had reported?
Fallback support added via 9ebe9459be71a81586e79c403d7b69999531644e. The socket will attempt all the WSS ports before trying the WS ports, so insecure connections will take a little longer to be established.
@bberenz, this is great, thanks. One thing we haven't added yet is the ability to start the server on ws://. Ideally, we'd have at least one and up to two instances listening.
Apple is working per https://github.com/qzind/qz-print/commit/84d8b5365a3d6c96649d55db1edd03fecc660a82
We still have a few items to work out in terms of how to Uninstall properly, etc, but the screenshot below has Firefox and Chrome running using Secure Websockets.
A tester reported an issue launching the software on Apple per #22 which is hopefully fixed now.
The next items are installer related:
ws://
Fallback support added via 9ebe945 (per Brett)Remaining items (Linux installer cleanup, will start new thread):
certutil
prior to install on Linux, or else Chrome certs won't work
Firefox by default blocks non-secure websockets connections from HTTPS locations. This is meant to be a placeholder for secure websockets (
wss://
) support.Current design includes: (please check off items as they are completed):