Konstantine is the Head of QA department at ISS Art. He has over 25 years of experience in the field of IT and Quality Assurance. Konstantine is specialized in a variety of fields including load testing, functional and automated testing, security and other types of testing

Become a JMeter and Continuous Testing Pro

Start Learning

Test Your Website Performance NOW! |

arrowPlease enter a URL with http(s)
Apr 16 2018

How to Use Multiple Certificates When Load Testing Secure Websites

The X.509 certificate plays a very important role in software security assurance. This certificate is part of the public key infrastructure and it’s used to secure web services. The primary intended function of X.509 certificates is usage with TLS and SSL protocols, which provide a security layer for the application layer protocols, such as HTTP, IMAP, FTP, LDAP and others.  


There are many articles in the BlazeMeter blog dedicated to testing secure web services and using X.509 certificates. Server side X.509 certificates usage runs smoothly for Apache JMeter™ scripts, as the exchange of certificates is part of the communication flow over the above mentioned protocols. But when it’s necessary to provide a client side certificate from JMeter, it may take some effort in coding and changing JMeter’s configuration in order to simulate this type of secure communication.


”How to set your JMeter load test to use client side certificates” is one of the BlazeMeter articles on this subject. Another example is the article ”Take the pain out of load testing secure web services”, which shows how to sign and send a client certificate for communication over the SOAP / XML protocol. But these articles demonstrate how to use a single certificate in the request. This article will show how to deal with multiple certificates in the communication over the HTTPS (HTTP Secure) protocol.


What is the X.509 Certificate?


The X.509 certificate is the public key container. Signed by the certification authority (CA), it confirms that the private key belongs to the subject that created the public key. There are a few ways for a client to use certificates for authentication in multiple domains. One way is to get a specific certificate that has a list of domains. Domains covered by this certificate are specified in the ‘subjectAltName’ certificate attribute. If the covered domains are subdomains, then a record with the asterisk char can be used in the ‘subjectAltName’ certificate attribute.


But the number of domains that can be covered by one certificate is limited, so multiple certificates are stored either in one file, (for example the PEM file format allows this), or in the keystore. Sending a PEM file with all the certificates it contains for the sake of only one certificate is not a good idea. That’s why the certificates are stored in the keystore. The key store may contain multiple certificates that can be accessed by their aliases or by an index.


Adding Your Keystore to JMeter


The key store can be uploaded to JMeter via the SSL manager.


1. Select “Options” in the top menu.


2. Choose the “SSL manager” entry


3. In the file browser window select a keystore file.


Next time you run your test, the SSL Manager will examine your key store to see if it has at least one key available. If there is only one key, the SSL Manager will select it for you. If there is more than one key, it selects the first key.


But what if you need a few certificates to authenticate themselves against a few services in one test, and all the required certificates are in the keystore file?


Choosing a Certificate from the JMeter Property File


The first option is to point JMeter to the location of the certificate that is necessary for establishing the communication, in the keystore. The JMeter property file, jmeter.properties, has a few entries related to the keystore. The SSL section of this file has two entries that define the range of the keystore file from which JMeter loads certificates.


HTTPS load testing


By default, these parameters are set to 0, that’s why JMeter loads the first certificate from the keystore. If the keystore location is fixed and we know where the desired certificate is located in the keystore, we can change the https.keyStoreStartIndex and https.keyStoreEndIndex parameters in the jmeter.properties file accordingly to run multiple certificates.


Of course, you should not make changes directly in this file. The required settings should be added to the user.properties file. Every time JMeter starts, the settings defined in the user.properties file will be applied. If we need to select a certain certificate from the keystore for a script, we can change these settings by passing them in the command string, while launching JMeter, via the -J parameter. For example:


-J https.keyStoreStartIndex = 2 -J https.keyStoreStartIndex = 5


Don’t forget to change the https.use.cached.ssl.context parameter to false, if the number of certificates used by the script is more than 1. This can be done in the user.properties file or by passing this parameter in the command string, under the -J key.


-J https.use.cached.ssl.context = false


Choosing a Certificate from JMeter’s Keystore Configuration Element


A more flexible approach is to use JMeter’s keystore configuration element. (Add -> Config Element -> Keystore Configuration). This configuration element works with Java keystore files. In order to use it in your script, you have to provide the path to the Java keystore file with the required certificates and the password to the keystore. The path and the password are specified in the system.properties file. The best way to do it is to change these parameters in the command string. Parameter -D is used for this.


-D javax.net.ssl.keystore = <path_to_your_keystore>


-D javax.net.ssl.keystorePassword = <your_keystore_password>


Below is the screenshot of the keystore configuration element of a JMeter script.


load testing x509 certificates


We can see, that this configuration element contains the start and end indices of the keystore. JMeter will load the certificates from this. If we need to specify the alias of the certificate we need to use for client authentication, we should provide the variable name that contains this alias. If your script uses a few client certificates, their aliases can be assigned to this variable in the JSR223 preprocessor for the HTTP sampler that uses a client certificate. The example of this script is shown on the screenshot below.


jmeter for https load testing guide


In this script, the Keystore Configuration element is configured, as shown in the screenshot above. The variable that contains the certificate alias is defined in it and has the name ‘cert_aliases’. The HTTPS requests use different client certificates. The JSR223 preprocessor contains only one string of code, which assigns the alias of the proper certificate to this variable. As a result each HTTPS request will be using its own client certificate.


Let’s launch the script from the command line, passing all parameters mentioned above. After the script is executed, open the jmeter.log file and check the lines related to the SSL Manager. They show that two aliases are successfully loaded from the keystore. The screenshot of the log file is below:


running performance tests with jmeter on secure websites


That’s all about using multiple certificates. Learn more advanced JMeter from our free JMeter academy.


HTTPS Load Testing in BlazeMeter


If you need to collaborate on your tests and results and easily run your tests for many users (hundreds, thousands, hundreds of thousands and more), consider running your tests in BlazeMeter.


To do this, upload your JMX file to BlazeMeter and run your test in the cloud. You will get collaboration on tests and reports, scalability, advanced reporting and integration capabilities.


multiple security certificates in load testing tutorial


Try us out, just put your URL in the box below and your test will start in minutes. To learn more, request a BlazeMeter demo.

arrowPlease enter a URL with http(s)

Interested in writing for our Blog?Send us a pitch!