8:30 p.m.
2014-03-07 18:21 GMT+02:00 Matthias Wessendorf <matzew(a)apache.org>:
On Fri, Mar 7, 2014 at 5:11 PM, Stefan Miklosovic <smikloso(a)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.
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... 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(a)redhat.com
> irc: smikloso
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev