SSL Interception

WePROXA intercepts HTTPS traffic only for rules you explicitly enable. After your device trusts the WePROXA Root CA, you can target interception in two ways:

• Host rules — match a hostname such as api.example.com or a wildcard such as *.example.com
• App rules — match the exact client application name shown in the Apps source view

This keeps inspection focused and lets you choose whether to decrypt traffic by destination, by app, or both.

Why Targeted SSL Rules?

Instead of blindly decrypting all HTTPS traffic, WePROXA lets you choose exactly what to inspect. This gives you:

• Better performance — only decrypt the traffic you care about
• Less noise — your request list stays focused on relevant hosts
• More control — easily toggle interception on/off per host or per app

Add a Host Rule

There are two ways to enable SSL interception for a host:

Certificate Menu (Toolbar)

1. Click the lock icon (Certificate) in the toolbar
2. Type a hostname in the input field (e.g., api.example.com)
3. Press Enter or click the + button
4. The host is added and SSL interception is enabled immediately

You can also use wildcard patterns like *.example.com to match all subdomains.

Right-Click a Request

1. Find a request in the request list from the host you want to inspect
2. Right-click the request to open the context menu
3. Click Enable SSL for {host}
4. SSL interception is enabled immediately for that host

This is the quickest way to enable SSL for a host you’re already seeing traffic from.

Add an App Rule

Use an app rule when you want to inspect HTTPS traffic from one specific client app, even if it talks to many different hosts.

1. Switch the sidebar to the Source View.
2. Expand Apps and find the client application you want to inspect.
3. Right-click the app and choose Enable SSL for {app}.
4. Traffic from that app is now eligible for HTTPS inspection and also appears under SSL Enabled Apps.

App rules match the exact app name shown in the sidebar. They do not support wildcard patterns.

TLS Passthrough Hosts

Use TLS passthrough when an app-wide SSL rule is useful, but certain domains should stay tunneled instead of decrypted. This is common for certificate-pinned hosts, identity providers, or services where you only need connection visibility.

1. Open Settings.
2. Go to Proxy Status.
3. Add hosts under TLS passthrough hosts, one per line or separated by commas.
4. Leave the field or press Cmd/Ctrl + Enter to save.

Bare domains include their subdomains: example.com matches example.com and api.example.com. Wildcards such as *.example.org are also accepted. Passthrough applies to app-wide SSL interception; an explicit host SSL rule still decrypts that host.

SSL Manager Window

For longer rule lists, open the standalone SSL Manager window from the certificate menu. The SSL Manager gives you a larger workspace for the same host and app interception rules.

From the SSL Manager you can:

• Add host rules such as api.example.com or *.example.com.
• Add app rules by application name or bundle identifier.
• Search across configured hosts and apps.
• Filter the list to All, Host, or App rules.
• Toggle or remove individual rules.
• Open certificate settings from the title bar.

The SSL Manager uses the same saved SSL rules as the toolbar certificate menu, so changes appear immediately across open windows.

Managing SSL Rules

Open the Certificate Menu (lock icon in the toolbar) to see all your configured SSL rules. From here you can:

• Toggle a host or app rule on/off using the checkbox
• Remove a host or app rule by clicking the trash icon
• Add new host rules using the input field
• Open SSL Manager when you want search, filters, or a larger detached window

To disable SSL for a host via the context menu, right-click a request from that host and select Disable SSL for {host}.

To disable an app rule, right-click the app again in the Apps source view and choose Disable SSL for {app}.

The Certificate Menu labels each rule as Host or App, and all SSL rules persist automatically between sessions.

Where SSL Rules Appear in the Sidebar

• SSL — hosts with SSL interception enabled
• SSL Enabled Apps — apps with SSL interception enabled, grouped as app → host → path
• Apps — all detected client applications, whether SSL is enabled or not

Prerequisites

Before SSL interception can decrypt HTTPS bodies, your device must trust the WePROXA Root CA certificate. On macOS, see Certificate Trust. On Windows, see Windows HTTPS Certificate Setup.

How WePROXA Trusts Upstream Servers

When WePROXA decrypts a host, it makes its own HTTPS connection to the origin server and must verify that server’s certificate. On macOS, WePROXA delegates this verification to the system trust store (the same trust the operating system uses), so anything Safari and other system apps trust is trusted here too. This also lets WePROXA fetch missing intermediate certificates automatically, so origins that ship an incomplete chain still verify instead of failing.

If you add a certificate to macOS system trust for a private or internal server, WePROXA picks it up without extra configuration.

Troubleshooting

HTTPS requests show as CONNECT tunnels

No matching host or app SSL rule is enabled. Add the host, enable SSL for the client app, or both.

Certificate errors after enabling SSL

Make sure the WePROXA Root CA is trusted. On macOS, see Certificate Trust. On Windows, see Windows HTTPS Certificate Setup.

Upstream server shows a certificate error

This means WePROXA could not verify the origin server’s certificate (separate from trusting the WePROXA Root CA). On macOS, verification uses the system trust store — if the server is internal or uses a private CA, add that CA to macOS system trust and try again.

Wildcard patterns

Use *.example.com to match all subdomains (e.g., api.example.com, cdn.example.com). The exact host example.com itself is not matched by a wildcard — add it separately if needed. Wildcards only apply to host rules, not app rules.

App rule does not match anything

Some traffic may not expose a stable client name and can appear under Unknown in the Apps source view. In that case, use a host rule instead.