SSL is a confusing subject for us all. And, trying to answer questions without all of the context is equally confusing.
First, it's is a good thing that the file verifies. But, that only indicates the file is valid. It does not tell us what certs are expected for the exchange.
Of SSL, SNI, Java and DevTest is one of the better posts on how SSL works between a consumer and provider. This has nothing to do with internal DevTest component-to-component comms.
Using an out of the box installation, DevTest uses its webreckey.ks file which has a set of certificates when HTTPS is used. In a virtual service, if the consumer and DevTest can agree to use one of these certs, the HTTPS traffic flows with no issues. Similarly, if a REST or Webservice step uses HTTPS to access an endpoint, DevTest presents the certificates from its webreckeys.ks file to the provider endpoint. If the provider is happy with the list of certs DevTest provides, the communications occur.
Similarly, SoapUI and web browsers do the same thing when using HTTPS. So long as the provider endpoint accepts the certs, everyone is happy. There is a bit of subtlety though. When computers are provisioned in a customer's environment, those computers can have custom certs pre-loaded as part of the setup. A browser, for example, can access those certs. But, DevTest does not know anything about their existence or location.
Some customers prefer to use their own set of custom certificates. In these cases, when DevTest presents its defualt (webreckeys) list of certificates, the expected custom certificate is not in the list. When the provider application does recognize the custom cert, it 'shuts down' the communications.
Some customers take the above a step further and require that a trust store exists on both servers so the servers trust and agree they are who they say they are. This is a truststore not a keystore.
The original post indicates a network team sent a custom JKS cert file. Naturally, I was expecting that the customer had a custom certificate that must be exchanged between the client and server in order for HTTPS to work. This is the reason for all the setup related to the custom JKS.
If this custom JKS actually contains other certificates that are in DevTest's webreckeys.ks then HTTPS works whether the custom JKS file is used or not. We would have no way of knowing what is in the custom JKS file without opening it and examining the expected set of certs.
Since you know the password to the custom JKS, download portecle (https://sourceforge.net/projects/portecle/ ), open the certs file and examine it. Do the same to the webreckeys.ks file. Perhaps, one of the certs in webreckeys is valid in the custom JKS.