A regional bank with 40 branches must inspect outbound HTTPS for malware while preserving privacy for banking apps via an allow-list, and auditors require no browser warnings for users. Edge routers will perform decrypt-and-inspect for selected flows. Which certificate handling for SSL/TLS proxy meets the decrypt-and-inspect requirement?
Select an answer to reveal the explanation.
Short Explanation
You've got to earn that browser trust before you peek inside encryption. A subordinate CA lets your Edges impersonate sites cleanly while clients already trust your root. It's like a hall monitor with a master badge everyone recognizes.
Full Explanation
SSL/TLS proxy works by having the WAN Edge terminate the client TLS session and originate a second session to the server, which requires the Edge to present a certificate the client trusts for the requested hostname, so best practice is to create a subordinate or issuing CA certificate signed by the enterprise root PKI, install it on the Edges designated as proxy, and ensure endpoints trust the enterprise root through group policy or MDM; selective decrypt with allow-lists then exempts banking or health categories to preserve privacy. Using a public internet CA certificate fails because public CAs will not issue a subordinate capable of impersonating arbitrary domains and its use would break audit control, generating isolated self-signed certificates without distributing trust fails because every client will raise warnings and helpdesk tickets, and reusing the SD-WAN Controller certificate, formerly vSmart, fails because that identity is for control-plane authentication and is not trusted by browsers as a web issuing CA nor scoped for proxy signing. Exam caveat: distinguish proxy CA handling from controller and device certificates used for DTLS/TLS to controllers. Practical check: verify the proxy CA under security configuration in SD-WAN Manager and confirm the enterprise root appears in a test client trusted store before enabling decrypt policy.