Intercepting Java Application Traffic: A Pentester's Guide to Certificate Woes

As a penetration tester, few things are more frustrating than firing up Burp Suite, configuring your proxy, and then watching Java applications completely ignore your interception attempts. While web browsers play nice with proxy certificates, Java applications seem determined to make your life difficult.  

At Schellman, we help business leaders like you navigate this challenge on a weekly basis and we’re here to explain how to win this battle. In this article, we’ll explore why Java applications break your testing setup, how to locate where the Java application stores its trust certificates, steps to export the Burb certificate and import it to the Java trust store, and more.  

Why Java Applications Break Your Testing Setup 

When you're conducting web application penetration tests, you rely on intercepting HTTPS traffic to analyze requests, modify parameters, and identify vulnerabilities. But Java applications have a nasty habit of throwing SSL/TLS errors the moment you try to proxy their traffic. 

Here's what's happening behind the scenes: Java applications don't trust your Burp Suite CA certificate, no matter how properly you've configured your browser or system certificate store. 

Unlike browsers that use your operating system's certificate store, Java applications maintain their own isolated trust store. Even worse, many thick client applications ship with their own embedded Java runtime, completely bypassing your system's Java installation. 

This means your carefully configured Burp certificate that works perfectly for browser testing becomes useless for Java application assessment. 

The Reconnaissance Phase: Finding the Right Certificate Store 

Before you can intercept traffic, you need to locate where the Java application stores its trusted certificates. This requires some digital forensics. 

Method 1: Application Directory Analysis 

Start by examining the target application's installation directory. Look for these telltale signs of an embedded Java runtime: 

Common certificate store locations include:

• C:\Program Files\YourTarget\jre\lib\security\cacerts
• C:\Program Files\YourTarget\jdk\lib\security\cacerts
• C:\Program Files\YourTarget\runtime\lib\security\cacerts

Pro tip: Use PowerShell or command line tools to recursively search for cacerts files: 

Method 2: Runtime Analysis 

For a more forensic approach, monitor the application's Java process to see which keystore it's actually using:

The debug output will explicitly show you which cacerts file Java is loading—pure gold for your assessment. 

Exporting the Burp Certificate and Importing it to the Java Trust Store 

Step 1: Export Your Burp CA Certificate 

In Burp Suite: 

1. Go to Proxy→ Options→ Proxy Listeners
2. Click: Import/export CA certificate
3. Export in DER format (this is crucial - Java prefers DER over PEM)
4. Save as something like burp-ca.der

Step 2: Importing the certificate to the Java Trust Store 

Now you'll use Java's own keytool utility to add your Burp certificate to the application's trust store. The key is using the keytool from the same Java installation the application uses. 

Note: The default password for Java keystores is changeit (yes, really). Most applications never change this. 

Step 3: Verify the Import 

Confirm your certificate is now trusted: 

You should see your burp-ca alias in the output. 

Intercepting Traffic 

With the certificate installed, restart the Java application completely. Java only reads the keystore at startup, so this step is critical. 

Configure your testing setup: 

1. Burp Proxy: Running on 127.0.0.1:8080 (or your preferred port)
2. Application Proxy Settings: Point to your Burp listener
3. System Proxy (if the app uses system settings): Also pointing to Burp

The application should now happily accept your Burp certificate and allow full HTTPS interception. 

When the Target Fights Back: Certificate Pinning 

Sometimes, even after perfect certificate installation, the application still refuses your traffic. You've likely encountered certificate pinning—a defensive technique that bypasses the trust store entirely. 

Signs you're dealing with certificate pinning: 

• SSL errors persist despite proper certificate installation 
• Application works fine with direct internet but fails through proxy 
• Error messages mentioning "certificate verification failed" or similar 

Bypassing Certificate Pinning 

For penetration testing purposes, you have several options to bypass certificate pinning: 

1. Application-Level Bypass:

• Look for configuration files that might disable pinning in debug/test modes
• Search for command-line flags like -Dcom.sun.net.ssl.checkRevocation=false

2. Runtime Manipulation:

• Use tools like SSL Kill Switch (mobile)
• Frida scripts for runtime SSL bypass
• Java SSL bypass tools for thick clients
  

3. Binary Modification:

• Decompile and patch the application (if legally permitted in your engagement) 
• Replace pinned certificates with your Burp certificate 

Techniques for Stubborn Applications 

Multiple Certificate Stores 

Some enterprise applications use multiple Java installations or custom certificate stores. If your first attempt fails: 

1. Process Monitor: Watch file system access to identify all certificate stores being used
2. Multiple Imports: Add your certificate to every cacerts file you find
3. Environment Variables: Check if the app sets custom javax.net.ssl.trustStore properties

Custom Trust Store Paths 

Look for application configurations that specify custom truststore locations: 

Operational Considerations 

Remember these important points during your engagement: 

1. Backup Original Files:
   Always backup the original cacerts before modification: 

2. Clean Up After Testing:
   Remove your certificates when the engagement concludes: 

3. Document Your Changes:
   Keep detailed notes of which certificate stores you modified for your final report. 

Troubleshooting Common Issues 

Application still shows SSL errors: 

• Verify you're using the correct Java installation 
• Check if the app uses a custom certificate store location 
• Look for certificate pinning implementations 

Certificate import fails: 

• Ensure you're using DER format (not PEM) 
• Verify the keystore password (might not be the default changeit) 
• Check file permissions on the cacerts file 

Traffic still not intercepted: 

• Confirm the application is actually using your proxy settings 
• Verify Burp is listening on the correct interface and port 
• Check for alternative network libraries that bypass system proxy settings 

Intercepting Java Traffic for Deeper Security Testing

Successfully intercepting Java application traffic is often the difference between a surface-level assessment and deep application security testing. While Java's certificate handling can be frustrating, understanding these techniques allows you to analyze thick client applications, mobile app backends, and enterprise Java services with the same thoroughness as web applications. 

The key is patience and methodical reconnaissance. Once you've identified the correct certificate store and successfully imported your CA certificate, you'll have full visibility into the application's HTTPS communications, enabling comprehensive security assessment. 

Remember: with great power comes great responsibility. Only use these techniques on applications you're authorized to test and always clean up your modifications when the engagement is complete. 

If you have additional questions about how to secure a successful pen test, contact us today and we’ll get back to you shortly.