Client certificates and custom roots

Client certificates for mutual TLS#

Some servers ask the client for a certificate during the TLS handshake. When WireLens decrypts such a host, it is WireLens that talks to the server, so WireLens needs the certificate.

On the Mac, open Settings ▸ Certificate ▸ Client certificates (mutual TLS) and import one for the host. WireLens accepts:

• a PKCS#12 bundle (.p12),
• a PEM certificate and key pair,
• a DER certificate (.cer or .der) with its key.

The private key goes into the Keychain and stays there by default. Export Identity writes a copy as PEM or PKCS#12 only after you confirm, and asks for a passphrase for PKCS#12.

Restart capture after importing so open connections pick up the new certificate.

Server certificate overrides#

Normally WireLens presents a certificate it issues from your root. A server certificate override presents one you hold instead. Use it when an app expects one specific certificate for a host and you have that certificate and its key.

Which certificate wins#

Both lists match hosts by pattern, and the most specific pattern wins:

api.example.com beats *.example.com, which beats *.

Bring your own root#

If your team runs an internal certificate authority, WireLens can sign decrypted traffic with it instead of the root it generated. Import the root, with its private key, from a PKCS#12 file. WireLens keeps the certificate with its settings and the private key in the Keychain, and uses it on the next start of capture. RSA and ECDSA roots both work.

Devices that already trust your internal root then trust WireLens's certificates with no extra setup, which is often the point.

Pinned applications#

WireLens measures pinning rather than guessing at it: a host that refuses the WireLens certificate twice is put on passthrough for the rest of the session. It keeps working, and it is still captured as a tunnel. See SSL Proxying.