SSL Forward Proxy Breaks Unmanaged Student Devices
A university SRX1500 at the campus edge applies an IPS and antivirus UTM policy to the student-to-untrust security policy. To inspect HTTPS, the administrator enables SSL forward proxy with a locally generated CA and applies the SSL proxy profile in the UTM policy. After rollout, HTTP works, but many HTTPS sites either show a certificate warning and then load, or hang after the TLS handshake. The help desk reports that the same sites work on the guest Wi-Fi, which bypasses the SRX. The CA certificate has not been installed on student laptops. Logs on the SRX show SSL proxy certificate and handshake errors for some sessions. The university wants HTTPS inspection but cannot immediately manage every student device.
1. Why does HTTP work while many HTTPS sites warn or hang after SSL forward proxy is enabled?
Read the worked answer
HTTP is clear text; the SRX can pass it through IPS and AV without touching TLS. SSL forward proxy terminates the client TLS connection, inspects it, and presents a certificate generated by the SRX local CA. If the student laptop does not trust that CA, the browser shows a certificate warning; some applications and pinned clients abort the connection, which looks like a hang after the handshake. Guest Wi-Fi bypasses the SRX, so the same sites work there and the CA warning does not appear. The symptom is not an IPS signature problem; it is a trust deployment problem. The SRX may also log certificate validation or SSL proxy errors, but the primary cause is that the endpoint trust chain was never established.
2. What would you check on the SRX to confirm the proxy is actually processing the session, and what would you check on the endpoint?
Read the worked answer
On the SRX, confirm the policy is matching and the UTM profile is attached with show security policies detail and show security policies hit-count. Use show security flow session for the client and server addresses to see whether the session is active and whether SSL proxy is involved; show security utm status confirms UTM processes are running. Check show log messages | match ssl and any UTM/SSL proxy logs for certificate or handshake errors. On the endpoint, open the certificate chain for a failing site: if the issuer is the SRX local CA, forward proxy is working and the endpoint simply does not trust it. If the issuer is the real site, the session may be bypassing the proxy, so check the SSL proxy profile and policy match. This separates a proxy problem from a trust problem.
3. The university cannot install the CA on all student devices. What are the defensible options?
Read the worked answer
Do not half-deploy decryption. Either distribute the CA through MDM or a managed onboarding process and accept that unmanaged devices will fail, or disable SSL forward proxy for the student policy and accept that HTTPS content is not inspected. A middle path is to decrypt only selected categories or destinations that matter and exempt banking, health, and pinned applications; use policy-based exemptions and document them. If you keep forward proxy, publish a clear support page and provide a bypass for devices that cannot trust the CA. The judgement is risk-based: blind decryption breaks user trust and creates outages; no decryption leaves encrypted traffic uninspected. Neither is free, so the decision should be explicit, logged, and reviewed.