2014-03-07 18:21 GMT+02:00 Matthias Wessendorf <matzew@apache.org>:

On Fri, Mar 7, 2014 at 5:11 PM, Stefan Miklosovic <smikloso@redhat.com> wrote:

Hi,

we are doing HTTPS tests on UPS integration tests where UPS Java client is used to send some payload to UPS, it seems it is not sufficient to have only plain HTTP sender when we are sending it to HTTPS endpoint.

When JBoss AS is set up with keystore and truststore in https connector for web subsystem like this:

<connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true">
<ssl name="aerogear-ssl" key-alias="aerogear"
password="aerogear"
certificate-key-file="${jboss.server.config.dir}/aerogear.keystore"
protocol="ALL"
verify-client="none"
certificate-file="${jboss.server.config.dir}/aerogear.keystore"
ca-certificate-file="${jboss.server.config.dir}/aerogear.truststore"/>
</connector>

and UPS Java client sends some payload (with HttpUrlConnection, not secure connection), this exception is thown from it:

I guess we can use, for https, the HttpsUrlConnection - that;s what you are basically asking, right ?

Mind to create PR for that ?

Thanks!
Matthias

The certificate used in UPS integration tests is self signed. The SSL handshake, most probably will fail even when using HttpsUrlConnection, if the custom truststore is not set. I believe that the existing UPS sender version will work when a real, valid certificate is used instead of a self signed one.

That's what I said on IRC: self signed certs issue

This issue could be fixed if UPS sender was providing a functionality to set up and use a custom TrustManager which contains the Keystore with the self signed certificate. In my opinion, the question is whether supporting self signed certificates in UPS sender, brings value.

Thanks,

Tolis

SEVERE: Send did not succeed: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

This basically means that server was not able to mark that connection as trusted.

In order to use custom trustStore and trustStorePassword, they are propagated to test like system properties

System.setProperty("javax.net.ssl.trustStore", "aerogear.truststore");
System.setProperty("javax.net.ssl.trustStorePassword", "aerogear");

however any attempt to set them in test itself like that is not successful since it is "too late". When they are set like -D properties with maven, it is executed without any problems.

This does not work as well https://github.com/aerogear/aerogear-unifiedpush-java-client#known-issues since we are not using jsse (and can not) because of this issue https://issues.jboss.org/browse/JBPAPP6-711 which was repaired in 7.1.2 and that release is not community release anymore so we can not base tests on EAP and we are running them on 7.1.1. (we can not run them on WF as well since it is not compatible with EAP but 7.1.1 is).

So this is chicken-egg problem. When verify-client is "none" plain http from UPS Java client is not validated. When we do want client authentication (verify-client=want/true), UPS sender is not https aware. Additionally, we can not use "jsse" due to JBPAPP6-711.

Ideas?

Stefan Miklosovic
Red Hat Brno - JBoss Mobile Platform

e-mail: smikloso@redhat.com
irc: smikloso
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev