Where does the HTTPS handshake actually terminate?
Start with the request path. A browser, Designer launcher, or client resolves the gateway hostname through DNS, opens a TCP connection to the returned IP and port, and then runs a TLS handshake with whatever process is listening there. The certificate that process presents is the only one that counts. DNS records at the registrar only point the name at an IP address. They take no part in the handshake.
So yes, you can use a certificate bought from a registrar, but buying it does nothing on its own. The certificate file, its private key, and the intermediate chain have to be installed on the Ignition gateway's web server or on a reverse proxy in front of it. Website-builder SSL that a registrar applies automatically to sites it hosts, such as a Squarespace site, cannot be exported and never reaches a gateway on a plant or cloud server. Adding SSL on the root domain and subdomains at the registrar has no effect on the gateways, and it does not break them either.
| Hop | What it does | What it needs for HTTPS |
|---|---|---|
| DNS (registrar or internal) | Resolves gatewayNN.example.com to an IP |
An A/CNAME record per gateway. No certificate. |
| Corporate firewall / TLS inspection | May decrypt and re-sign traffic | Clients must trust the inspection CA |
| Reverse proxy (optional) | Terminates TLS and forwards to the gateway | Certificate + key + chain for each hostname |
| Ignition gateway web server | Terminates TLS if there is no proxy | Certificate + key + chain in the gateway's store |
Standard HTTPS listens on 443. Ignition gateways listen on their own configured HTTP and HTTPS ports, so read both from the gateway's web server settings before you build URLs or firewall rules.
Which certificate approaches fit 15 gateways plus a root domain?
Scope comes first. A wildcard certificate *.example.com covers one level of subdomain only. It does not cover the apex example.com or a.b.example.com. The apex usually hosts the company website and not a gateway, so leave it alone unless a gateway actually answers on it.
| Approach | Hostname coverage | Key exposure | Renewal effort | Client trust |
|---|---|---|---|---|
| Commercial cert per gateway (registrar/CA) | One name each | Isolated per gateway | Manual, 15 installs per cycle | Public, trusted by default |
| Commercial wildcard or multi-SAN | All subdomains (plus apex if listed as SAN) | One key copied to every gateway | Manual, one purchase, 15 installs | Public, trusted by default |
| Let's Encrypt (ACME) | Per name or wildcard | Isolated if issued per gateway | Short-lived, so renewal must be automated | Public, trusted by default |
| Internal CA | Any internal name | Isolated per gateway | Set by your PKI policy | Root must be deployed to every client |
| Reverse proxy terminating TLS | All names on one host | Keys live on the proxy only | Centralized, ACME-friendly | Depends on the issuing CA |
Public CAs validate domain control. HTTP validation needs port 80 on the gateway reachable from the internet. DNS validation needs a TXT record at the DNS provider. Plant gateways that are not internet-facing can still get public certificates through DNS validation.
Which approach should you pick?
Issue one certificate per gateway hostname. Use Let's Encrypt with DNS validation when the names are in public DNS. Use an internal CA when every client is a managed machine on the plant network. Per-host certificates contain a compromise to one gateway, and ACME removes the renewal chore that causes most HTTPS outages. Pick a wildcard only if you cannot automate renewal and you accept the same private key sitting on 15 machines. Pick a reverse proxy when the gateways sit behind one ingress point and you want one place to manage certificates.
How do you install the certificate on 7.9 and 8.1 Edge gateways?
- Create DNS records so each
gatewayNN.example.comresolves to the right gateway IP from the client networks. Confirm withnslookup gatewayNN.example.com. - Generate the private key and CSR yourself, or let the ACME client generate them. If the registrar's portal generates the key, download it immediately. Without it the certificate cannot be installed.
- Obtain the leaf certificate and the full intermediate chain. The CN or SAN must match the exact hostname clients type.
- 8.1 gateways: open the gateway web server configuration, run the SSL/TLS setup, and supply the certificate, private key, and chain. Enable the HTTP-to-HTTPS redirect option if you want plain-HTTP bookmarks to follow automatically.
- 7.9 gateways: bundle the files into PKCS12 and import them into the Java keystore the gateway uses. Take the keystore file name, alias, and password from the 7.9 user manual SSL procedure, enable SSL in the gateway settings, and restart the gateway service so the web server reloads the keystore.
- Open the gateway's HTTPS port on the host and network firewalls. Close the HTTP port afterward if policy requires it.
- Update launchers, bookmarks, and any stored project or client URLs from
http://tohttps://with the new port.
# Bundle for a Java keystore (7.9)
openssl pkcs12 -export -in gateway.crt -inkey gateway.key -certfile chain.pem -out gateway.p12
keytool -importkeystore -srckeystore gateway.p12 -srcstoretype PKCS12 -destkeystore <gateway keystore>What breaks after switching a gateway to HTTPS?
Nearly every failure at this stage comes from certificate handling, not from Ignition itself.
| Symptom | Cause | Fix |
|---|---|---|
| Works on some networks, cert error on the corporate LAN | A TLS-inspecting (MITM) firewall re-signs the traffic | Exempt the gateway hostnames, or deploy the inspection CA to clients and Java trust stores |
| Browser accepts it, Java launcher or other clients reject it | Missing intermediate chain, or the Java trust store lacks the root | Install the full chain. For an internal CA, import the root into every client trust store |
| Name mismatch warning | URL uses an IP or short name that is not in the SAN | Connect by the FQDN on the certificate |
| Everything fails on the same day | Certificate expired | Automate renewal and monitor expiry dates |
| Old links still fail | Hard-coded http:// URLs |
Enable the redirect (8.1) and update stored URLs |
The web server certificate is separate from the certificates Ignition uses for gateway-to-gateway connections. Replacing one does not replace the other, so gateway network trust between the Edge nodes and the central gateway does not change.
How do you verify each gateway serves the right certificate?
- From a client subnet, confirm DNS resolves to the expected IP:
nslookup gatewayNN.example.com. - Pull the handshake and chain:
openssl s_client -connect gatewayNN.example.com:<https-port> -servername gatewayNN.example.com -showcerts. Confirm the leaf, the intermediates, andVerify return code: 0 (ok). - Check names and dates: pipe the leaf through
openssl x509 -noout -subject -ext subjectAltName -enddate. - Test the redirect with
curl -vI http://gatewayNN.example.com:<http-port>and confirm theLocationheader points tohttps://. - Repeat step 2 from a machine behind the corporate firewall. If the issuer changes to the firewall's CA, TLS inspection is in the path.
- Launch a Designer or client session against the
https://URL on each 7.9 and 8.1 gateway and confirm it connects without a trust prompt.
FAQ
Does adding SSL at GoDaddy or Squarespace make my Ignition gateway use HTTPS?
No. The registrar only hosts DNS. You must install the certificate, private key, and intermediate chain on the gateway web server or on a reverse proxy that terminates TLS.
Can I use one wildcard certificate for all my Ignition gateways?
Yes. A *.example.com certificate covers every single-level subdomain but not the apex, and the same private key ends up on every gateway. Per-gateway certificates limit the damage if one key is compromised.
Can I use Let's Encrypt on gateways that are not reachable from the internet?
Yes. Use DNS validation, where the ACME client publishes a TXT record at your DNS provider, and automate renewal because the certificates are short-lived.
Does a corporate firewall break Ignition HTTPS?
A TLS-inspecting firewall re-signs traffic with its own CA. Browsers on managed PCs may accept it while Java-based clients reject it, so exempt the gateway hostnames or add the inspection CA to every client trust store.
Does changing the gateway SSL certificate affect the gateway network between 8.1 Edge and central gateways?
No. Gateway network connections use their own certificates, separate from the web server certificate. Verify both independently after the change.