Troubleshooting — TLS Proxies and Trust Stores

If your TLS connection to Synura completes but messages never arrive — or the connection resets immediately after handshake — the problem is almost always your network intercepting the traffic or your trust store missing the required root certificate.

---

TLS-intercepting proxies

Symptoms

• TLS handshake succeeds, but Synura never receives messages
• Connection resets shortly after handshake
• Certificate in the handshake shows your organisation’s internal CA, not Let’s Encrypt
• openssl s_client shows a different certificate fingerprint than expected

Cause

Many enterprise networks run a TLS-intercepting proxy (Zscaler, Palo Alto, Bluecoat, etc.) that terminates and re-encrypts traffic on port 443. The proxy decrypts your Synura Connect traffic, sees binary/non-HTTP data, and either drops it or resets the connection.

Diagnosis

From the server running your integration engine, check the certificate Synura presents:

openssl s_client -connect {subdomain}.synura.io:443 -servername {subdomain}.synura.io 2>/dev/null | openssl x509 -noout -issuer -fingerprint

Expected output:

issuer=C = US, O = Let's Encrypt, CN = R11
SHA1 Fingerprint=...

If the issuer is not Let’s Encrypt — for example, if it shows your company’s internal CA or a proxy vendor name — your traffic is being intercepted.

Fix

Add *.synura.io to your proxy’s bypass list so that traffic to Synura is not intercepted. This is typically configured in your proxy’s admin console or via Group Policy.

The specific steps depend on your proxy:

Proxy	Where to configure
Zscaler	ZIA Admin Portal > SSL Inspection > Do Not Inspect > add *.synura.io
Palo Alto	Decryption Policy > No Decrypt rule for *.synura.io
Bluecoat / Symantec	SSL Interception Policy > bypass for *.synura.io
Fortinet	SSL/SSH Inspection > Exempt > add *.synura.io

Contact your network team if you don’t have access to the proxy configuration.

Caution

Do not attempt to import your proxy’s internal CA certificate as a workaround. Even if the TLS handshake succeeds, the proxy will still interfere with the MLLP binary protocol and messages will not be delivered.

---

Trust store issues

When this matters

Synura’s certificate is issued by Let’s Encrypt using the ISRG Root X1 root certificate. This root is trusted by default in:

• Windows (all supported versions)
• macOS (10.12.1+)
• Ubuntu (16.04+), Debian (9+), RHEL/CentOS (7.4+)
• Java (8u101+, all current LTS releases)

If you’re running a current OS and Java version, you should not need to do anything. This section is for environments with restricted or custom trust stores — common in large enterprise Java deployments.

Symptoms

• SSLHandshakeException: PKIX path building failed
• unable to find valid certification path to requested target
• SSL certificate problem: unable to get local issuer certificate
• openssl s_client shows Verify return code: 20 (unable to get local issuer certificate)

Diagnosis — Java trust store

Check whether the ISRG Root X1 certificate is in your Java trust store:

keytool -list -cacerts -alias isrgrootx1

If this returns keytool error: java.lang.Exception: Alias <isrgrootx1> does not exist, the certificate is missing.

Note

The -cacerts flag works on Java 9+. For Java 8, specify the trust store path explicitly:

keytool -list -keystore "$JAVA_HOME/lib/security/cacerts" -alias isrgrootx1

The default password is changeit.

Fix — Import ISRG Root X1

1. Download the root certificate:

curl -o isrgrootx1.pem https://letsencrypt.org/certs/isrgrootx1.pem

2. Import it into the Java trust store:

# Java 9+
sudo keytool -importcert -cacerts -alias isrgrootx1 -file isrgrootx1.pem -noprompt

# Java 8
sudo keytool -importcert -keystore "$JAVA_HOME/lib/security/cacerts" \
  -storepass changeit -alias isrgrootx1 -file isrgrootx1.pem -noprompt

3. Restart your integration engine or application server.

4. Verify the import:

keytool -list -cacerts -alias isrgrootx1

You should see:

isrgrootx1, ..., trustedCertEntry

Fix — System trust store (non-Java)

If you’re connecting from a non-Java application and your OS trust store is missing the root:

Ubuntu / Debian:

sudo apt install ca-certificates
sudo update-ca-certificates

RHEL / CentOS:

sudo yum install ca-certificates
sudo update-ca-trust

Windows: The ISRG Root X1 certificate is distributed via Windows Update. Run Windows Update if your trust store is out of date.

---

Still stuck?

Contact support@synura.io with:

• Your subdomain
• The output of the openssl s_client command above
• Any error messages from your integration engine or application
• Whether you’re behind a corporate proxy (and which one, if known)