Fix S7-1200 Web Server SSL Certificate Errors on iOS and Android

The SIMATIC S7-1200 CPU ships with an integrated Web server that exposes diagnostics, tag values, and user-defined pages over HTTPS. Engineers commissioning panels on tablets and phones routinely hit a brick wall: the login screen loads, but the mobile browser refuses the self-signed X.509 certificate and blocks the session. This reference explains the root cause, walks through every documented mitigation, and gives you a verification matrix for production hand-over.

1. Problem Description

When a PC browser connects to the S7-1200 Web server, the operator receives a self-signed certificate warning and can continue by adding an exception. The session then completes normally and tag read/write operations work. When an iPad, iPhone, or most Android devices try the same URL https://<cpu-ip>/ with valid CPU credentials, the browser either:

• Refuses to display the login page at all (Safari behaviour on older iOS).
• Renders a non-dismissable certificate error page with no "Continue anyway" option.
• Returns HTTP 404 or 403 after the login form POST because the secure session was never established.

This behaviour was confirmed by Siemens Support as a known limitation at the time of firmware V3.1 and persists on later firmware revisions when no customer certificate is installed.

2. Affected Hardware, Firmware, and Software

3. Root Cause Analysis

The S7-1200 Web server is bound to https://<cpu-ip>/ on TCP 443 and presents an auto-generated self-signed certificate during the TLS handshake. Desktop browsers such as Internet Explorer, Mozilla Firefox, and older Opera implement a permissive trust model: the operator can permanently accept the exception through the certificate store and proceed.

Mobile browsers, however, follow stricter WebKit/Chromium policies:

1. Safari (iOS / iPadOS): WebKit blocks navigation to hosts with untrusted certificates. The "Visit this website" advanced option is hidden by default and requires typing the exact hostname to expose it; even then the certificate download/accept flow is unreliable for embedded WebView controls.
2. Chrome on Android: Modern Chromium builds refuse to surface a "Proceed anyway" prompt for net::ERR_CERT_AUTHORITY_INVALID when the site uses HSTS-style indicators. Adding the certificate to the device trust store is required, but the certificate is issued to the CPU's MAC-derived CN, not to a routable name.
3. WebView components inside apps: Most HMI/SCADA apps embed a WebView that inherits the host app's TLS validation and offers no override.

The technical root cause is therefore not a bug but a policy difference between desktop and mobile TLS stacks interacting with a self-signed certificate that cannot be issued by a public CA (the CPU has no ACME client, no external network, and no operator-controlled subject name without engineering effort).

4. Browser Compatibility Matrix

Per the official Siemens "Creating and Using Own Web Pages for SIMATIC S7-1200" PDF, the Web server was validated against the browsers below. Items in italics are behaviour confirmed by Siemens Support in the original case report.

5. TIA Portal Configuration Walkthrough

Enable the Web server in the project and create a user-defined page. These are the minimum steps before any mobile workaround can succeed.

1. Open the S7-1200 device configuration in TIA Portal.
2. Navigate to Properties > Web server and tick Activate web server on this module.
3. Under User management, add at least one user with a password and assign the "administrator" or "standard" permission level as required for tag read/write.
4. If the deployment target is a phone or tablet, tick Permit access only with HTTPS (default) so credentials travel encrypted — but plan a cert workaround from section 6 onwards.
5. Under User-defined web pages, define a DB with the HTML fragment names, then compile and download. The DB contains the page payload that is served by the CPU at runtime.
6. Confirm with a PC browser that https://<cpu-ip>/ opens the diagnostics page and https://<cpu-ip>/<your-page>.html opens the user page. If PC fails, fix that first.

6. Documented Workarounds for Mobile Browsers

6.1 Install the CPU Certificate on the Mobile Device

1. From a PC browser, navigate to https://<cpu-ip>/ and download the certificate through the browser's certificate viewer (DER or PEM).
2. Transfer the file to the mobile device (email attachment, cloud drive, USB).
3. On iOS: Settings > General > VPN & Device Management > tap the profile > Install, then Settings > General > About > Certificate Trust Settings > enable full trust.
4. On Android: Settings > Security > Encryption & credentials > Install a certificate > CA certificate. Modern Android (7+) prompts for credentials/PIN before installing a user CA.
5. Reopen the Web server URL. The login should now complete.

This is the only workaround that works on stock iOS Safari without third-party tools. It does not scale across fleets because every device must be touched individually.

6.2 Use a Third-Party Browser (Historical)

At the time of the original case, Opera Mobile permitted a one-tap "Accept certificate" flow and was the only stock browser confirmed by the user to work on iPad. Opera Mobile was discontinued for iOS in 2013 and is no longer an option. On Android, Firefox with security.enterprise_roots.enabled set to true in about:config can be coerced into honouring user-installed CAs without re-prompting.

6.3 Front the S7-1200 with a Reverse Proxy

Place a small Linux/Windows box (Raspberry Pi, IPC, or the engineering laptop) running nginx or haproxy between the tablet and the CPU. Configure the proxy with a real certificate (Let's Encrypt, internal CA, or self-signed distributed via MDM) and proxy_pass traffic to https://<cpu-ip>:443. The proxy handles TLS termination, the CPU keeps its self-signed cert private, and the mobile browser trusts the proxy because the cert is real.

6.4 Use an MDM-Managed Trust Profile

For plant-wide deployment, push the S7-1200 root certificate as a trusted CA through your Mobile Device Management (Intune, Jamf, AirWatch). Tablets in scope inherit the trust anchor automatically. This is the only scalable option for >5 devices.

6.5 Build an App-Side WebView with Pinned Cert

Replace browser-based access with a thin native or Flutter/React Native shell that loads the CPU URL inside a WebView with the S7-1200 certificate bundled and pinned. Examples include Apache Cordova with the cordova-plugin-certificate-pinner plugin or MAUI WKWebView with NSURLSessionDelegate.urlSession(_:didReceive:completionHandler:) override.

6.6 Migrate to a Native HMI

If browser access is a recurring operational pain point, switch the mobile dashboard to WinCC Unified, the Siemens SIMATIC WinCC Unified Comfort Panel runtime, or a third-party SCADA mobile client. These clients maintain their own trust stores and bypass browser policy.

7. User-Defined Web Pages and the Login Form

The S7-1200 refuses to expose tag write operations to anonymous users — every read/write of a configured tag inside a user-defined page requires a valid session cookie issued after the HTTPS login. The login form is generated by the firmware; HTML source of the built-in pages is not published. Engineers reproducing the official "AT 2 — User Defined Webpage" demo must therefore:

1. Scrape the login form from the built-in /Login page served by the CPU using a PC browser's "View Source".
2. Replicate the form action (POST /FormLogin) and hidden fields (LoginState, LoginName, Password) in the user-defined HTML fragment.
3. POST credentials over HTTPS; the CPU replies with Set-Cookie: SiemensIWS7WWW=... which the client must echo back on every subsequent request.

On mobile devices the form posts, the CPU replies with HTTP 302 to a success page, and the WebView's WebKit/Chromium layer drops the redirect because the underlying TLS validation failed. That is why the user in the source case saw the same login screen re-render after submit.

8. HTTP vs HTTPS Decision

The S7-1200 Web server can be configured to accept HTTP, but credentials and tag writes will traverse the network in plaintext. For operational technology networks this is rarely acceptable. If you decide to enable HTTP for tablet-only access, isolate the CPU on a VLAN that cannot reach the corporate network, disable inter-VLAN routing, and document the security exception in the network risk register.

9. Troubleshooting Matrix

10. Verification Procedure

1. From a PC on the same subnet, browse to https://<cpu-ip>/ and confirm the diagnostics page renders.
2. Log in with the configured credentials and toggle a test tag. Note the value change.
3. Capture the PC session in Wireshark and confirm the TLS handshake completes with the S7-1200 certificate.
4. From the tablet, browse to the same URL. If the certificate warning appears, follow section 6.1.
5. After installing the cert, reload and attempt login. Verify the post-login cookie is set (Developer Tools in Safari > Storage > Cookies).
6. Read a tag from the user-defined page; confirm the value matches the PC view.
7. Write a tag from the tablet and verify the change in TIA Portal's watch table.
8. Power-cycle the tablet and the CPU and repeat steps 4–7 to confirm persistence.

11. When to Escalate to Siemens Support

Open a Support Request via the Siemens Industry Online Support portal if:

• The certificate cannot be downloaded from a PC browser (browser bug or firmware regression).
• The login form action URL on the current firmware differs from any documented value.
• The user-defined page is rejected with HTTP 500 even on a PC after a firmware upgrade.
• You require an officially-signed Siemens certificate for the CPU and your environment cannot distribute a private CA.

Reference the original "SIMATIC S7-1200: AT 2 — User Defined Webpage" demonstration in the support request so that the engineer handling the case has the same baseline.

12. Long-Term Direction: S7-1200 G2 Web Server

The second-generation S7-1200 (S7-1200 G2) ships with an updated Web server documented in the S7-1200 G2 Webserver Guide. The G2 Web server retains the same self-signed-certificate model but adds structured data export (JSON / CSV) and improved HTTPS defaults. Mobile browser restrictions on self-signed certificates still apply; the workarounds in section 6 remain the only mitigation paths until customer-supplied certificates are supported, which is not exposed in the documentation reviewed.