Question

I've been trying to adopt myself and my applet to the new security constraints imposed in Java 7.

My applet is self signed and as such, it was automatically blocked. After adding the site to the exception list in the java configuration console I managed accessing it but not without having to see that annoying message shouting at me that the signer is UNKNOWN, requiring me to approve running the applet.

This one is really annoying as it requires my approval each time I try to load the applet...not storing my previous approval...

so, I found this document which should have solved all my problems as the distribution of my applet is within a known community. I followed all the guidelines, created the certificate and entered it into the store that is used by the JRE (I also see that certificate from the configuration console) but the annoying approval message keeps popping and saying that the signer is still UNKNOWN...

any idea, what I'm missing? it looks like the addition of the certificate into my store had no impact on the flow whatsoever...

thanks in advance. GBa.

Was it helpful?

Solution 2

Well, I finally found the problem...

It turns out that once I cloned the trusted.certs (deployment.user.security.trusted.certs) file into trusted.cacerts (deployment.user.security.trusted.cacerts) file, everything started working...

I do not understand what the difference is between the two stores, futhermore, in the link that I added in the question (this), it talks about the certs file for individual usage and so... it made sense to me that it should work... however, it turns out that Java thinks differently :-)

anyways... this is the answer.

thanks everyone for your collaboration, GBa.

OTHER TIPS

Unfortunately mentioned certificate fields are not provided so maybe my guess is wrong but I would suggest that you create a certificate where the Common Name in the Subject field matches the signing authority address. There are three ways to have a match and eventually avoid the warning: 1. The host name (in the address bar) exactly matches the Common Name in the certificate's Subject. 2. The host name matches a wildcard common name. For example, www.example.com matches the common name *.example.com. 3. The host name is listed in the Subject Alternative Name field. The most common form of SSL name matching is for the SSL client to compare the server name it connected to with the common name in the server's certificate. If an SSL certificate has a Subject Alternative Name (SAN) field, then SSL clients are supposed to ignore the common name value and seek a match in the SAN list.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top