Skip to content

Client Certificates

Some applications require a digital certificate installed in your browser to authenticate users, typically internal or enterprise applications with PKI (Public Key Infrastructure) or applications requiring mutual TLS (mTLS) security. Instead of entering a username and password, the browser presents a certificate that cryptographically proves your identity to the server.

Load Tester must be configured to use client certificates BEFORE recording or replaying. This guide shows you how to import certificates, configure them for recording and replay, and manage multiple certificates for load testing.

When You Need Client Certificates

You'll know your application uses client certificates if:

  • The browser prompts you to select a certificate when accessing the site
  • The application requires certificate installation before you can access it
  • The application is internal/enterprise with PKI infrastructure
  • The application documentation mentions "mutual TLS" (mTLS), "client certificates", or "certificate-based authentication"
  • The IT department provided you with a .p12 or .pfx certificate file

Common use cases:

  • Enterprise intranet applications with certificate-based authentication
  • Government applications requiring PIV/CAC smartcard certificates
  • Banking/financial applications with mutual TLS security
  • API endpoints requiring certificate-based authentication
  • VPN access portals with certificate authentication

Understanding Client Certificates

What Is Mutual TLS (mTLS)?

Normally, SSL/TLS is one-way authentication:

  1. Client (browser) connects to server
  2. Server presents its certificate to prove its identity
  3. Client validates the server certificate
  4. Encrypted connection is established

With mutual TLS (mTLS), authentication works both ways:

  1. Client connects to server
  2. Server presents its certificate
  3. Client validates the server certificate
  4. Server requests client certificate
  5. Client presents its certificate to prove its identity
  6. Server validates the client certificate
  7. Encrypted connection is established (both parties authenticated)

Client certificates provide stronger security than username/password authentication: certificates are cryptographically signed and cannot be forged, private keys are encrypted and password-protected, expiration and revocation can be enforced centrally, and users cannot share certificates as easily as they share passwords.

Certificate File Formats

Client certificates typically come in these formats:

Format Extension Description
PKCS#12 .p12 Most common format. Contains both the certificate and encrypted private key in a single file. Password-protected. This is what Load Tester expects.
PFX .pfx Microsoft variant of PKCS#12. Same format, different extension. Load Tester handles .pfx files.
PEM .pem, .crt Text-based format. If you receive separate .pem files (certificate + private key), you'll need to convert them to .p12 format.
DER .der, .cer Binary format. Less common for client certificates. Convert to .p12 if needed.

Load Tester requires PKCS#12 format (.p12 or .pfx files) because both the certificate and the private key are needed for authentication, and PKCS#12 bundles them into a single file.

Converting PEM to PKCS#12

If you have separate PEM files (certificate + private key), you can convert them to PKCS#12 using OpenSSL:

openssl pkcs12 -export -out certificate.p12 -inkey privatekey.pem -in certificate.pem

You'll be prompted to set a password for the .p12 file.

Password Protection

Client certificates are always password-protected to prevent unauthorized use if the certificate file is stolen. You'll need both:

  1. The certificate file (.p12 or .pfx)
  2. The password to decrypt the private key

When you import a certificate into Load Tester, you'll enter the password once. Load Tester stores it securely and uses it automatically during recording and replay.

Before You Begin

What you need:

  1. Client certificate file(s) in .p12 or .pfx format
  2. Certificate password(s) provided by your IT department or certificate authority
  3. Access to the application to test the certificate works in your browser first

Test the certificate in your browser before configuring Load Tester. This ensures:

  • The certificate file is valid
  • The password is correct
  • The application accepts the certificate
  • You understand the authentication workflow

Configuring Certificates for Recording

Before you can record a test case for an application that requires client certificates, you must import the certificate and configure Load Tester to present it during recording.

Step 1: Open Client Certificates Preferences

  1. Navigate to: Tools → Preferences (or Window → Preferences on macOS)
  2. Expand: Load Tester in the tree
  3. Select: Client Certificates

You'll see the Client Certificates preference page with two sections:

  • Recording: Which certificate to use when recording test cases
  • Replay: Which certificate(s) to use when replaying test cases or running load tests

Step 2: Import Your Certificate

In the Recording section:

  1. Click: Import button
  2. Browse to your .p12 or .pfx certificate file
  3. Select the certificate file and click Open
  4. Enter the certificate password when prompted
  5. Click OK

The certificate is now imported and appears in the Recording Certificate dropdown list.

Remember the Password

Keep a record of the certificate password. You'll need it again if you:

  • Import the certificate into Load Tester on a different machine
  • Re-import the certificate after reinstalling Load Tester
  • Configure datasets for multiple certificates

Step 3: Select the Certificate for Recording

  1. In the Recording section, use the Certificate dropdown to select the imported certificate
  2. Enter the password in the Password field
  3. Click: Test Password button to verify the password is correct

Expected result: You should see a message confirming the password is valid.

If the test fails:

  • Double-check the password (passwords are case-sensitive)
  • Re-import the certificate if the test continues to fail
  • Verify the certificate file isn't corrupted

Step 4: Apply and Record

  1. Click: Apply to save your settings
  2. Click: OK to close the Preferences dialog
  3. Start recording your test case normally

During recording, Load Tester's browser proxy will automatically present the client certificate to the server during the SSL/TLS handshake. The server will validate the certificate and allow access to the application.

No Browser Prompt During Recording

When you navigate to the application during recording, the browser should NOT prompt you to select a certificate. Load Tester's proxy automatically presents the certificate you configured. If you still see a browser prompt, the certificate may not be configured correctly. Verify the Preferences settings.

Configuring Certificates for Replay

After recording, you need to configure which certificate(s) Load Tester will present when replaying the test case or running a load test. You have two options:

Option 1: Shared Certificate (Single-User Replays)

When to use:

  • Single-user replays for debugging
  • Small load tests where all virtual users can share the same certificate
  • Applications where the certificate identifies the application (not individual users)

How it works: All virtual users present the same client certificate during replay.

Configuration:

  1. Open Client Certificates Preferences: Tools → Preferences → Load Tester → Client Certificates
  2. In the Replay section, select "Use single certificate for all virtual users" (or leave Dataset field empty)
  3. Select certificate from the dropdown
  4. Enter password
  5. Click: Test Password to verify
  6. Click: Apply and OK

Option 2: Dataset with Multiple Certificates (Load Testing)

When to use:

  • Load testing with realistic user simulation
  • Applications where each certificate identifies an individual user
  • Compliance requirements for unique credentials per virtual user
  • Applications that don't support concurrent sessions with the same certificate

How it works: Each virtual user gets a unique certificate from a dataset. The dataset maps certificate filenames to passwords.

Advantages:

  • Simulates real-world usage (each user has their own certificate)
  • Avoids server-side conflicts from reusing the same certificate
  • Meets compliance requirements for unique authentication per user

Step-by-Step: Configure Dataset for Multiple Certificates

Step 1: Import All Certificates

First, import all the certificates you'll use during the load test:

  1. Open Client Certificates Preferences: Tools → Preferences → Load Tester → Client Certificates
  2. In the Recording section, click Import for each certificate file
  3. Enter the password for each certificate when prompted
  4. Repeat until all certificates are imported

Certificate Location

Load Tester stores imported certificates in its workspace. You don't need to keep the original .p12/.pfx files after import, but it's good practice to back them up in case you need to reinstall Load Tester or move to a different machine.

Step 2: Create the Dataset

Create a dataset with two columns:

Column Name Description
filename The certificate filename (e.g., user1.p12, user2.p12)
password The password for that certificate

Example dataset (CSV format):

filename,password
user1.p12,P@ssw0rd1
user2.p12,P@ssw0rd2
user3.p12,P@ssw0rd3
user4.p12,P@ssw0rd4
user5.p12,P@ssw0rd5

To create the dataset:

  1. Navigate to: File → New → Dataset
  2. Enter dataset name: e.g., ClientCertificates
  3. Add two columns: filename and password
  4. Add rows: One row for each certificate
  5. Fill in values: Certificate filenames and their corresponding passwords
  6. Save the dataset

See Datasets & Data-Driven Testing for detailed instructions on creating and managing datasets.

  1. Open Client Certificates Preferences: Tools → Preferences → Load Tester → Client Certificates
  2. In the Replay section:
  3. Dataset: Select the dataset you just created (e.g., ClientCertificates)
  4. Client Certificate: Select the dataset column containing filenames (e.g., filename)
  5. Password: Select the dataset column containing passwords (e.g., password)
  6. Click: Test Passwords to validate all certificate/password pairs

Expected result: Load Tester will test each certificate/password combination in the dataset and report success or failure.

Testing Can Take Several Minutes

Depending on the number of certificates in your dataset, testing all passwords could take several minutes. Load Tester must decrypt each certificate to validate the password, which is a computationally expensive operation.

  1. If all tests pass, click Apply and OK
  2. If tests fail:
  3. Verify the certificate filenames in the dataset exactly match the imported certificate filenames (case-sensitive)
  4. Double-check passwords (case-sensitive)
  5. Ensure all certificates are imported into Load Tester

Step 4: Verify During Replay

Run a small replay test (2-5 virtual users) to verify the certificate configuration works:

  1. Run a replay with multiple virtual users
  2. Check the Replay View: All transactions should succeed (green)
  3. If you see SSL or authentication errors:
  4. Verify certificates are configured correctly in Preferences
  5. Check that the dataset has enough rows for the number of virtual users
  6. Use Headers View to inspect SSL/TLS negotiation details

Troubleshooting Certificate Issues

Password Test Fails

Symptom: When you click "Test Password", Load Tester reports the password is incorrect.

Likely causes:

  1. Wrong password (passwords are case-sensitive)
  2. Corrupted certificate file
  3. Wrong certificate file (you imported a different certificate than you intended)

Solution:

  • Double-check the password with your IT department or certificate authority
  • Try importing the certificate again from the original file
  • Verify the certificate file is valid by testing it in your browser first
  • Check for extra spaces in the password field (common copy/paste error)

Browser Still Prompts for Certificate During Recording

Symptom: During recording, the browser displays a certificate selection prompt, even though you configured the certificate in Load Tester Preferences.

Likely causes:

  1. Certificate not applied (forgot to click Apply/OK in Preferences)
  2. Wrong certificate selected (selected a different certificate than the application requires)
  3. Recording preferences not refreshed (browser proxy not using updated settings)

Solution:

  • Close the browser and stop recording
  • Re-open Client Certificates Preferences and verify the certificate is selected
  • Click Apply and OK to ensure settings are saved
  • Start a new recording session
  • If prompt persists: The application may require a different certificate than you imported. Verify with your IT department

SSL Handshake Failures During Replay

Symptom: Replay fails with SSL/TLS errors like "SSL handshake failed", "peer not authenticated", or "unable to find valid certification path".

Likely causes:

  1. Certificate not configured for replay (only configured for recording)
  2. Dataset misconfigured (wrong column names, missing passwords)
  3. Expired certificate
  4. Server doesn't trust the certificate

Solution:

  • Verify Replay section in Client Certificates Preferences is configured (not just Recording section)
  • If using a dataset: Run Test Passwords to validate all certificates
  • Check certificate expiration: Certificates have expiration dates, so verify they're still valid
  • Verify server configuration: Ensure the server trusts the certificate authority that issued the certificate

Ask the AI to Diagnose SSL Errors

If you're getting SSL/TLS errors during replay:

My replay is failing with "SSL handshake failed" errors. I configured
a client certificate but it's still not working. Can you help diagnose
the issue?

The AI can:

  • Check if certificates are configured for both recording AND replay
  • Verify dataset configuration (column names, password mapping)
  • Identify certificate expiration or trust issues
  • Analyze Headers View for SSL/TLS negotiation details
  • Suggest specific configuration fixes

Dataset Has Wrong Number of Certificates

Symptom: Load test fails because more virtual users are requested than certificates available in the dataset.

Example: You have 5 certificates in your dataset but try to run a load test with 100 virtual users.

Solution:

Option 1: Add more certificates (recommended for realistic simulation)

  • Obtain additional client certificates from your IT department
  • Import them into Load Tester
  • Add rows to your dataset for the new certificates
  • Re-run Test Passwords to validate

Option 2: Configure dataset to reuse certificates

  • Dataset Properties → Random Access: Disable "prevent row from being used more than once"
  • This allows multiple virtual users to share the same certificate
  • Warning: Some applications don't handle concurrent sessions with the same certificate correctly, so test carefully

Certificate Works in Browser But Not Load Tester

Symptom: The certificate works fine when you access the application in a regular browser, but fails during Load Tester recording or replay.

Likely causes:

  1. Certificate not imported into Load Tester (you only installed it in your browser)
  2. Browser using a different certificate than you think (browser may have multiple certificates installed)
  3. Certificate chain incomplete (intermediate certificates missing)

Solution:

  • Export the certificate from your browser to a .p12 file, then import it into Load Tester
  • Verify which certificate the browser uses: Check browser's certificate manager to see which certificate is selected for the site
  • Ensure complete certificate chain: Some applications require intermediate certificates in addition to the client certificate. Consult your IT department

Ask the AI to Explain Certificate Configuration

If you're confused about certificate configuration:

I have a .p12 certificate file and password. Can you walk me through
exactly how to configure it in Load Tester for recording and replay?

The AI can:

  • Provide step-by-step configuration instructions
  • Explain the difference between Recording and Replay sections
  • Guide you through dataset creation for multiple certificates
  • Clarify certificate file format requirements
  • Answer specific questions about your setup

Best Practices

1. Test Certificates in Browser First

Why: Verifying the certificate works in a regular browser ensures the certificate file and password are valid before attempting to configure Load Tester.

How:

  1. Install the certificate in your browser (browser-specific process)
  2. Navigate to the application and verify you can access it
  3. Only then: Import the certificate into Load Tester

2. Use Datasets for Load Testing

Why: Using unique certificates for each virtual user simulates real-world usage and avoids server-side conflicts from reusing the same certificate.

How:

  • Obtain multiple client certificates from your IT department (one per virtual user, or at least enough to avoid excessive reuse)
  • Create a dataset mapping certificate filenames to passwords
  • Configure the Replay section to use the dataset

3. Keep Certificate Passwords Secure

Why: Client certificates provide strong authentication, but only if the passwords remain secret.

How:

  • Store passwords securely (password manager or secure documentation)
  • Don't commit datasets to version control if they contain plaintext passwords
  • Use workspace encryption if your Load Tester workspace is stored on shared storage
  • Consider using environment variables for passwords instead of hardcoding them in datasets (advanced configuration)

4. Monitor Certificate Expiration

Why: Client certificates have expiration dates. Expired certificates will cause SSL handshake failures during load tests.

How:

  • Track expiration dates for all certificates used in load testing
  • Renew certificates before they expire
  • Update datasets with new certificates when renewed
  • Re-import certificates into Load Tester after renewal

5. Test with Small Replays Before Load Testing

Why: Certificate configuration errors are easier to diagnose with 2-5 virtual users than with 100+ virtual users generating thousands of SSL errors.

How:

  1. Configure certificates for replay
  2. Run a small replay (2-5 virtual users)
  3. Verify all transactions succeed (green in Replay View)
  4. Only then: Scale up to full load test

Next Steps

After configuring client certificates, verify your test case replays successfully:

If your application uses additional authentication methods:

For load testing configuration: