Resolving Ignition Gateway Not Secure Browser Warnings

You open the Ignition gateway on your LAN and the browser shows one of two warnings. Either the address bar says Not Secure, or you get a full-page "connection is not private" screen before the page loads. Perspective sessions open once you click through. Then every new browser, tablet, and panel PC shows the same warning.

The gateway is running fine. The browser cannot prove which server it is talking to. That is a certificate trust problem, and it has a permanent fix even on a closed network.

Skip the Fixes That Don't Stick

These are the usual first attempts. Each one fails or has to be repeated on every client.

• Clicking Advanced, then Proceed. This only adds an exception for that browser. The padlock stays broken. Browsers also turn off some features on untrusted origins because those features need a secure context.
• Staying on plain HTTP. Browsers mark every HTTP page as Not Secure. Gateway logins also cross the network in clear text. You cannot fix this without switching to HTTPS.
• Trusting the gateway's own self-signed certificate on each machine. This works until the certificate is regenerated or the hostname changes. Self-signed certificates often lack a Subject Alternative Name (SAN), so Chromium-based browsers reject them anyway. You also repeat the work on every client at every renewal.
• Editing the hosts file. This fixes name resolution only. It does nothing for trust.
• Turning off warnings with browser flags. This disables the check for every site on that machine and does nothing for mobile devices.

None of these touch the actual fault.

Identify Which Trust Condition Fails

A browser treats a site as secure only when all of these are true:

1. The connection uses HTTPS, so traffic is encrypted and the server presents a certificate.
2. The certificate is signed, possibly through intermediate certificates, by a certificate authority (CA) that the client already trusts.
3. The hostname or IP address in the URL appears in the certificate's SAN list.
4. The client's clock falls inside the certificate's validity dates.

Browsers ship with a built-in list of trusted CAs. Users can add more CAs on most platforms, but this is harder on mobile devices.

Start here. Click the warning or padlock and open the certificate viewer. Read four fields: Issued To, Issued By, the SAN entries, and the validity dates. Match what you see to a row below.

Choose Between a Public CA and Your Own CA

There are two ways to get a trusted chain.

• Get a certificate from a CA that browsers already trust. Most public CAs charge for this. Let's Encrypt does not.
  • You need a public domain you control, for example scada.yourdomain.com.
  • Let's Encrypt's HTTP-based check needs the gateway to be reachable from the internet. That is wrong for an isolated control network.
  • The DNS-based check works for a gateway that is only reachable internally, as long as the name sits under a public domain you own.
  • Certificates are short-lived. Plan an automated way to renew them and re-import them into the gateway.
• Create your own CA. Sign the gateway certificate with it, then install the CA's root certificate on every client.
  • Works fully offline.
  • You control the certificate lifetime.
  • You must distribute the root certificate yourself. Mobile devices take the most effort.

Decision rule:

• If the plant has an IT group with an internal enterprise CA, ask them to issue the certificate. Their root is probably already pushed to domain-joined machines.
• If the network is air-gapped or a home lab, build a private CA.
• If you own a public domain and can automate DNS checks, use Let's Encrypt.

Build a Private CA and Install the Certificate

The hostname ignition.home.lan and the address 192.168.1.50 below are examples. Replace them with every name and IP that users actually type into the browser. The validity periods are example values.

1. Create the root CA once. Store rootCA.key offline.

   openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes -keyout rootCA.key -out rootCA.crt -subj "/CN=Plant Private Root CA"

2. Generate the gateway key and a certificate signing request:

   openssl req -newkey rsa:2048 -nodes -keyout gateway.key -out gateway.csr -subj "/CN=ignition.home.lan"

3. Create gateway.ext. The SAN line is required.

   basicConstraints=CA:FALSE
   keyUsage=digitalSignature,keyEncipherment
   extendedKeyUsage=serverAuth
   subjectAltName=DNS:ignition.home.lan,IP:192.168.1.50

4. Sign the request with the root CA:

   openssl x509 -req -in gateway.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out gateway.crt -days 365 -sha256 -extfile gateway.ext

5. Import gateway.crt, gateway.key, and rootCA.crt (as the chain) through the gateway's web server SSL/TLS configuration page. The exact page name depends on your Ignition version. Restart the web server if the page asks you to.
6. Install rootCA.crt on every client:
   • Windows: run certutil -addstore -f Root rootCA.crt from an elevated prompt, or push it by Group Policy on a domain.
   • macOS: add it to the System keychain and set it to Always Trust.
   • iOS: install it as a profile, then turn on full trust for it under Certificate Trust Settings.
   • Android: install it as a user CA. Browser behavior varies, and many apps ignore user-added CAs.
   • Firefox: import it in Firefox's own certificate settings, or enable Firefox's option to use the OS enterprise roots.

Verify the Chain Before You Walk Away

1. From a client, check the certificate the gateway actually serves. Replace <https-port> with the HTTPS port configured on the gateway.

   openssl s_client -connect ignition.home.lan:<https-port> -servername ignition.home.lan -CAfile rootCA.crt -showcerts

   You want Verify return code: 0 (ok). Any other code means the served chain or the SAN is wrong. Fix it before touching clients.
2. Open the gateway in each browser and on each device type in use. Confirm the padlock appears with no warning page.
3. Repeat step 2 using every hostname and IP your operators use.
4. Once HTTPS verifies cleanly, turn on the gateway's HTTP-to-HTTPS redirect. Update any bookmarks and kiosk launch URLs.
5. Record the certificate expiry date in the maintenance schedule.

Avoid the Pitfalls That Bring the Warning Back

• Browsing by IP when the SAN only lists a hostname. This is the most common cause of a mismatch warning. Put both in the SAN, or standardize on DNS names.
• Missing intermediate certificate. With public CAs, desktops may fill in a missing intermediate on their own, but mobile devices usually will not. Import the full chain.
• Clock drift on panel PCs. If an HMI's clock is wrong, a valid certificate looks expired or not yet valid. Point clients at an NTP source.
• Renewals that are not automated. A short-lived certificate that nobody re-imports brings the warning back on schedule.
• Mixing up certificate types. The gateway's web certificate is separate from OPC UA and gateway-network certificates. Fixing the browser padlock does not change trust on those connections.
• Handling the root CA key carelessly. Anyone who has rootCA.key can create certificates your clients will trust. Keep it off the gateway and off shared drives.

FAQ