LoadRunner and Performance Center
Showing results for 
Search instead for 
Do you mean 

New Ways to Secure Your LoadRunner Environment in 12.00

Anonymous_User1 ‎04-01-2014 10:00 AM - edited ‎09-22-2015 01:44 PM

(This post was written by Yan-Jun Yu (Tedy), from the LoadRunner R&D Team)


HP LoadRunner is a distributed system consisting of a number of different components, such as Controller, Load Generators, MI Listener and Monitor Over Firewall. Support for SSL in the communication between these components was introduced many releases ago. For example, in LoadRunner 11.0 and 11.5x, you can check “Enable SSL support” on the Security tab of the Load Generator Information dialog in the Controller application, so that the inter-process communication between Controller and that Load Generator is protected by SSL, ensuring that nobody can eavesdrop or manipulate the messages transmitted in either direction. The same setting is also available in the Agent Configuration tool, to protect the communication between Load Generator over firewall and MI Listener.


The existing solution up to and including version 11.52 is secure enough to protect data. However, it doesn’t cover the authentication requirements. For example, you cannot prevent other people from connecting to and using your Load Generators. The only solution in previous releases was to configure the host security channel and specify the same secret key on all your different components, meaning that a Controller can only connect to your Load Generator in the security channel if it has the same key. The Security channel also encrypts the data sent over the channel using the same key.


In LoadRunner 12.00, we introduced a complete security solution based on an industry standard SSL/TLS library (OpenSSL), which includes both data encryption and authentication. The figure below illustrates how SSL actually works. The client initiates an SSL request to negotiate the cipher suite to be used with the server, then the server responds by sending its own certificate and an optional request to validate the client certificate.  Finally, the client sends the encrypted shared secret key, and its certificate if necessary. All subsequent messages are encrypted with the shared secret key, and authentication is done by verifying the certificate on the other side:



The following figures show the clients and servers in a LoadRunner deployment:


Controller – Load Generator Communication:


Controller – Load Generator and MI Listener Communication:



Controller – MI Listener – Load Generator and Monitor Over Firewall Communication:


In the Controller, once the connection to Load Generator is SSL enabled, there is a special SSL icon in LoadRunner 12.00:



It’s worth pointing out that although this article is mainly about features in LoadRunner 12.00, many concepts and operations apply to earlier releases as well. I’ll point them out as I discuss them below. 


Working with certificates

The heart of SSL communication is the certificate. LoadRunner provides a default certificate for all LoadRunner components, which is available in the <InstallDir>\dat\cert\ folder, where <InstallDir> is the folder where LoadRunner is installed.  But since the same default certificate is provided for all users, we strongly recommend that you create your own ones with the tools provided by LoadRunner. In fact, if you enable SSL but are still using the default certificate, you’ll get a warning message in the Controller:



To create your own self-signed certificates, the first step is to generate a Certificate Authority (CA) in gen_ca_cert.exe tool, if you don’t have one. Specify a meaningful common name for your CA, I recommend you to use the name of your team, e.g. XyzTeam. You can also specify other command line options, like expiration date; by default the certificate you generate will expire in three years.


Change the current directory to <InstallDir>\bin and run following command:

gen_ca_cert.exe -common_name XyzTeam


It will create two files in the current folder: cacert.cer which is the CA certificate, and capvk.cer which is the CA private key. The private key should be protected separately in your organization and only needed when signing other certificates. You should use the same CA certificate across all LoadRunner components. 



If you already have a CA certificate in your organization, you can continue using it with LoadRunner. The certificate format recognized by LoadRunner is *.pem - base64 encoded DER certificate, enclosed between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----".


To generate a certificate for SSL communication, you have a number of options:


1) Use gen_cert.exe command line tool from the same location of gen_ca_cert.exe. This utility is also available on Linux Load Generator:

gen_cert.exe -common_name XyzTeam -CA_cert_file_name cacert.cer -CA_pk_file_name capvk.cer


2) Use a new tool in 12.00 named lr_agent_settings.exe, which provides an option “-generate_new_cert_file” (used together with “CA_private_key_file_name”) to create a new certificate and install it to the default path in one step. To install new certificates, you should update both the CA certificate and the SSL certificate in this command line tool. The option is case-insensitive in this tool. This utility is also available on Linux Load Generators.


Install CA certificate:

lr_agent_settings.exe -CA_cert_file_name cacert.cer


Automatically generate the SSL certificate using a CA private key (the SSL certificate is also installed after executing this command):

lr_agent_settings.exe -CA_private_key_file_name capvk.cer -generate_new_cert_file


Install the SSL certificate from file which was copied from other machines:

lr_agent_settings.exe -cert_file_name cert.cer


To make the changes take effect, restart the agent from service manager or by using the following command:

lr_agent_settings.exe -restart_agent


3) In the Controller, you can assign the CA or existing certificate or even generate a new certificate inside the application through the menu Tools>Authentication Settings. Don’t forget to restart the Controller after successfully updating the certificates.


In LoadRunner 12.00, the encryption algorithm and signature hash algorithm have been improved to RSA (2048 bits) and sha256 respectively.


You can create a single unique certificate in advance and install it on all LoadRunner components, or alternatively you can create a separate certificate for each of the client machines such as the Controller, Load Generator over firewall, and Monitor over firewall. For client certificates, the latter is recommended so that you can differentiate between them.


As I already mentioned, there is only one copy of certificates from now on, so if your machine is used as both Controller and Load Generator, you only need to install them once.


In previous releases, there are two copies of the same certificates.  The other one can be found at <InstallDir>\launch_service\dat\cert\ which takes precedence over the first one. So exercise caution if you work with those releases. Similarly you should use tools like gen_ca_cert.exe and gen_cert.exe from <InstallDir>\launch_service\bin. To install certificates on those releases, run gen_ca_cert or gen_cert with the “-install” option.


Authentication of client certificates

To validate whether the client machines are really from your team, you can enable the client certificate to check the server side, as long as the CA and certificate have been installed correctly. This flag will cause the server to check the client side certificates on connection, as illustrated in the figure of SSL server and client handshaking, above. By default the flag is turned off. To turn it on, run the following:

lr_agent_settings.exe -check_client_cert 1 -restart_agent


Note that the operation is not allowed if you are using the default certificate shipped with LoadRunner 12.00.


If a Controller is not updated with the client certificate signed by the same CA on Load Generator side, the connection will fail with the communication error, “The client SSL certificate is not trusted by the server”.


Once this check is defined on the server side, any clients already connected without SSL will be notified to reconnect with SSL enabled under the hood.


Client certificate based authentication is a new feature in LoadRunner 12.00.


Authentication of server certificates

In the same way that web browsers validate certificates sent from web servers, LoadRunner client components can also validate the certificate sent from the server applications. By default it’s turned off.


To verify that the server certificates are signed by a trusted Certification Authority on Controller machine:

lr_agent_settings.exe -check_server_cert Medium


The ‘High’ setting will also verify that the common name in the server certificate matches the server host name or IP address:

lr_agent_settings.exe -check_server_cert High


For example, if the Load Generator certificate can’t be trusted by the Controller, it will report an error of the form, “SSL connect error: certificate verify failed”, and the connection will drop.


The same check has been available in the Agent Configuration tool on Load Generators over firewall in previous releases. 


Security of Load Generator on the Cloud

In LoadRunner 12.00, when provisioning Load Generators on the cloud, the certificates will be taken from the Controller and automatically copied to the Load Generators, so the communication will be secure by default. A full overview of cloud-based Load Generator features of LoadRunner 12.00 will be covered in a future blog post.



We described the new solution provided in LoadRunner 12.00 to protect your data from being exposed to malicious third-parties, and to prevent your LoadRunner components from being used by unauthenticated users. If you would like to secure your LoadRunner 12.00 environment, start generating your own certificates and enable the client or server certificate check now!


Please leave a comment in the comment box below to let us know if you found this article useful.



To download HP LoadRunner, click here.



Thanks to Tedy for providing this article!

About the Author


on ‎06-17-2015 08:17 AM

I'm happy that HP is improving support for SSL.  I have a couple of questions about this approach though.


1. Does this toolset support creating requests that must be sent ot an external CA for certificate generation?  All normal PKI environments will require this.  The CA cert is not normally passed around for average folks to create certificates.


2. Does this toolset support multi-level CA trust chains?  This is the most common architecture.


3. Is there planned support for Hardware Security Modules to hold the private keys?  If the underlying crypto libraries (I suspect OpenSSL) are exposed to the administrator, this would be fairly trivial to enable.



27 Feb - 2 March 2017
Barcelona | Fira Gran Via
Mobile World Congress 2017
Hewlett Packard Enterprise at Mobile World Congress 2017, Barcelona | Fira Gran Via Location: Hall 3, Booth 3E11
Read more
Each Month in 2017
Software Expert Days - 2017
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all