Server

The Server page groups controller-level configuration and connectivity into seven tabs: General (operational flags and site identity), Email (outbound SMTP), SMS (outbound text alerts), Network & Database (connection info and reverse-proxy trust), SSL / TLS (HTTPS certificates), Tunnel (the reverse connection to the cloud orchestrator), and Remote Support (temporary technician access through the tunnel).

The General, Email, SMS, and Network tabs edit sections of the on-disk gem.json configuration file. Saves are atomic (written to a temporary file and renamed) and only touch the keys exposed in the form, so unrelated gem.json sections are preserved. Some changes — server ports, the REST API toggle, SMTP server/credentials — take effect only after a restart.

Secrets are write-only

Passwords and API keys are never sent back to the browser. Each secret field shows only whether a value is currently set (•••••••• (unchanged)) and is left blank on load. Leave it blank to keep the stored value; type a new value only to replace it.

General

The General tab edits operational flags and site identity stored in gem.json, grouped into three sections with a single Save button that writes them all back together.

Startup — how GEM boots and who hears about it; applies from the next start:

Setting	Description
Start Offline	Start GEM even if devices are unreachable
Start Alert	Email when GEM starts
Failed Start Alert	Email when startup fails

Health Alerts — email when devices or monitored hosts change state, sent to the default recipient on the Email tab. These switches are the global on/off; the subjects live elsewhere — Device Health for devices, Monitoring for ping hosts:

Setting	Description
Device Alerts	Email when a device goes offline
Alert Threshold	Consecutive monitor failures before a device alert is sent (editable only while Device Alerts is on)
Monitor Alert	Email on monitor (ping) state changes

Network & Identity — where this site lives and how it is reached; used in notification links, the mobile apps, and weather lookups:

Setting	Description
External URL	Public URL used in notifications and links
Internal URL	LAN URL advertised to mobile apps for local failover — leave blank to auto-detect from the primary network interface (the detected value is shown as the field placeholder)
Location	Site location used for weather and sunrise/sunset. It is also the name this controller reports to the cloud site list — see Information Collected
REST API	Enable the /api endpoints (takes effect after a restart)

Connection alerts

When Device Alerts is on, a device's connection state raises and clears a stateful event under the Device Offline alarm definition — one alarm per outage, after the device stays down past Alert Threshold consecutive checks, cleared on confirmed recovery. The alarm center sends the notifications: batched into a single digest email when an outage storm hits many devices at once, honoring a per-device device_alerts address when set (explicit false suppresses), otherwise this page's Device Alerts default. Every send is stamped onto the event's delivery log on the Alarms page. Per-zone connection alerts behave the same way (Zone Offline) for drivers that report zone-level connectivity. Configuring notify steps on those definitions replaces the built-in recipients entirely.

GEM also watches for connection flapping — a device (or one of its zones) that keeps dropping and reconnecting without ever staying down long enough to trip the offline alert, which is often a worse symptom than a clean outage. When more than the flap threshold of disconnects occur inside the rolling flap window, GEM raises a one-time Connection Flapping alarm (notified the same way); it re-arms automatically once a full window passes with no further drops.

A link that flaps chronically storms, settles, and storms again, so the alarm is paced by a repeat-alert cooldown — one week by default. Later storms for the same device or zone are still detected and logged, but stay quiet until the cooldown expires; a device that flaps all week is one problem, not one alert per storm. Set flap_alert_cooldown to 0 to alert on every storm. The cooldown is tracked in memory, so a server restart or a device reload arms the next storm to alert again.

Flap detection is on by default and tuned with these gem.json keys (not surfaced in the form); each can be overridden per device by setting an attribute of the same name on the device:

Key	Default	Description
flap_detection	true	Set false to disable flap alerts entirely.
flap_window	600000	Rolling window in ms (values under 1000 are read as seconds).
flap_threshold	4	Disconnects within the window before a flap alert is sent (must be > 1).
flap_alert_cooldown	604800000	Minimum time in ms between repeat flap alerts for the same device or zone (1 week). 0 alerts on every storm.

Email

The Email tab configures the outbound SMTP server used for alerts and notifications. This is the transport only — who receives which alert, and when, is set per user under Notification Profiles.

Field	Description
SMTP Host	Mail server hostname
Port	SMTP port (e.g. 587 for STARTTLS, 465 for implicit TLS)
Secure Connection	Use implicit TLS (SMTPS)
Username	SMTP authentication user
Password	SMTP authentication password (write-only — leave blank to keep current)
From Address	Envelope/from address for outbound mail
Default Recipient	Default destination for alert emails

Server and credential changes take effect after a restart.

SMS

The SMS tab configures outbound text alerts via Telnyx. Recipients and delivery windows are set per user under Notification Profiles.

Field	Description
From Number	Sending number in E.164 format (e.g. +15551234567)
Default Recipient	Default destination number
Telnyx API Key	Telnyx API key (write-only — leave blank to keep current)

If gem.json specifies a non-Telnyx provider, that provider is reported as read-only here and must be managed directly in gem.json.

Network & Database

The Network & Database tab displays the listen port and database connection (dialect, host, port, name, user) read from gem.json at boot — these are read-only — and carries the editable Reverse proxies section below.

warning

The database connection is not editable from the admin UI — an incorrect value could prevent GEM from starting. Change these settings directly in gem.json and restart.

Reverse proxies

If GEM sits behind nginx or another reverse proxy, every connection appears to come from the proxy's own address, so GEM cannot tell an off-site client from one on the LAN. The Reverse Proxy section on this tab tells GEM to read the real client address from the proxy's x-forwarded-for header — which is otherwise ignored, deliberately, since that header is supplied by the client itself. This decides Allow Remote role enforcement and Skip 2FA on Local Network — see Roles — so only trust a proxy you control.

Trusted Proxies	Effect
None — no reverse proxy (default)	Every client is judged by its own peer address
Proxy on this machine (loopback)	x-forwarded-for is honored from loopback peers only — the nginx-on-the-controller case. Direct LAN and VPN clients are still judged by their own address
Specific proxy addresses	x-forwarded-for is honored only from the listed addresses (comma-separated IPs the proxy connects from)

Saving applies immediately — no restart needed. The setting is stored as trusted_proxies in gem.json (true for loopback mode, an address array such as ["10.1.1.5"] for the list), so it can also be set there directly. A trusted_proxies System attribute overrides the gem.json value at every config reload; the page warns when a save is being shadowed that way.

One setting covers every listener, not just the web and socket ports. Listeners a driver opens on its own follow the same rule — the Remote Proxy driver identifies a caller by address to pick which remote's key bindings apply, and honors x-forwarded-for only from a proxy named here. Remotes on the LAN need no proxy and no setting.

SSL / TLS

The SSL / TLS tab manages HTTPS certificates for secure browser connections to GEM. GEM uses a self-signed Certificate Authority (CA) to issue certificates, providing enterprise-grade encryption without dependency on external certificate providers.

Overview

GEM's SSL implementation:

• Self-Signed CA: GEM creates its own Certificate Authority
• Automatic Certificates: Server certificates generated automatically
• Subject Alternative Names (SANs): Includes all detected IP addresses
• Auto-Renewal: Certificates regenerate on expiry or IP changes (when enabled)
• Easy Device Trust: One-time CA installation on each device

Certificate Status

The status section displays current certificate information:

SSL Status

• Enabled: HTTPS is active, HTTP redirects to HTTPS
• Disabled: HTTP only (no encryption)

CA Certificate

• Generated: Certificate Authority is created
• Not Generated: SSL not configured (enable and restart to create)

Server Certificate

• Generated: Server certificate is active
• Not Generated: Server certificate not created

Expiration

• Expires: Certificate expiration date
• Days remaining: Countdown to expiration
• ⚠️ Warning: Shows in red when < 30 days remaining

IP Match

• OK: Certificate SANs match current server IPs
• IPs Changed: Server IP addresses changed since certificate creation
  • Certificate should be regenerated to match new IPs
  • Clients may see warnings when connecting via new IPs

SANs (Subject Alternative Names)

Lists all IP addresses and hostnames included in the server certificate:

192.168.1.100, 10.0.0.50, gem-server.local

Browsers check this list when connecting via HTTPS.

Configuration

Enable SSL

Toggle Enable SSL to activate/deactivate HTTPS.

When Enabled:

• Server listens on HTTPS port (default: 443)
• HTTP port redirects to HTTPS
• Certificates are generated on first restart
• Client devices can access via HTTPS

When Disabled:

• Server listens on HTTP port only
• No encryption or certificate validation
• Simpler configuration for local-only installations

HTTPS Port

Port for encrypted connections (default: 443)

Common Ports:

• 443: Standard HTTPS (requires root/admin privileges)
• 8443: Alternative HTTPS (no special privileges needed)
• 9000: Custom port

Firewall: Ensure chosen port is open in firewall.

HTTP Port

Port for unencrypted connections (default: 80)

Uses:

• CA certificate download (works without trust)
• Redirect to HTTPS
• Initial setup before devices trust CA

Auto-Regenerate

When enabled, GEM automatically regenerates certificates when:

• Certificate approaches expiration (< 30 days)
• Server IP addresses change
• Hostname changes

Recommended: Enabled (default)

Prevents expired certificates and IP mismatch issues.

Saving Configuration

• Save: Saves configuration only
• Save & Restart: Saves and restarts GEM to apply changes

SSL changes require a restart to take effect.

CA Certificate Download

Why Download the CA Certificate?

Each client device (browser, tablet, phone) must trust GEM's CA certificate to:

• Avoid browser security warnings
• Enable secure HTTPS connections
• Allow embedded webviews to load

One-Time Setup: Each device installs the CA once. Future server certificate renewals work automatically.

Download Formats

PEM Format (.pem):

• Text-based format
• Use for: macOS, Linux, Chrome, Firefox
• View in text editor

DER Format (.crt):

• Binary format
• Use for: Windows, iOS, Android
• Double-click to install

HTTP Download URL

When SSL is enabled, GEM serves the CA certificate over HTTP:

http://192.168.1.100:80/ssl/ca.pem
http://192.168.1.100:80/ssl/ca.crt

Why HTTP?: Devices can download without already trusting the certificate (chicken-and-egg problem).

Installation Instructions

The page provides platform-specific installation guides:

iOS / iPadOS

1. Open Safari and navigate to http://<server-ip>:<http-port>/ssl/ca.pem
2. Tap "Allow" when prompted to download profile
3. Open Settings > General > VPN & Device Management
4. Tap "GEM Local CA" profile and install
5. Go to Settings > General > About > Certificate Trust Settings
6. Enable full trust for "GEM Local CA"

Important: Must use Safari, not Chrome or other browsers.

Android

1. Download the .crt file from http://<server-ip>:<http-port>/ssl/ca.crt
2. Open Settings > Security > Encryption & credentials
3. Tap "Install a certificate" > "CA certificate"
4. Select the downloaded gem-ca.crt file
5. Confirm installation

Note: Steps vary slightly by Android version and manufacturer.

Windows

1. Download the .crt file
2. Double-click the file
3. Click "Install Certificate"
4. Select "Local Machine" and click Next
5. Select "Place all certificates in the following store"
6. Click Browse and select "Trusted Root Certification Authorities"
7. Click Next and Finish

Requires: Administrator privileges

macOS

1. Download the .pem file
2. Double-click to open in Keychain Access
3. Add to the "System" keychain
4. Find "GEM Local CA" in the certificate list
5. Double-click, expand "Trust"
6. Set to "Always Trust"
7. Close and authenticate with password

Ubuntu / Debian

Terminal commands:

# Download CA certificate
wget http://192.168.1.100:80/ssl/ca.crt -O gem-ca.crt

# Install system-wide
sudo cp gem-ca.crt /usr/local/share/ca-certificates/gem-ca.crt
sudo update-ca-certificates

# For Chrome browser
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n "GEM Local CA" -i gem-ca.crt

# For Firefox
# Import via Settings > Privacy & Security > Certificates > View Certificates > Import

Copy Commands: Click Copy Commands button to copy to clipboard.

Certificate Management

Regenerate Server Certificate

Creates a new server certificate signed by the existing CA.

When to Use:

• Certificate expiring soon
• IP addresses changed
• Hostname changed
• SANs need updating

Impact:

• Devices already trusting CA: No action needed
• New certificate is trusted automatically
• No client device reconfiguration

Process:

1. Click Regenerate Server Cert
2. New certificate generated with current IP addresses
3. Server certificate updated
4. Restart may be required

Regenerate All Certificates

Creates a new CA and server certificate.

When to Use:

• CA certificate compromised
• Starting fresh
• CA certificate expiring (rare, usually 10-year validity)

Impact:

• All devices lose trust
• Must re-install new CA on all devices
• Significant reconfiguration effort

Process:

1. Click Regenerate All
2. Confirmation dialog warns about impact
3. Click Regenerate All to confirm
4. New CA and server certificates created
5. Download new CA certificate
6. Re-install on all client devices

Important: Only use when absolutely necessary. Server-only regeneration is preferred.

Common Workflows

Initial SSL Setup

1. Navigate to System > Server and open the SSL / TLS tab
2. Enable Enable SSL
3. Configure ports (443/80 recommended)
4. Enable Auto-Regenerate
5. Click Save & Restart
6. Wait for GEM to restart
7. Download CA certificate (both .pem and .crt)
8. Install on all client devices
9. Access GEM via https://<server-ip>

Adding a New Client Device

1. On the new device, navigate to http://<server-ip>:<http-port>/ssl/ca.pem (or .crt)
2. Follow platform-specific installation instructions
3. Access GEM via HTTPS
4. Verify no security warnings

Server IP Address Changed

If Auto-Regenerate Enabled:

1. GEM detects IP change
2. Automatically regenerates server certificate
3. Restarts server
4. Devices continue working (same CA)

If Auto-Regenerate Disabled:

1. Access shows "IP Changed" warning
2. Manually click Regenerate Server Cert
3. Server certificate updated with new IPs
4. Access via new IP works without warnings

Certificate Expiring Soon

If Auto-Regenerate Enabled:

• Certificate automatically renews when < 30 days remaining
• No manual intervention needed

If Auto-Regenerate Disabled:

1. Status shows expiry warning
2. Click Regenerate Server Cert
3. New certificate issued with extended validity

Security Considerations

Self-Signed vs. Public CA

Self-Signed (GEM's Approach):

• ✅ No external dependencies
• ✅ Works offline
• ✅ No recurring costs
• ✅ Full control
• ⚠️ Requires manual trust installation
• ⚠️ Not trusted by default

Public CA (Let's Encrypt, etc.):

• ✅ Trusted by default
• ✅ No manual installation
• ⚠️ Requires public DNS
• ⚠️ Requires internet connectivity
• ⚠️ External dependency
• ⚠️ Not suitable for local-only networks

GEM's Choice: Self-signed is appropriate for local automation systems.

CA Key Security

The CA private key is the most sensitive component:

Protection:

• Stored with restrictive file permissions
• Not exposed via web interface
• Not included in backups by default

Compromise Scenarios:

• Physical server access
• Backup file theft (if included)
• Root-level system compromise

If Compromised:

1. Regenerate all certificates
2. Re-install CA on all devices
3. Review access logs
4. Investigate breach source

HTTPS Benefits

• Encryption: All traffic encrypted in transit
• Authentication: Verifies server identity
• Integrity: Prevents man-in-the-middle attacks
• Compliance: Required for many security standards

HTTP Fallback

GEM keeps HTTP port active even with SSL enabled:

Use Cases:

• CA certificate download
• Initial setup
• Troubleshooting

Security Note: HTTP port only serves:

• CA certificate
• Redirect to HTTPS

Configuration and control interfaces require HTTPS.

Troubleshooting

Browser Shows "Not Secure" Warning

Causes:

1. CA certificate not installed on this device
2. Wrong CA certificate installed
3. Certificate expired
4. IP mismatch

Solutions:

1. Download and install current CA certificate
2. Verify certificate is "GEM Local CA"
3. Check expiration date in certificate status
4. Regenerate server certificate if IPs changed

Mobile App Can't Connect

Symptoms: App shows connection error or certificate warning

Solutions:

1. Install CA certificate using platform instructions
2. Verify HTTPS port is accessible (firewall)
3. Confirm Auto-Regenerate is enabled
4. Check if accessing via IP in SANs list

Certificate Installation Fails

iOS: Must use Safari browser, not Chrome Android: May need to set screen lock PIN first Windows: Need administrator privileges macOS: Must authenticate with password

"NET::ERR_CERT_COMMON_NAME_INVALID"

Cause: Accessing via IP not in certificate SANs

Solutions:

1. Access via an IP in the SANs list
2. Regenerate server certificate to add current IPs
3. Enable Auto-Regenerate to prevent recurrence

Regenerate Button Disabled

Cause: No CA certificate exists yet

Solution: Enable SSL and restart to generate initial certificates

Advanced Topics

Multiple Network Interfaces

GEM automatically detects all network interfaces:

• Ethernet
• Wi-Fi
• VPN interfaces
• Docker bridges (if applicable)

All IPs are included in server certificate SANs.

Excluding Interfaces: Not currently configurable. All IPs are included.

Custom Hostnames

Add custom hostname to certificate:

1. Configure DNS or hosts file: gem-server.local → server IP
2. Regenerate server certificate (auto-includes hostname)
3. Access via https://gem-server.local

Certificate Validity Period

• CA Certificate: 10 years
• Server Certificate: 2 years

Auto-regenerate renews server certificate when < 30 days remain.

Port Conflicts

Port 443 Already in Use:

• Another service is using HTTPS port
• Choose alternative port (8443, 9000)
• Update firewall rules

Port 80 Already in Use:

• Another web server is running
• Choose alternative HTTP port
• Update CA download URLs in documentation

Firewall Configuration

Open required ports in firewall:

iptables (Linux):

sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

firewalld (RHEL/CentOS):

sudo firewall-cmd --permanent --add-port=443/tcp
sudo firewall-cmd --permanent --add-port=80/tcp
sudo firewall-cmd --reload

ufw (Ubuntu):

sudo ufw allow 443/tcp
sudo ufw allow 80/tcp

Best Practices

1. Enable Auto-Regenerate: Prevents expiration and IP mismatch issues

2. Document CA Installation: Create site-specific installation guide for technicians

3. Test on All Platforms: Verify CA installation process on all client device types

4. Backup CA Certificate: Download and store CA certificate in documentation

5. Monitor Expiration: Even with auto-regenerate, monitor expiration dates

6. Use Standard Ports: 443/80 unless there's a conflict

7. Secure Server Access: Protect physical and remote access to GEM server

8. Update Documentation: When regenerating all certificates, update client documentation

Tunnel

The Tunnel tab controls the reverse connection from this controller to the cloud orchestrator. The tunnel is a single persistent outbound WebSocket that lets the orchestrator reach the controller for remote management without any inbound port forwarding or public IP.

How it works

The controller initiates the connection outbound, so nothing needs to be opened on the site firewall. The connection binding — orchestrator URL, tenant, and a short-lived rotating token — is delivered automatically inside the signed update check; the controller does not store long-lived credentials. You normally only decide whether the tunnel runs.

The update server only mints the authentication token for installations whose public key it holds. If a binding arrives without a token, the controller does not attempt to connect — the orchestrator would reject the authentication, and each failure would trigger another update check, producing a retry loop that can never succeed from this end. Instead the tunnel waits and reconciles on the next scheduled update check (every 10 minutes); the moment a token appears in the binding, it connects. The same update response is what triggers automatic public-key re-registration, so the condition normally clears itself within a check or two. See Automatic re-registration.

Enable Tunnel

Toggle Enable Tunnel to start or stop the connection. Changes take effect immediately — no restart required. Disabling stops the active tunnel; re-enabling reconnects and fetches a fresh token on the next update check.

The toggle is backed by the tunnel system attribute. When no attribute is set, the tunnel defaults to on.

Status

The status panel reflects the live transport:

• State: Connected, Connecting, Reconnecting, Waiting (enabled but no binding yet), Disabled, Identity Fail, or awaiting_token (bound, but the update server is withholding the authentication token because no public key is registered for this installation)
• Connected: whether the WebSocket is currently established
• Identity Pinned: whether the orchestrator's public key is pinned and verified. Unpinned means the orchestrator's identity is not cryptographically verified — set orchestrator_pubkey to pin it
• Orchestrator URL / Tenant / Site: the active binding
• Active Streams: in-flight multiplexed requests
• Last Connected / Reconnect In: connection age and current backoff
• Config Source: whether the effective config came from gem.json or the tunnel system attribute
• Last Error / Reconcile Error: most recent transport or reconciliation failure

Refresh re-reads the status on demand; the panel also polls periodically.

No auth_token in binding

A Reconcile Error of no auth_token in binding (public key not registered) means the update server has no public key on file for this installation, so it withheld the tunnel token. The controller deliberately stays disconnected rather than retrying against a rejection, and re-registers its key automatically on the next update check — remote access restores itself once the key is accepted. The status also reports how long it has been waiting.

What the far end may reach

Nothing on the controller answers a tunnel peer until that peer has authenticated and, where orchestrator_pubkey is set, been verified against it. Requests arriving before that are dropped rather than handed to the web server, so the controller's sign-in page, web services and socket handshake are not reachable by whatever answers the tunnel URL — only by an orchestrator that proved who it is. If verification fails after a connection was already up, anything in flight is torn down with it rather than being allowed to finish.

Two ceilings bound what a connected peer can consume: a per-request body limit and a cap of 256 simultaneous requests, both generous enough for ordinary remote management including backup and firmware transfers. Active Streams in the status panel is the live count against that cap. A request over either limit is closed and logged; there is nothing to configure.

Advanced

Advanced binding overrides — orchestrator url, tenant_id, and pinned orchestrator_pubkey — are set on the tunnel system attribute under System → Attributes. The attribute is a single JSON object that fully overrides the gem.json tunnel block, so include every field you need:

{ "enabled": true, "url": "wss://tunnel.example.com", "tenant_id": "…", "orchestrator_pubkey": "…hex…" }

A read-only Orchestrator Tunnel dashboard widget shows the same status at a glance; add it from the admin dashboard's Customize editor.

Remote Support

Grant your support technician temporary admin access to this controller through the cloud tunnel — without sharing your own password and without any standing vendor account.

How it works:

1. Pick an access duration (1 hour to 7 days). Optionally tick Also allow terminal (command-line) access — see below. Then click Enable Remote Support.
2. A one-time support code (like MHKP-29TX-QRWD) is displayed once. Read it to your technician over the phone or send it however you prefer — it is never stored or shown again. If it's lost (the page was reloaded, for example), click Generate New Code — see below.
3. The technician enters the code at your site's cloud login page (the same https://<yoursite>.mygem.us address you use) via the Have a support code? link, and lands in the admin UI as a clearly-identified support account.

Terminal (command-line) access:

For deeper diagnostics — reading logs, checking services, running a repair step — a technician may need a command-line terminal on the controller, not just the admin interface. This is a separate, explicit opt-in: tick Also allow terminal (command-line) access when you enable remote support. Leave it unchecked and the grant covers the admin interface only; a terminal can never be opened.

• Your support code is still required to open a terminal. Opting in is not enough on its own — the technician must also enter the same one-time support code, which the controller verifies before any terminal starts. So opening a command line needs both your opt-in and the code you read out, and neither alone is sufficient.
• The terminal is reached only from Harness's own support console, which authorizes the technician there, and only over the same cloud tunnel — the controller exposes no command-line service to the network, and none exists when a terminal-enabled grant is not active.
• Every terminal session is recorded to a full transcript stored on this controller (under support_transcripts/), and the admin banner shows "with terminal access" — and "terminal open" while a session is live.
• Ending remote support (the button, expiry, or the background sweep) closes any open terminal immediately, along with the rest of the grant.

What the customer keeps control of:

• Nothing exists until you enable it. There is no standing support credential; the code, the support account, and its access window are created on your controller when you click Enable, and only then.
• It ends on its own. Access expires at the end of the window you chose — an in-progress session is disconnected at expiry, not just refused next time.
• You can end it early. End Remote Support Now disconnects the technician immediately and invalidates the code.
• You can replace the code without ending access. Generate New Code issues a fresh support code for the grant already in progress: the previous code stops working immediately, while the access window, the terminal opt-in and any session already connected are left untouched. Use it when the code was lost before it reached the technician — there is no need to end remote support and start over. Like the original, the new code is shown only once.
• It's visible. A banner shows on every admin page while support access is active — whether the technician has connected, whether terminal access was granted, and whether a terminal is open right now. The banner cannot be dismissed; its Manage link opens this Remote Support tab directly.
• It's audited. The support session's actions are logged to Request History under the support account's name (support_…), separate from your own users — while a grant is active, the status panel's Support Account entry links straight to that account's activity; terminal sessions additionally leave a full transcript on the controller.

The support account is site-local: it is never synchronized to your other sites by account sync, and each site grants support access independently.

Requirements: the cloud tunnel must be connected (see the Tunnel tab) for the technician to reach the controller, and enabling/ending remote support requires an elevated admin session.

Related Documentation

• Backup & Restore - Certificate backup considerations
• Users - User authentication over HTTPS
• Access Control - HTTPS access policies
• Attributes - Editing the tunnel system attribute