UTN-USERFirst-Object - "Can't verify signature
bmo
CA cert UTN-USERFirst-Object in Firefox 3.0.1.
We were issued a code signing certificate which was signed by the UTN-
USERFirst-Object cert built into Firefox (Comodo issues these). We
have successfully signed our jar file with the certificate (verified
with jarsigner -verify, etc.), however on Firefox 3.0.1 (on macosx),
when our jar is loaded, we get a 'this applet was signed by <company
name> however we cannot verify the signature' do you want to trust
this applet?
Showing the details lists our certificate, derived from the built-in
UTN-USERFirst-Object certificate. I have verified that the signature
on the UTN-USERFirst-Object shown in the dialog matches the internal
one.
Looking at the built-in certificates (using Preferences->Advanced-
>Encryption, View Certificates) and scrolling down to The USERTrust
Network list of certs -- pick the last one in the list, Viewing the
certificate shows the message "Can't verify signature of this
certificate for unknown reasons".
I suspect that that is the problem; I do note that firefox 2.x on
Windows does NOT display the scary dialog, and accepts the jar as
signed. It also displays the 'Can't verify signature of this
certificate for unknown reasons' message when viewing the built-in
certificate (Which, in reading the archives of bugs from 2005, may
mean something else entirely).
Can someone tell me:
1) Why the built-in UTN-USERFirst-Object cert is not verifiable (why
is it in Firefox, then?)
2) Why the behavior (if it's the same certificate in FF 2.x and
3.0.1) is different between FF versions?
thanks,
Nelson B Bolyard
> Summary: I suspect that there's something wrong with the BUILT-IN Root
> CA cert UTN-USERFirst-Object in Firefox 3.0.1.
Or perhaps something is wrong with the code that tells you about that
cert.
> We were issued a code signing certificate which was signed by the UTN-
> USERFirst-Object cert built into Firefox (Comodo issues these). We
> have successfully signed our jar file with the certificate (verified
> with jarsigner -verify, etc.), however on Firefox 3.0.1 (on macosx),
> when our jar is loaded, we get a 'this applet was signed by <company
> name> however we cannot verify the signature' do you want to trust
> this applet?
>
> Showing the details lists our certificate, derived from the built-in
> UTN-USERFirst-Object certificate.
Is your cert issued directly by the UTN-USERFirst-Object cert? Or is
there an intermediate CA certificate in between your cert and that one?
> Looking at the built-in certificates (using Preferences->Advanced->
> Encryption, View Certificates) and scrolling down to The USERTrust
> Network list of certs -- pick the last one in the list, Viewing the
> certificate shows the message "Can't verify signature of this
> certificate for unknown reasons".
Yeah, I think that's a bug in the PSM UI code that displays that page.
I think it says the cert is not verifiable when it actually is.
> I suspect that that is the problem; I do note that firefox 2.x on
> Windows does NOT display the scary dialog, and accepts the jar as
> signed. It also displays the 'Can't verify signature of this
> certificate for unknown reasons' message when viewing the built-in
> certificate (Which, in reading the archives of bugs from 2005, may
> mean something else entirely).
Those facts alone should be pretty convincing that the cert is actually
OK, but the UI says it's not for some unknown reason. :) (It's unknown
why the UI says it can't be verified, and it's unknown why the UI says
the reason is unknown.)
> Can someone tell me:
> 1) Why the built-in UTN-USERFirst-Object cert is not verifiable (why
> is it in Firefox, then?)
Let's call it a bug in the UI code. I'm pretty sure there's a really OLD
bug filed about that UI code. Let's see...
https://bugzilla.mozilla.org/show_bug.cgi?id=289988 filed in 2005 for FF1
https://bugzilla.mozilla.org/show_bug.cgi?id=293154
https://bugzilla.mozilla.org/show_bug.cgi?id=300071
> 2) Why the behavior (if it's the same certificate in FF 2.x and
> 3.0.1) is different between FF versions?
That's a good question. Here are some things to investigate.
Look at your cert in FF2. Look at the cert chain. Do you see only two
certs? or three? or more?
If you see a third cert in between yours and the "root" cert at the top,
look for that cert in the Authorities tab, and see if it is in the
"Builtin Object Token" or the "Software Security Device".
Also, look in the tab for "your certificates" and see if your code signing
cert is listed there.
Then repeat these steps with FF3 and see if anything is different.
Let us know.
Rob Stradling
The "UTN-USERFirst-Object" Root CA happens to be cross-certified by
the "AddTrust External CA Root" Root CA. Both Roots are owned by Comodo, and
both are trusted by Firefox for the purpose of signing code.
You can download the cross-certificate from:
http://crt.comodoca.com/UTNAddTrustObjectCA.crt
If you include that cross-certificate when you sign your .jar, it just might
work around the problem.
(Note: I haven't tested this, so it might not work. Either way, some feedback
would be appreciated :-) ).
On Tuesday 12 August 2008 05:42:35 Nelson B Bolyard wrote:
> bmo wrote, On 2008-08-11 20:22:
> > Summary: I suspect that there's something wrong with the BUILT-IN Root
> > CA cert UTN-USERFirst-Object in Firefox 3.0.1.
>
> Or perhaps something is wrong with the code that tells you about that
> cert.
>
> > We were issued a code signing certificate which was signed by the UTN-
> > USERFirst-Object cert built into Firefox (Comodo issues these). We
> > have successfully signed our jar file with the certificate (verified
> > with jarsigner -verify, etc.), however on Firefox 3.0.1 (on macosx),
> > when our jar is loaded, we get a 'this applet was signed by <company
> > name> however we cannot verify the signature' do you want to trust
> > this applet?
> >
> > Showing the details lists our certificate, derived from the built-in
> > UTN-USERFirst-Object certificate.
>
> Is your cert issued directly by the UTN-USERFirst-Object cert? Or is
> there an intermediate CA certificate in between your cert and that one?
>
> > Looking at the built-in certificates (using Preferences->Advanced->
> > Encryption, View Certificates) and scrolling down to The USERTrust
> > Network list of certs -- pick the last one in the list, Viewing the
> > certificate shows the message "Can't verify signature of this
> > certificate for unknown reasons".
>
> Yeah, I think that's a bug in the PSM UI code that displays that page.
> I think it says the cert is not verifiable when it actually is.
>
> > I suspect that that is the problem; I do note that firefox 2.x on
> > Windows does NOT display the scary dialog, and accepts the jar as
> > signed. It also displays the 'Can't verify signature of this
> > certificate for unknown reasons' message when viewing the built-in
> > certificate (Which, in reading the archives of bugs from 2005, may
> > mean something else entirely).
>
> Those facts alone should be pretty convincing that the cert is actually
> OK, but the UI says it's not for some unknown reason. :) (It's unknown
> why the UI says it can't be verified, and it's unknown why the UI says
> the reason is unknown.)
>
> > Can someone tell me:
> > 1) Why the built-in UTN-USERFirst-Object cert is not verifiable (why
> > is it in Firefox, then?)
>
> Let's call it a bug in the UI code. I'm pretty sure there's a really OLD
> bug filed about that UI code. Let's see...
> https://bugzilla.mozilla.org/show_bug.cgi?id=289988 filed in 2005 for FF1
> https://bugzilla.mozilla.org/show_bug.cgi?id=293154
> https://bugzilla.mozilla.org/show_bug.cgi?id=300071
>
> > 2) Why the behavior (if it's the same certificate in FF 2.x and
> > 3.0.1) is different between FF versions?
>
> That's a good question. Here are some things to investigate.
>
> Look at your cert in FF2. Look at the cert chain. Do you see only two
> certs? or three? or more?
>
> If you see a third cert in between yours and the "root" cert at the top,
> look for that cert in the Authorities tab, and see if it is in the
> "Builtin Object Token" or the "Software Security Device".
> Also, look in the tab for "your certificates" and see if your code signing
> cert is listed there.
> Then repeat these steps with FF3 and see if anything is different.
> Let us know.
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
--
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com
Comodo CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
bmo
> bmo wrote, On 2008-08-11 20:22:
>
> > Summary: I suspect that there's something wrong with the BUILT-IN Root
> > CA cert UTN-USERFirst-Object in Firefox 3.0.1.
> Look at your cert in FF2. Look at the cert chain. Do you see only two
> certs? or three? or more?
>
> If you see a third cert in between yours and the "root" cert at the top,
> look for that cert in the Authorities tab, and see if it is in the
> "Builtin Object Token" or the "Software Security Device".
> Also, look in the tab for "your certificates" and see if your code signing
> cert is listed there.
I've posted a PNG of the chain of trust as reported by the browser to
http://www.tryventi.com/certissue/onehub_cert.png - there is no
intermediate certificate between ours and UTN-USERFirst-Object.
The browser-supplied details of the UTN-USERFirst-Object is
http://www.tryventi.com/certissue/utn_cert_unverifiable.png
I'll look at the cross-cert issue in a bit.
Kyle Hamilton
Firefox security module. Try looking in Keychain Access for the
UTN-USERFirst certificate, and then try installing it into Keychain
Access, and try it again.
-Kyle H
bmo
> Er. Java on the Mac might use the system Keychain, instead of the
> Firefox security module. Try looking in Keychain Access for the
> UTN-USERFirst certificate, and then try installing it into Keychain
> Access, and try it again.
Gee, wouldn't that put this in the 'broken' category then? One of the
big advantages (perhaps only advantage) of having a commercially-
issued signing cert is the avoidance of a user to have to install or
change anything in their configuration.
Nelson Bolyard
> I've posted a PNG of the chain of trust as reported by the browser to
> http://www.tryventi.com/certissue/onehub_cert.png
That shows your cert to be valid. That's all that matters, with respect
to your cert.
You originally reported an error message that said: 'this applet was signed
by <company name> however we cannot verify the signature'
That's a statement about the signature on the applet, not the signature
on the certificate. It doesn't say that the cert is bad.
Kyle Hamilton raised the possibility that the error you're seeing is from
the JVM rather than from Mozilla code. If the complaint comes from Java,
which has its own PKI and trusted cert store, then I'd guess that Java
doesn't trust UTN's object root.
bmo
wrote:
> Kyle Hamilton raised the possibility that the error you're seeing is from
> the JVM rather than from Mozilla code. If the complaint comes from Java,
> which has its own PKI and trusted cert store, then I'd guess that Java
> doesn't trust UTN's object root.
I've checked all of the cacerts files that I can find .. all show the
USERFirst-Object... not sure what the JVM would use besides ONE of
these FOUR ...
keytool -v -list -keystore /System/Library/Frameworks/JavaVM.framework/
Versions/1.4.2/Home/lib/security/cacerts :
*******************************************
Alias name: keychainrootca-61
Creation date: Apr 11, 2007
Entry type: trustedCertEntry
Owner: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The
USERTRUST Network, L=Salt Lake City, ST=UT, C=US
Issuer: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The
USERTRUST Network, L=Salt Lake City, ST=UT, C=US
Serial number: 44be0c8b500024b411d3362de0b35f1b
Valid from: Fri Jul 09 11:31:20 PDT 1999 until: Tue Jul 09 11:40:36
PDT 2019
Certificate fingerprints:
MD5: A7:F2:E4:16:06:41:11:50:30:6B:9C:E3:B4:9C:B0:C9
SHA1: E1:2D:FB:4B:41:D7:D9:C3:2B:30:51:4B:AC:1D:81:D8:38:5E:
2D:46
*******************************************
keytool -v -list -keystore /System/Library/Frameworks/JavaVM.framework/
Versions/1.5.0/Home/lib/security/cacerts
*******************************************
Alias name: keychainrootca-62
Creation date: Apr 11, 2007
Entry type: trustedCertEntry
Owner: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The
USERTRUST Network, L=Salt Lake City, ST=UT, C=US
Issuer: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The
USERTRUST Network, L=Salt Lake City, ST=UT, C=US
Serial number: 44be0c8b500024b411d3362de0b35f1b
Valid from: Fri Jul 09 11:31:20 PDT 1999 until: Tue Jul 09 11:40:36
PDT 2019
Certificate fingerprints:
MD5: A7:F2:E4:16:06:41:11:50:30:6B:9C:E3:B4:9C:B0:C9
SHA1: E1:2D:FB:4B:41:D7:D9:C3:2B:30:51:4B:AC:1D:81:D8:38:5E:
2D:46
*******************************************
keytool -v -list -keystore /System/Library/Frameworks/JavaVM.framework/
Versions/1.6.0/Home/lib/security/cacerts
*******************************************
Alias name: keychainrootca-37
Creation date: Jan 14, 2008
Entry type: trustedCertEntry
Owner: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The
USERTRUST Network, L=Salt Lake City, ST=UT, C=US
Issuer: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The
USERTRUST Network, L=Salt Lake City, ST=UT, C=US
Serial number: 44be0c8b500024b411d3362de0b35f1b
Valid from: Fri Jul 09 11:31:20 PDT 1999 until: Tue Jul 09 11:40:36
PDT 2019
Certificate fingerprints:
MD5: A7:F2:E4:16:06:41:11:50:30:6B:9C:E3:B4:9C:B0:C9
SHA1: E1:2D:FB:4B:41:D7:D9:C3:2B:30:51:4B:AC:1D:81:D8:38:5E:
2D:46
*******************************************
Output from
keytool -v -list -keystore /Library/Java/Home/lib/security/cacerts
*******************************************
Alias name: keychainrootca-62
Creation date: Apr 11, 2007
Entry type: trustedCertEntry
Owner: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The
USERTRUST Network, L=Salt Lake City, ST=UT, C=US
Issuer: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The
USERTRUST Network, L=Salt Lake City, ST=UT, C=US
Serial number: 44be0c8b500024b411d3362de0b35f1b
Valid from: Fri Jul 09 11:31:20 PDT 1999 until: Tue Jul 09 11:40:36
PDT 2019
Certificate fingerprints:
MD5: A7:F2:E4:16:06:41:11:50:30:6B:9C:E3:B4:9C:B0:C9
SHA1: E1:2D:FB:4B:41:D7:D9:C3:2B:30:51:4B:AC:1D:81:D8:38:5E:
2D:46
*******************************************
bmo
page with an applet signed by our cert as with FF 3.0.1 on Mac,
the dialog comes up as "Signature is verified, do you want to run this
code?" - SUCCESS.
That machine has never seen our signed java applet before; it has no
certificates installed.
I then download Firefox 3.0.1 on that machine (Windows Vista) and
installed it.
Hitting the same page with the signed java code (after clearing the
cache in the Java console) also SUCCEEDS- no problems whatsoever.
That is much, much friendlier than "Can't verify signature"
On FF2.0.15 on Windows Vista, the UTN-USERFirst-Object certificate
ALSO shows "Could not verify this certificate for unknown reasons"
bmo
hit the page with our signed java applet on it -- SUCCESS -- I am
provided a prompt that says the applet verified, do I want to run the
code?
I then installed FF 3.0.1 on the Vista machine. Reset the JVM cache;
hit the same page with our signed applet -- SUCCESS -- not even a
warning or a query about whether I wanted to run the application.
Back on the mac (firefox 3.0.1) , I checked the certificates in the
Apple Keychain utility -- UTN-USERFirst-Object is provided with
"System Default" preferences, whatever those are. I set that
certificate to "ALWAYS TRUST" in the keychain utility, and also set
our Onehub cert to "always trust". I cleared the cache, and hit the
page with our applet -- still says the certificate's signature cannot
be verified.
Summary:
Firefox 2.0.15 on Windows Vista- SUCCESS
Firefox 3.0.1 on Windows Vista - SUCCESS
Firefox 3.0.1 on Mac OSX - FAILURE
Kyle Hamilton
-Kyle H
Nelson Bolyard
Unfortunately, it's still not clear (at least, to me) whether this is a
Firefox issue or a JVM issue. I searched through all the firefox source
code for the string "this applet was signed by" and didn't find it.
That makes me suspect that this is an issue with JVM/JD/JCE/Jmumble.
bmo
> Could you perhaps post your certificate chain?
>
> -Kyle H
>
What is presented in the browser for the certificate chain:
http://www.tryventi.com/certissue/trust1.png
http://www.tryventi.com/certissue/trust2.png
http://www.tryventi.com/certissue/trust3.png
As far as our cert, here's the dump from keytool:
Creation date: Aug 13, 2008
Entry type: keyEntry
Certificate chain length: 2
Certificate[1]:
Owner: CN="Onehub, Inc.", O="Onehub, Inc.", STREET=3380 146th Place
SE, STREET=Suite 105, L=Bellevue, ST=WA, OID.2.5.4.17=98007, C=US
Issuer: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The
USERTRUST Network, L=Salt Lake City, ST=UT, C=US
Serial number: af795fc39554a02bb73f76c6597f5d4f
Valid from: Tue Jul 22 17:00:00 PDT 2008 until: Thu Jul 23 16:59:59
PDT 2009
Certificate fingerprints:
MD5: 9F:2A:2E:80:E4:DF:82:71:5B:96:B7:46:D7:E2:30:09
SHA1: 3E:6B:2E:85:DC:D8:F7:F9:51:64:2F:1F:C9:D9:83:47:81:72:38:C1
Certificate[2]:
Owner: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The
USERTRUST Network, L=Salt Lake City, ST=UT, C=US
Issuer: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The
USERTRUST Network, L=Salt Lake City, ST=UT, C=US
Serial number: 44be0c8b500024b411d3362de0b35f1b
Valid from: Fri Jul 09 11:31:20 PDT 1999 until: Tue Jul 09 11:40:36
PDT 2019
Certificate fingerprints:
MD5: A7:F2:E4:16:06:41:11:50:30:6B:9C:E3:B4:9C:B0:C9
SHA1: E1:2D:FB:4B:41:D7:D9:C3:2B:30:51:4B:AC:1D:81:D8:38:5E:2D:46
A typical entry in our jar (from jarsigner -verify...) is
sm 986 Fri Jun 13 18:28:54 PDT 2008 images/up.gif
X.509, CN="Onehub, Inc.", O="Onehub, Inc.", STREET=3380 146th
Place SE, STREET=Suite 105, L=Bellevue, ST=WA, OID.2.5.4.17=98007,
C=US
[certificate is valid from 7/22/08 5:00 PM to 7/23/09 4:59 PM]
X.509, CN=UTN-USERFirst-Object, OU=http://www.usertrust.com,
O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
[certificate is valid from 7/9/99 11:31 AM to 7/9/19 11:40 AM]
bmo
applets that DO WORK on Firefox 3.0.1/mac osx.
Again, 'works' is defined as if the applet is signed, with a valid
cert, and chain of trust to a trusted root CA, then no scary-and-
confusing-to-a-user messages should come up.
Here's one on Sun's web site, a nice OpenGL demonstration:
https://jogl-demos.dev.java.net/applettest.html
FAIL: This applet exhibits the same issue-- signature is unable to be
verified. (See error message http://www.tryventi.com/certissue/trust_not_for_sun.png
Looks like this isn't an issue with USERFirst-Object so much as FF
3.0.1 on mac doesn't deal with valid certs correctly *OR* perhaps the
wrong dialog is being presentded? Perhaps the dialog should be the one
that says (on other platforms) -- "FOOBAR applet has been signed and
the signature has been verified, do you want to allow this code to
execute?"
Kyle Hamilton
does not do the OSX Java releases, the best place to file a bug report
on this issue would be http://bugreport.apple.com/ -- an Apple
Developer Center (ADC) ID is required to submit bug reports there.
-Kyle H
Nelson Bolyard
> Summary: I suspect that there's something wrong with the BUILT-IN Root
> CA cert UTN-USERFirst-Object in Firefox 3.0.1.
>
> We were issued a code signing certificate which was signed by the UTN-
> USERFirst-Object cert built into Firefox (Comodo issues these). We
> have successfully signed our jar file with the certificate (verified
> with jarsigner -verify, etc.), however on Firefox 3.0.1 (on macosx),
> when our jar is loaded, we get a 'this applet was signed by <company
> name> however we cannot verify the signature' do you want to trust
> this applet?
That apparent quote of the text of the error message is actually a misquote,
and the misquote was significant to our attempts to help
you diagnose the problem. The actual error message, as it appears
in the png files you posted,
http://www.tryventi.com/certissue/trust1.png
http://www.tryventi.com/certissue/trust2.png
http://www.tryventi.com/certissue/trust3.png
http://www.tryventi.com/certissue/trust_not_for_sun.png
was:
The applet was signed by <company name> but *Java* cannot verify the
authenticity of the signature's certificate. Do you trust this
certificate?
The crucial difference between the message as you quoted it, and the actual
message, is in who is speaking as the source of the error message. The
message actually says that _JAVA_ cannot verify the signature.
This error message is coming from Java, not from Firefox. Java has its
own code and its own store of certificates for signature verification.
It does not use the signature verification built into the browser, and
the browser relies entirely on Java to verify the signature on file of
MIME content-type application/java-archive (which these are). The browser
does not verify the signature, but passes the received JAR to Java to verify
it.
Also note that it is not asking you if you trust the applet, but rather
it is asking you if you want to trust the certificate. If you answer
positively, I believe Java may store that certificate so that henceforth
you will not be asked about applets signed with that same cert.
Your issue is with Java, I believe, not with Firefox.
I think you'll get more help in a Java support forum.
Regards,
Nelson
Kyle Hamilton
(https://jogl-demos.dev.java.net/applettest.html) under Safari, it's
definitely not Firefox-related.
http://bugreport.apple.com/ is the best way to report this, since
Apple maintains its own Java distribution for OS X (you cannot get an
OS X version of Java from Sun).
It requires a (free) ADC membership to actually submit a bug report;
if you do not have one, you can get one by going to
http://developer.apple.com/ and selecting (from the very top of the
page, on the right side) "ADC Member Site".
-Kyle H
Kyle Hamilton
bugreport.apple.com. The text of the report follows.
-Kyle H
* SUMMARY
Java mispresents a properly-signed applet as "Java cannot verify the
authenticity of the signature's certificate".
* STEPS TO REPRODUCE
On a freshly-installed copy of Leopard, with all software updates:
1) Open Safari
2) Go to the URL https://jogl-demos.dev.java.net/applettest.html
3) View the security warning that pops up, select "Show Certificate"
4) Check the chain of certificates up to the root certificate
* RESULTS
The security dialog that pops up says:
This applet was signed by "sun microsystems, inc," but Java cannot
verify the authenticity of the signature's certificate. Do you trust
this certificate?
When I select "Show Certificate", it comes up with a chain of
certificates (I'm listing them from bottom to top):
sun microsystems, inc -- green checkmark, "this certificate is valid"
(Issued by: VeriSign Class 3 Code Signing 2004 CA)
VeriSign Class 3 Code Signing 2004 CA -- green checkmark, "this
certificate is valid" (Intermediate Certification Authority)
Class 3 Public Primary Certification Authority -- green checkmark,
"this certificate is valid" (Self-signed root certificate)
Comparing the self-signed root with the certificate in the System
Roots keychain matches precisely.
I expected Java's applet permission-request message to read more like:
This applet was signed by "sun microsystems, inc," which states that
it needs permission to do everything that a locally-installed
application could do in order to operate properly. Would you like to
grant this permission?
(this is my suggested wording -- but "cannot verify the authenticity
of the signature's certificate" is absolutely NOT the actual case.)
* REGRESSION
I have not performed any regressions, other than to test both between
Firefox 3.0.1 and Safari.
* NOTES
I am submitting this bug report because somebody made a post to the
Mozilla dev-tech-crypto mailing list stating that Firefox was having
problems. The thread can be found at:
http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/512ef357ccef3d9d#
. We have traced this to a mispresented error message from Java.
This is a security-usability issue.
On Thu, Aug 14, 2008 at 2:31 AM, Kyle Hamilton <aero...@gmail.com> wrote:
> Since this same warning shows up even going to the same location
> (https://jogl-demos.dev.java.net/applettest.html) under Safari, it's
> definitely not Firefox-related.
>
> http://bugreport.apple.com/ is the best way to report this, since
> Apple maintains its own Java distribution for OS X (you cannot get an
> OS X version of Java from Sun).
>
> It requires a (free) ADC membership to actually submit a bug report;
> if you do not have one, you can get one by going to
> http://developer.apple.com/ and selecting (from the very top of the
> page, on the right side) "ADC Member Site".
>
> -Kyle H
>
> On Thu, Aug 14, 2008 at 1:05 AM, Nelson Bolyard
> <NOnels...@nobolyardspam.com> wrote: