iOS Client Fails to Trust CA Certificate in WireGuard Mode Despite Full Trust

Problem Description

When running mitmproxy in WireGuard mode, an iOS client fails to trust the mitmproxy CA, resulting in certificate errors for all HTTPS sites. This occurs even after the CA certificate has been installed as a profile and explicitly enabled for "Full Trust for Root Certificates" in iOS settings.

A separate Linux client connects to the same mitmproxy server, trusts the CA system-wide, and can browse all HTTPS sites without any issues, confirming the server-side setup is functional.

Steps to Reproduce

1. Server Setup (proxy host):

   • Debian 12 LXC container.
   • mitmproxy 12.2.0 (standalone Linux binary) is installed.
   • wireguard-tools is installed.
   • mitmproxy is started as a systemd service in WireGuard mode: ExecStart=/usr/local/bin/mitmweb --mode wireguard --web-host 0.0.0.0

2. Working Linux Client Setup (prox-test host):

   • A separate Debian 12 LXC container.
   • The mitmproxy-ca-cert.pem from the server is copied to /usr/local/share/ca-certificates/mitmproxy.crt.
   • update-ca-certificates is run, successfully adding the CA to the system trust store.
   • The client connects to the mitmproxy WireGuard server using the generated configuration.
   • Result: curl -L https://example.com and other HTTPS sites work perfectly. Traffic is visible in the mitmweb UI.

3. Failing iOS Client Setup (iPhone):

   • The QR code generated by mitmproxy is scanned and the WireGuard profile is successfully installed and connected.
   • The mitmproxy-ca-cert.pem file is installed on the iPhone, under Settings > General > VPN & Device Management.
   • In Settings > General > About > Certificate Trust Settings, the switch for the "mitmproxy" root certificate is toggled ON.
   • The WireGuard VPN is active. DNS requests and other initial flows from the iPhone are visible in the mitmweb UI.

Observed Behavior

When opening Safari on the iPhone and navigating to any HTTPS site (e.g., https://example.com), the browser displays a "Connection Not Private" error.

Inspecting the certificate details on the error page correctly shows that the certificate for example.com is issued by the "mitmproxy" CA. However, the details also explicitly state that the certificate is "Not Trusted".

Expected Behavior

After enabling "Full Trust" for the mitmproxy root certificate in iOS settings, the browser should trust the certificates generated by mitmproxy and load HTTPS pages without error.

Troubleshooting Steps Taken

• Cleared Safari history and website data.
• Performed a "Reset Network Settings" on the iPhone.
• Removed and re-installed both the WireGuard profile and the CA certificate profile multiple times.
• Verified the correct DNS server (10.0.0.53) is being assigned by the WireGuard configuration.
• Blocked outgoing UDP traffic on ports 80 and 443 on the proxy host to rule out QUIC interference.

The issue persists despite all these steps. The core problem appears to be that iOS is ignoring the "Full Trust" setting for this specific CA when the traffic is routed through the WireGuard VPN.

I'm not sure if this is an iOS bug or not.

System Information

Mitmproxy: 12.2.0 binary
Python:    3.14.0
OpenSSL:   OpenSSL 3.5.4 30 Sep 2025
Platform:  Linux-6.8.4-3-pve-x86_64-with-glibc2.36

Checklist

• This bug affects the latest mitmproxy release.

No repository file, test, or entry point is identified. Start by reproducing the reported WireGuard setup with the iOS CA profile and compare it with the working Linux client, then determine whether the behavior is controlled by mitmproxy or iOS. Done would be a confirmed root cause with a concrete repository change or a documented external limitation.