google-code-export / jzebra

Automatically exported from code.google.com/p/jzebra
1 stars 0 forks source link

Connection to this website is untrusted #174

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
While loading qz-print, a dialog appears with an incorrect message saying:

> "JAR File does not contain the Permissions attribute"

> "Security Warning, Do you want to Continue?"

> "The connection to this website is untrusted."

> "The certificate is not valid and cannot be used to verify the identity of 
this website"

Here is a bulletin on it:
http://qzindustries.com/CertNotValid

Most people experiencing this issue seem to be related to Java treating 
StarField Technologies and Godaddy Certificates as untrusted.  This is 
inconsistent with how the applet is treated with similar certificates.

-Tres

Original issue reported on code.google.com by tres.fin...@gmail.com on 2 Nov 2013 at 2:21

Attachments:

GoogleCodeExporter commented 9 years ago
I was able to fix this on my end by importing the offending certificate into 
Java.  It seems Java looks at the OS for it's applet signatures, but not for 
the HTTPS signatures and I don't see StarField in its initial list.

This is most clearly a bug with the Java framework and only seems to apply when 
dealing with HTTPS and is most common with Godaddy certificates.

Recommendation is to try this against a certificate in Java's list, such as 
Verisign and see if it goes away (if you don't have a verisign cert, perhaps a 
collegue does).

I'll do more testing with this on my own and post my progress here.

-Tres

Original comment by tres.fin...@gmail.com on 5 Nov 2013 at 1:47

GoogleCodeExporter commented 9 years ago
Some more information on this... Not sure what to make of it...

http://support.godaddy.com/groups/ssl-certificates/forum/topic/ssl-cert-not-reco
gnized-by-java/

Original comment by tres.fin...@gmail.com on 6 Nov 2013 at 8:32

GoogleCodeExporter commented 9 years ago
After examining some logs and performing some research on the matter, the cause 
of this issue was fixed by a configuration option in Apache.

----

It appears there may be missing configuration(s) in Apache for Java to work 
nicely with SSL/HTTPS.  The message I searched for was 
"javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name"

<VirtualHost mydomain.com:443>
  ServerName mydomain.com
  ServerAlias www.mydomain.com
Let me know if this helps.

----

I'll leave this bug open for a little while, but it should be a pretty easy fix 
for those Apache users encountering this issue.

-Tres

Original comment by tres.fin...@gmail.com on 11 Nov 2013 at 1:45

GoogleCodeExporter commented 9 years ago
Hi, I have the same problem. I have all my "JAR" signed with the new security 
settings. "All-permissions", "Codebase" and "Application-Name". If I access the 
SSL application displays the same dialog box. What worries me is the message of 
blocking the application. If I access without SSL everything seems fine and I 
have no problem.

Have you found any solution?

Original comment by nemeek@gmail.com on 21 Nov 2013 at 11:34

GoogleCodeExporter commented 9 years ago
@netmeek,

We've had difficulties reproducing this.  Do you have a sample page I can use 
to reproduce this error? If so, please email me:  tres.finocchiaro@gmail.com 

Original comment by tres.fin...@gmail.com on 21 Nov 2013 at 6:15

GoogleCodeExporter commented 9 years ago
Here is a link to the stackoverflow page where I got my <VirtualHost...> 
solution.

http://stackoverflow.com/questions/7615645/ssl-handshake-alert-unrecognized-name
-error-since-upgrade-to-java-1-7-0

Note that in Java 7 Update 51 (j7u51) this completely blocks the applet from 
loading.

Closing bug and marking as invalid, since this is a peculiarity of Java and is 
not a bug with the qz-print plugin.

-Tres

Original comment by tres.fin...@gmail.com on 17 Jan 2014 at 2:39