We have several REST service in one of our project which are HTTPS based . We are using KS file for SSL configuration within the VSM but middleware app (Consumer) is not able to conenct to our service due to error 407 .
Do we need to provide them cert file that is imported to ks file in our service to authenticate ?
An HTTP 407 is usually associated with a proxy authentication error code. I have never seen DT send that type of a response. When the SSL handshake is terminated, the consumer usually just sees the connection drop with no explanation.
A few questions that might help us out.
- The usual which version of DevTest are you using?
- As a test, can you set up the service as HTTP and have the consumer send a request as HTTP. Let's ensure the request is getting into the service and then debug the security side of it.
- I assume you have enabled TLSv1.2, v1.1, and v1 in local.properties.
- Is the consumer expecting mutual authentication (two-way) SSL (e.g., trust stores)?
- How was the virtual service created? (e.g., Gateway mode or Proxy mode)... Trying to figure out if the virtual service is running in Proxy Server mode or in standard mode.
- When you say using a KS file, do you mean that you are using a custom JKS file (either defined in local.properties or in the Listen step) or are you using SSL with the OOTB webreckeys.ks & vse.ks file that comes with DevTest?
- If you start your VSM in ITR mode and turn on SSL Debug, what do you see there when the consumer submits a request? It might be good to turn on SSL debug to get a better trace of what is happening.
Thanks Joel. Below are my answers
- Devtest Version : 8
- Application is able to hit URL by adding namespace(like abc.com with host name) which i can't mention here
- We have not enable TLS protocol since nothing is SSL enabled here .
- Mutual authentiaction not required
- Virtual servcie created via Gateway mode using RR pairs
- Using custom JKS/KS file made with server sertificate provided by network team
- We haven't tested this in ITR mode with consumer
I just want to know one thing if i am enabling SSL using KS/JKS in VSM do i need to provide consumer team the certificate to authenticate if not in what case it is required
Check out: Of SSL, SNI, Java and DevTest as well.
I do not recall if DT v8.0 has the TLS properties or not.
- In local.properties, add a line having: https.protocols=TLSv1.2,TLSv1.1,TLSv1 (do not add any spaces and do not place '.0' as a suffix on TLSv1) you will need to restart DT servers after making the change -- at least restart Registry, VSE, and Workstation.
- Configure the Listen Step to point to the custom JKS provided by the network team.
Upon verifying the certificate, you should see some sort of success type pop-up. If an error occurs indicating 'Failed', you need to get the certificates in the JKS file cleaned up before SSL will work properly.
- Deploy the service to VSE. The service is now expecting HTTPS to be used.
- Using DT Workstation, create a test case step that sends a sample request to the Service. Send the request as HTTPS and use the same keystore file you used in the Listen step. Before executing the Test (from the Green circle with white arrow), turn on SSL debug (Help Menu -> HTTP/SSL Debug option). Workstation will show you the HTTPS handshake. If you get a proper response, you know the service can send a response so long as the client is using the correct certs.
- If this works, try performing the same action from another tool such Postman, SoapUI, etc. using the JKS file.
- Then, try sending from the application.
If the consumer still does not work, ask the consumer if their application is resolving the endpoint by using a Proxy Server. Perhaps, the Proxy server is not redirecting the HTTPS request back to DT.
Is it necessary to setup TLS protocol for this because our Devtest components and registry are not intercating via SSL .
And we are able to create HTTPS service without adding this as well . A bit confused if TLS is really required in this case .
I have done with hitting https service with above given steps without adding TLS in local.properties and got below
OK, perhaps TLS is enabled in v8.0. I was thinking that v8.0 only supported SSL not TLS, but that may have been v7.0.
In later DT versions, TLS must be enabled using the https.protocols property. This property has no affect on internal DevTest component to component communication. It is strange to me that TLS is automatically enabled in v8.0 and removed in favor of a property in DT v9, v10, onward. However, it seems that you have TLS v1 enabled so you can disregard the configuration steps.
Can you include a picture of the Listen step where you have SSL enabled? There shouldn't be much there that gives away any proprietary information. You can obfuscate the path to the JKS if you want.
When you verify the custom JKS file in the Listen Step, is it showing as "Verified"?
And, if you call your service from a DT Test Case using Webservice step using HTTPS are you able to get the expected response? If you can do these things successfully, I suspect that issue is not with the virtual service.
Yeah it is showing as verified . i have just given the keystore path and password nothing else and i am able to verify the same . but what i am trying to understand is even if i don't provide Keystore details in Web Service excution Steps or even in SOAP UI how HTTPS works then ? Ideally it should not
I believe any client who is trying to hit a HTTPS servcie should have authentication file to create a connection to the URL . Correct me if i am wrong
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.
Thanks joel for Beautifully Aligning this . My custom JKS is contains multiple certs but not the one in webreckeys.ks. In that case i need to tell my client about specific certificates .
Are you aware what certs are contained in webreckeys.ks because we don't have rights to use portecle
Try adding the following directive to your Workstation vmoptions file. You could do the same in VirtualServiceEnvironment.vmoptions or VirtualServiceEnvironmentService.vmoptions file <-- depending on which manner you are starting the VSE.
1) Stop the Workstation
2) Add the directive to Workstation.vmoptions
3) Delete c:\Users\<yourUserID>\lisatmp.x.x.x\Workstation.log
3) Start the Workstation
4) Review the .log file. The OOTB cert chain displays at the top of the log when process starts.
This will give you an idea of the contents.
If you create a test case as HTTPS and send a sample transaction OR if you enable SSL debug in VSE, the log will show the SSL handshake for the incoming HTTPS request.