Troubleshooting

Last updated: Apr 24, 2026

If your issue is not listed here, contact the Fluid Attacks support team at [email protected].

SSL Handshake failure — Plugin cannot connect to the platform

Symptoms

The plugin fails to validate the API token and displays a connection error. No vulnerabilities are loaded. The following error appears in the IDE logs (Help > Show Log in Explorer/Finder):

ApolloNetworkException: Failed to execute GraphQL http network request
Caused by: javax.net.ssl.SSLHandshakeException: (certificate_unknown)
PKIX path building failed: unable to find valid certification path to requested target

What this error is NOT

This is not a problem with the API token, plugin logic, or the Fluid Attacks platform. The error occurs at the network layer, before any data is transmitted.

Cause

The error is caused by a corporate HTTPS proxy with SSL inspection (e.g., Zscaler, Netskope, Forcepoint) intercepting the connection between IntelliJ and app.fluidattacks.com.

When SSL inspection is active, the proxy replaces the server's original certificate with one signed by the organization's own Certificate Authority (CA). The JVM (Java Virtual Machine) used by IntelliJ maintains its own certificate trust store (cacerts), which is separate from the operating system's certificate store. If the corporate proxy's root CA certificate is not present in the JVM's cacerts, the JVM rejects the connection.

# Current behavior (connection rejected)
IntelliJ (JVM) → Proxy (intercepts and re-signs certificate) → app.fluidattacks.com
                    ↑
    JVM does not recognize the proxy's CA → connection blocked

# Expected behavior
IntelliJ (JVM) → Proxy (passthrough, no interception) → app.fluidattacks.com
                    ↑
    JVM receives the original certificate from a public CA → connection accepted

Solution — Add an SSL inspection bypass for the Fluid Attacks domain

The network administrator should add an SSL inspection bypass (exclusion) for the following domain in the corporate proxy:

app.fluidattacks.com

This tells the proxy to pass HTTPS traffic to this domain through without intercepting or re-signing it. The JVM will then receive the original certificate issued by a trusted public CA and the connection will succeed for all users automatically.

This type of bypass is standard practice for trusted SaaS and security vendors and is supported by all major proxy solutions (Zscaler, Netskope, Forcepoint, etc.). It is applied once from the central console and requires no changes on individual machines.

Another option is manual certificate import

Importing the corporate proxy's certificate manually into the JVM's cacerts is an alternative, but it is fragile and does not scale:

• IntelliJ bundles its own JBR (JetBrains Runtime), whose cacerts path differs from the system JVM and may change with IDE updates.
• It requires administrator access and must be repeated on every user machine and after every IntelliJ update.
• If the corporate proxy rotates its CA certificate, all imports must be redone.

The SSL bypass is the recommended solution because it is centralized, permanent, and does not require touching individual machines.

User-side workaround

If the SSL bypass cannot be configured immediately, users can apply the following options in order.

Quick option — Use the operating system truststore

Instead of importing certificates manually, IntelliJ can be configured to trust the certificates already installed in the operating system:

1. Go to Help → Edit Custom VM Options.

2. Add the following line for your operating system:

   macOS:

   -Djavax.net.ssl.trustStoreType=KeychainStore

   Windows:

   -Djavax.net.ssl.trustStoreType=Windows-ROOT

3. Restart IntelliJ.

If the error persists, proceed with the manual import below.

Manual import option — Obtain the corporate CA certificate

Your IT team should provide the root certificate of the corporate CA (a .crt, .cer, or .pem file). In many cases it is already installed in the operating system.

Option A — Export from the operating system

Windows:

1. Open certmgr.msc (Certificate Manager).
2. Navigate to Trusted Root Certification Authorities → Certificates.
3. Locate the corporate certificate (it usually carries the company name).
4. Right-click → All Tasks → Export → select Base-64 encoded X.509 (.CER).
5. Save as corporate-ca.crt.

macOS:

# Export corporate CAs from the system keychain
security find-certificate -a -p /Library/Keychains/System.keychain > corporate-ca.pem

Or open Keychain Access → find the corporate certificate → export as .pem.

Option B — Export from the browser

1. Open a browser and navigate to app.fluidattacks.com.
2. Click the padlock in the address bar → Certificate → Details.
3. Select the root certificate (the topmost entry in the chain).
4. Export as Base-64 encoded X.509.

Step 1 — Locate the JRE used by IntelliJ

IntelliJ bundles its own JBR (JetBrains Runtime). The truststore path varies by operating system:

To confirm which JRE is active: Help → Find Action → "Choose Boot Java Runtime".

Step 2 — Import the certificate into the JRE truststore

keytool is bundled with the JRE and requires no additional installation.

macOS / Linux:

# sudo required if the directory is read-only
sudo keytool -import \
  -alias corporate-ca \
  -keystore "/Applications/IntelliJ IDEA.app/Contents/jbr/lib/security/cacerts" \
  -file /path/to/corporate-ca.crt \
  -storepass changeit \
  -noprompt

Windows (cmd run as Administrator):

keytool -import ^
  -alias corporate-ca ^
  -keystore "C:\Program Files\JetBrains\IntelliJ IDEA <version>\jbr\lib\security\cacerts" ^
  -file C:\path\to\corporate-ca.crt ^
  -storepass changeit ^
  -noprompt

The default truststore password is changeit.

To verify the certificate was imported successfully:

keytool -list -keystore <cacerts_path> -storepass changeit | grep corporate-ca

Step 3 — Restart IntelliJ

Close IntelliJ completely and reopen it for the changes to take effect.