ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

Application cannot connect to VSM using SSL - Cannot Verify the Server Name

book

Article ID: 109641

calendar_today

Updated On:

Products

CA Application Test Service Virtualization CA Continuous Application Insight (PathFinder)

Issue/Introduction

A virtual service was created and the option to use SSL enabled in the HTTP Listen step.
There are no issues to deploy the service, but when a request is sent, we get errors that indicate the self-signed SSL certificate for the DevTest virtual service is not installed correctly.
 

Cause

By looking at the client application log files, we verified the exception in the client application connecting to the VSE was "Cannot Verify the Server Name".
By default, if we do not change the keystore provided in the VSM, it will use the self-signed key delivered with DevTest - webreckeys.ks. This is a self-signed keystore issued to Lisa.

When the client application sends a request to the VSM, it returns the Lisa key and since this does not match with the VSE server name the application is trying to access it returns a name mismatch error - The common name in the SSL certificate does not match the address that was provided in the application.

Environment

Release:
Component: ITKOVS

Resolution

In this case, we could create a new self-signed key issued to the VSE Server:
$ ./keytool -genkey -keyalg RSA -alias VSESERVER -keystore keystore.jks -storepass password -validity 360 -keysize 2048

The common name (CN), first and last name, needs to be how the application access the VSE Server - server FQDN, hostname, IP address...

After the key was created, we exported the certificate using the command below:
$ ./keytool -export -alias VSESERVER -file mycert.cer -keystore keystore.jks

The exported certificate was then imported to the client application truststore.

The VSM was modified to use the new keystore created above and redeployed.

After these steps, the client application was able to connect to the Virtual Service Model.