UnityWebRequest Custom Certificate Validation: Missing Env Toggle

Short answer

A global AllowInsecureCertificates flag scoped to a domain list would centralize logic that today lives in ad-hoc CertificateHandler subclasses, but it would not remove the underlying risk: any bypass that ships in a release binary is exploitable, and on iOS 15+ the platform can reject an incomplete chain before your handler's return value matters. A flag changes who can make the mistake, not whether the mistake is possible.

What is confirmed vs. likely

Confirmed behavior (well-established): UnityWebRequest has no built-in environment toggle. Accepting a self-signed certificate requires subclassing CertificateHandler and overriding ValidateCertificate(byte[]), then assigning it to unityWebRequest.certificateHandler. There is no public SetInsecureDomains API in current Unity LTS lines.

Likely, but verify on device: The claim that iOS 15+ rejects incomplete chains even when ValidateCertificate returns true is plausible — App Transport Security and the native URL loading stack perform their own evaluation, and Unity's handler sits on top of platform TLS behavior that differs per backend (NSURLSession on iOS, platform-specific stacks on Android and Windows). Treat the exact iOS interaction as needs device verification; do not design around it from documentation alone.

Consequences of a global domain-scoped flag

• Leakage surface: a static/global flag persists for the process lifetime. One code path that forgets to reset it, or a config file accidentally bundled into a release build, silently disables validation for the whole app.
• Matching ambiguity: domain lists invite wildcards (*.staging.example.com), and wildcard or suffix matching can be abused via DNS rebinding/spoofing in hostile networks — exactly the networks where TLS matters most.
• False confidence on iOS: if the platform enforces chain completeness independently, the flag's behavior diverges per platform, which is the problem you were trying to solve.

Safe gating pattern (works today, no new API needed)

Gate the handler at compile time so the bypass code is not present in release binaries at all:

public class DevCertHandler : CertificateHandler
{
    protected override bool ValidateCertificate(byte[] certificateData) => true;
}

UnityWebRequest req = UnityWebRequest.Get(url);
#if DEV_INSECURE_TLS
// Only defined in a dedicated dev build configuration, never in release.
if (IsAllowedDevHost(req.uri.Host))
    req.certificateHandler = new DevCertHandler();
#endif

Key properties of this pattern:

1. Compile-time, not runtime: a runtime config file can ship by accident; a stripped #if block cannot. Verify by building a release player and confirming the define is unset.
2. Exact-host allowlist, no wildcards: compare against a fixed set of staging hostnames with ordinal string equality.
3. Per-request, not global: the handler is attached to one request, so there is no process-wide state to leak.

Would SetInsecureDomains help?

Marginally, as ergonomics — but only if it were implemented as per-request, exact-host, and compiled out of release builds by default. A global static method would reproduce every risk above with a friendlier name. Until such an API exists, the conditional-compilation handler above achieves the same result with stronger guarantees.

One diagnostic worth checking

Before relying on any bypass for iOS staging: log inside ValidateCertificate on a physical iOS 15+ device against your staging server. If the callback never fires and the request still fails, the platform is rejecting the chain independently, and no Unity-level flag will fix it — you would need a properly chained staging certificate instead.