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

java -jar testingbot-tunnel.jar --nobump

WebSockets and Server-Sent Events. Streaming protocols need --nobump together with --nocache. See the FAQ.
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.

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 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.

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 and proxy authentication.