Service Virtualization

Recently our development team have implemented https protocol with ssl certificate authentication for rest services, due to this all our current tests cases are giving authentication error (since they were developed on http protocol).

I have the certificate (.cer), please guide what steps need to be taken in order to make our https rest call working with the ssl certificate authentication.

Using lisa 7.0.3 on windows 7

Any suggestions will be off great help.

~Umair.

I've never seen version 7, but typically you don't have to do much to make a client side call to an https server.. cause the client does all the negotiation work.. in 8.x you check the box that says SSL to server

are they using ssl or tls encryption.. I know we had to make a change to our DevTest config to do tls first.

Not sure about the encryption method. All i am aware of is that there is .cert involved.

~Umair.

Hi Savzwari,  I believe you are referencing one-way authentication not two-way / Mutual Auth, correct?

I don't have specific step-by-step information because I no longer have 7.0 installed on my machine.  If you have the User's Guide or Administration guide, you might find useful information there.

Are you able to convert the .cer file into a .jks file or can you have an admin do that for you?

This conversion is done using Java keytool.exe which is in java's bin directory.  The command is something like:

keytool -importcert -file </path/to/Cert/FileNameHere>.cer -keypass <password> -keystore </path/to/Keystore/NameHere>.jks -alias "myAlias"

Once you get the certificate converted into a JKS, place it in a directory where your step can access it.  Open your test case and look at the SSL tab on your steps (you may need to use PRO mode for this).  Within the SSL tab, you should be able to add the SSL Keystore file location, password, and alias.  This overrides SSL only for this step.

If you are certain that you can apply the certificate globally, research the use of ssl.client.cert.path, ssl.client.cert.pass, and ssl.client.key.pass properties in local.properties.  These properties are used to set global certificate information.  I believe the above props are used by Web service and Raw Soap steps.  I don't recall if this overrides REST steps.  There is also a process for folding the cert into LISA's OOTB JKS file, but I do not recall the specific steps involved for this approach.  

Hi Joel,

it is a rest service, with one way authentication. I am not able to see the PRO mode under rest service call. Will try to see if the global application of cert works or not.

~Umair

Apologies for the misdirection on using PRO mode.  I couldn't recall if r7.0 had PRO mode or not. 

Since this is a certificate and you are not dealing with Trust stores, you may be able to fold (import) the certificate into the OOTB LISA JKS file.  This file is located in the LISA_HOME/webreckeys.ks and is referenced by the lisa.default.keystore property.  This is LISA's default keystore where self-signed certificates are stored. 

As Sam pointed out, this JKS supports the majority of client-side SSL negotiations that are typically encountered.  I have on occasion run into situations where I had to download and install the Java crypto classes when a server expects a stronger encryption algorithm. I believe the password for this JKS is 'passphrase'.  If you decide to use webreckeys.ks, it is best to create a backup so you have a restore point in case something goes wrong. 

After you make your JKS changes, run your REST step from LISA Workstation.  Before you submit the step, select the Help menu bar and choose HTTP/SSL debug from the options.  This will open a panel at the bottom of your Workstation.  Submit the test and you can see the SSL handshaking.  If the handshake fails, you might be able to use this output to diagnose what happened.   

Hi Jeol, No need to apologies , I am thankful for all the help.

I undid the changes in the local properties file.

I have imported the certificate as you suggested but it is still failing. Following is the log which I captured:

~Umair.

Unfortunately, there is not enough information in the text above to figure out what is wrong. 

Here's an additional option so can generate detailed SSL debug output.

1) Using Windows Explorer (assuming you are running a Windows OS), navigate to LISA_HOME/bin

2) Locate the LISAWorkstation.EXE.

3) If there is a file called LISAWorkstation.vmoptions, open it with an editor (Notepad or Notepad++)

    If there is not a file, create one and save it exactly as the 'LISAWorkstation' name appears and replace the '.exe' suffix with '.vmoptions'.

    Add the following command on a line by itself

-Djavax.net.debug=all  

     The syntax is '-D' which means directive.  You are activating the the built-in Java debugger for the system property javax.net.debug

     If using Notepad, make sure that a .txt extension is not added by Notepad.

4) Save the file and check that it appears with exactly the same name as the Workstation.exe including UPPER and lower case letters.

     You have now defined a VMOPTIONS file that can be used when the Workstation is started.

5) Shut down the Workstation.

6) Navigate to c:\users\<yourAcctId>\lisatmp_7.0.1    (this is where LISA places its log files.  your folder name may be slightly different)

7) Locate the file called workstation.log and delete or rename it. (this is the log file that Workstation dumps output into)

     Deleting this file will not cause harm.  And, it will make it smaller when you open it in step 9, below.

8) Restart LISA Workstation so the directive activates, open your project, and execute your REST call one time

9) Navigate back to c:\users\<yourAcctId>\lisatmp_7... and open the workstation.log file.

The debug option will cause a lot of information to be dumped into the log.  If you drop to the bottom of the file and work up from there you will see output similar to what you saw in the SSL Debug within Workstation.  Hopefully, there will be more detailed information than you received in the SSL debug window inside workstation.

Now open this URL: Debugging SSL/TLS connections

Oracle has a document that identifies what is happening during the handshake between the client and the server.  Oracle's example uses X509 certificates, but generally the handshake pattern holds true regardless of the SSL.

One thought is that the server may be expecting a stronger encryption algorithm than the Workstation Java JRE provides.  You might need to install the Java crypto classes if the encryption is greater than what the JRE supports.

The other thought is that the REST call is not picking up your self-signed Certificate (the one provided by the admin in the CER file).  When the CLIENT says HELLO to the server, it passes a list of the Cipher suites it can use.  The SERVER says HELLO, it settles on a cipher suite that the two will use.  The SERVER then passes its certificate chain to LISA (the Client).

What I would look for is that the CLIENT recognizes the chain.  There may be a message like:  'Found Trusted Certificate' indicating that a match has been found between the Issuers and the Certificates.  I would look at the Cert and see if it is the correct self-signed cert and not a generic cert issued by CA or Sun, etc.

I am hoping debug output might provide a better indication since Exception is a generic 'catch all' type of exception.

From here, you have two options.  One option is to upload the workstation log -- which you probably cannot do since there could be customer information in the dump.  The other option is to find a security admin within the customer organization that created the certificate to help you diagnose the output in your log file.

Sorry, wish I had been able to spot the exact issue.  Joel