---
title: TestingBot Tunnel SSL Bumping, Certificates and TLS-Intercepting Proxies
description: 'How TestingBot Tunnel handles HTTPS: SSL bumping with the TestingBot
  CA, when to disable it with --nobump, certificate pinning, and trusting a corporate
  CA with --cacert-file.'
source_url:
  html: https://testingbot.com/support/tunnel/ssl-bumping
  md: https://testingbot.com/support/tunnel/ssl-bumping.md
---

# HTTPS through the tunnel

Two different certificate questions come up with a tunnel. Does the **cloud browser** trust the certificate your site presents? And does the **tunnel itself** trust the network it runs on? This page covers both.

## What SSL bumping does

By default, HTTPS traffic through the tunnel is intercepted and re-signed with the TestingBot CA. This is called SSL bumping.

Every TestingBot VM and device already trusts the TestingBot CA. Because the cloud browser sees a certificate it trusts, staging sites with self-signed or expired certificates load without certificate warnings, with no changes to your servers or tests.

Bumping on

Default

Self-signed, expired and internal-CA certificates just work.

Bumping off

`--nobump`

HTTPS is relayed as opaque bytes. The browser sees your server's real certificate, which it has to trust on its own.

## When to disable bumping

```bash
java -jar testingbot-tunnel.jar --nobump
```

- **WebSockets and Server-Sent Events.** Streaming protocols need `--nobump` together with `--nocache`. See the [FAQ](https://testingbot.com/support/tunnel/faq#websockets).
- **Certificate pinning** in a mobile app, see below.
- **Mutual TLS** , where your server expects a client certificate that a re-signing proxy cannot present.
- **Testing the certificate itself** , for example HSTS, certificate transparency or an expiry warning.

`--nobump` applies to the whole tunnel. If only one environment needs it, run a separate tunnel for that environment with its own [tunnel identifier](https://testingbot.com/support/tunnel/multiple).

## Certificate pinning

An app that pins its server certificate will reject the re-signed certificate. You have two options.

Trust the TestingBot CA

[Download the certificate](https://testingbot.com/downloads/testingbot-ssl-bumping.crt) and add it to your test build's trust store or pin set.

Disable bumping

Start the tunnel with `--nobump` so the app sees your server's real certificate.

## Networks that intercept TLS

The other direction: some corporate proxies intercept outgoing TLS and re-sign it with an internal certificate authority. Java does not trust that authority, so the tunnel cannot even register itself with TestingBot.

Point the tunnel at the authority's certificate, in PEM format. Repeat the option for several.

```bash
java -jar testingbot-tunnel.jar --proxy proxy.corp:8080 --cacert-file /etc/ssl/corp-ca.pem
```

- The certificate is **added** to the platform's trust store, not used instead of it, so public sites keep working.
- `--doctor` prints the subjects of the certificates it loaded, so you can confirm it picked up the right one.
- This affects what the tunnel process trusts. It does not change what the cloud browser trusts.

More on corporate networks: [upstream proxies](https://testingbot.com/support/tunnel/upstream-proxy) and [proxy authentication](https://testingbot.com/support/tunnel/authentication).

## Looking for more help?

Have questions or need more information? Reach out via email or Slack.

[Email us](https://testingbot.com/contact/new) [Join our Slack](https://join.slack.com/t/testingb0t/shared_invite/zt-3bcw9xch-jk19~6XPs_xBrsAgAedkCw)