Cannot load URL: com.ibm.jsse2.util.h: No trusted certificate found

[PUB Web Team]

Hello All,

We have Google reCAPTCHA implemented on our WebSphere 6 Application Server with a Signer Cert installed. The Cert stops working even before it expires without any notice and the only way to fix it is to generate a new one which comes back with a new date. 

This issue happens in our production environment and I am wondering why Google updates the certs randomly without notice and why the old cert stops working even before it is expired?

Are we doing something wrong or is there a better way to implement the signer cert so this does not occur?

The error we begin receiving when this occurs is: Cannot load URL: com.ibm.jsse2.util.h: No trusted certificate found

- Murtaza 

[Wayne]

Murtaza,

I believe I've the same issue.  How did you get a new cert, please?

Thanks,
Wayne

Follow CrossView on Twitter!  twitter.com/CrossView_Inc

Check out our Linkedin Profile!  linkedin.com/company/crossview-inc.

This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.

[PUB Web Team]

Wayne, 

Here is how I do it. Unfortunately this has started to happen more and more and its getting very annoying...

1.      Login into WebSphere Application server of the target environment

2.      In the left column Go to SSL certificate and key management > Key stores and certificates > CellDefaultTrustStore > Signer certificates

a.      Click Retrieve From Port

b.     Fill out the form as below as displayed in screenshot and hit “Retrieve signer information”:

c. Apply and Save changes

d. Restart the application Server.

- Murtaza

[Kiran Hiremath]

Hi,

We are also facing the similar issue. Our Apps server is also WAS , is this issue only being seen in this application server?

If anyone has figured out the cause of these frequent certificate changes then please let the forum know.

Thanks 

KIran

[PUB Web Team]

We are continuing the to face this issue. I believe what is happening is that Google is switching over to servers which seem to have different certs. When the signer is not found in WAS the error starts occuring. I am now starting to save all the signers that have not expired instead of removing the previous one before installing the new one. Hope this resolve the issue.

- Murtaza

[PUB Web Team]

Found a solution that works!

Use the the non SSL verification URL which does not require signers to be installed on the WebSphere application server. This resolve the issue by verifying the reCAPTCHA text over port 80. You can still use this on a application that is being hosted on port 443 by using the SSL URL for the initial reCAPTCHA call to get the image but then use the non SSL verification URL for the server side validation. 

Hope this helps resolve this very annoying signer issue once and for all. 

- Murtaza

[Adrian Godong]

Why are you calling the verify URL using HTTPS? You don't need to do
it and I don't think it is supported.

Ref: https://developers.google.com/recaptcha/docs/verify (take note of
the API Request URL, use http).

> --
> You received this message because you are subscribed to the Google Groups
> "reCAPTCHA" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to recaptcha+...@googlegroups.com.
> To post to this group, send email to reca...@googlegroups.com.
> Visit this group at http://groups.google.com/group/recaptcha.
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
Adrian Godong
adrian...@gmail.com

[Scott Hurlbert]

Because I was trying to keep all calls secure since the reCAPTCHA is being used on a fully SSL hosted site (Company  Policy). SSL verifty URL works and we have been using the https://www.google.com/recaptcha/api/verify URL for a over a year now. Its just flaky and every server has a different signer cert so whenever google changes their DNS settings to point to a different server reCAPTCHA failed until we retrieved the signer from that server. 

Anyway I was having this issue for a very long time and no one seemed to have a solution for it on this form. Looks like I was not the only one either. I figured it out on my on my own on a last ditch effort. Google pretty much has no support for this service and I would move off of it if there were any similar providers. 

- Murtaza

--
You received this message because you are subscribed to a topic in the Google Groups "reCAPTCHA" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/recaptcha/Ld0QopNkrgc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to recaptcha+...@googlegroups.com.

[thanh nguyen]

[Adrian Godong]

Have you tried using HTTP instead to verify the challenge?

---

Adrian Godong

On Jul 2, 2013, at 20:15, thanh nguyen <tn3...@gmail.com> wrote:

We have Google reCAPTCHA implemented on our WebSphere 6 Application Server with a Signer Cert installed. The Cert stops working even before it expires without any notice and the only way to fix it is to generate a new one which comes back with a new date. 

This issue happens in our production environment and I am wondering why Google updates the certs randomly without notice

--