Legacy SOAP Endpoint Blocks TLS 1.2 Rollout
A claims-processing app in OutSystems Cloud integrates with 40 endpoints. Most are HTTPS with TLS 1.2, but one on-premises SOAP service used for medical eligibility checks only supports TLS 1.0 and a self-signed certificate. The app also has an HTTP listener endpoint used by a partner to post claim status; the partner says HTTPS is too slow and currently posts over HTTP. A penetration test found the app accepts HTTP and redirects to HTTPS, but the redirect happens after the request body is read, and the mobile app has certificate validation disabled in a test build that was promoted to production. The security team requires TLS 1.2+ everywhere, no self-signed certificates in production, and no cleartext credentials. The legacy vendor can upgrade in nine months, but the business needs the eligibility feed daily. There are three environments and a change freeze in two weeks.
1. Prioritize remediation for the legacy SOAP TLS 1.0/self-signed certificate, the partner HTTP post, and disabled certificate validation. Justify the order.
Read the worked answer
First re-enable certificate validation in the production mobile build. It is a small change with immediate impact: without validation, any network attacker can impersonate the server and capture credentials or claims. Second, stop accepting cleartext HTTP for the partner. If the redirect happens after the body is read, credentials or claim data may already be exposed. Require HTTPS at the edge; if the partner cannot comply, use a VPN or secure gateway, or suspend the endpoint. Third, handle the legacy SOAP service. It is a real risk, but it is a single internal integration and can be compensated with network isolation, allowlisting, and monitoring while the vendor upgrades. Do not lower TLS platform-wide or disable validation to accommodate it. The first two are emergency changes; the legacy fix follows the vendor timeline.
2. How would you connect to the legacy SOAP service without weakening the whole platform?
Read the worked answer
Put the legacy service behind a dedicated secure gateway or private network segment, expose only that SOAP endpoint, and allow only the OutSystems environment IPs. Keep TLS 1.2+ from the cloud to the gateway; if the gateway must speak TLS 1.0 to the legacy service, treat that segment as untrusted and isolate it, with no other services on it. Import the self-signed certificate into the trust store if possible; otherwise pin the expected certificate and alert on change. Do not disable certificate validation globally. Add logging, rate limits, and a planned cutover to the vendor's upgraded endpoint. Document the compensating controls as temporary and time-bound. Test that other integrations still use strong TLS and that the gateway cannot reach unrelated internal hosts.
3. What configuration and test evidence would you require before closing the finding?
Read the worked answer
Evidence should include an external TLS scan showing only TLS 1.2 or 1.3 on public endpoints; HSTS enabled; HTTP requests rejected at the edge before body processing, not redirected after; certificate validation enabled in all builds and environments; a successful partner HTTPS post with a strong cipher; secure gateway configuration export and allowlist; and negative tests showing an invalid certificate is rejected and cleartext credentials are refused. Also require a change record, monitoring alerts, and a dated vendor upgrade plan for the legacy SOAP service. For the mobile app, show the production build settings and a man-in-the-middle test failing. The finding should not close on a promise to upgrade; close on verified controls and tracked residual risk.