[ https://issues.jboss.org/browse/ARQ-1370?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč commented on ARQ-1370: --------------------------------- Hey Oliver, this might not be ideal solution at all, just the idea which came from my mind (and just to make it clear, I'm not really a guy into security like you are). Generally: * {{Alpha2}} didn't need to know anything about the underlying communication (see [[1|https://github.com/lfryc/arquillian.github.com/blob/962cf48dee8ed90f42421ac240704a1379caf3a4/docs/warp.adoc]], [2|https://github.com/arquillian/arquillian-organization/wiki/Warp-(JSFUni...) ** I actually think that any SSL communication wouldn't work in Warp in Alpha2, beucase Warp is a Man in the Middle from the SSL handshake perspective * {{Alpha3-SNAPSHOT}} no longer communicates just when a client request is triggered but it creates a request also when test is finished in order to collect server's coverage metrics (through the CommandService servlet) ** and here comes a problem - the request for CommandService is redirected and forced to open a SSL request which fails, because the SSL handshake I guess your client-side tools worked because you used a HTTP client which handled SSL communication. The in-container and Warp test failed, because they weren't able to establish SSL communication. Now the client-side tests fails because CommandService aren't able to establish SSL communication either. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira