TLS/SSL Inspection and ScreenMeet: Configuration and Security Controls

Overview

If your company employs a network security solution that decrypts TLS traffic (Zscaler, Palo Alto Networks NGFW, Cisco Umbrella, Fortinet FortiGate, Blue Coat ProxySG, or similar), this article explains the impact on ScreenMeet functionality, the recommended configuration, and the application-level controls available to offset the change. It is intended for IT and network security administrators.

Recommended Configuration

Add a TLS/SSL inspection exception (a "do not decrypt" rule) for the following domains, on port 443 over both TCP and UDP:

*.screenmeet.com
*.scrn.mt
myhelpscreen.com (Remote Support front end, including custom domain deployments)

An inspection exception is not a firewall whitelist

Traffic under a do-not-decrypt rule remains fully logged (hostname, destination IP, user, volume) and remains subject to your URL filtering, cloud application, and firewall policies. Only decryption is skipped.

Scoping the exception

A do-not-decrypt rule does not need to apply broadly. Most enterprise security platforms let you constrain the rule so it applies only where ScreenMeet is actually used. Where supported by your platform, consider scoping by:

Users and groups: apply the rule only to the directory groups licensed for ScreenMeet, such as support agents and the employee groups they assist.
Devices: restrict the rule to managed or trusted devices, using device groups, device posture, or trust-level criteria.
Destination: where your platform provides a vendor-maintained ScreenMeet application object, match on it instead of a manually maintained domain list.
Locations and policy tiers: apply the rule to the locations or remote-user policies where ScreenMeet traffic originates. If remote users connect through an endpoint agent, confirm the rule applies to that policy path as well.

Combined, these constraints reduce the exception to a narrow slice of traffic: known users, on managed devices, connecting only to ScreenMeet, with all non-decryption policies still enforced. Consult your security platform's documentation for the exact criteria it supports.

Impact of TLS/SSL Inspection

Certificate pinning: ScreenMeet client software validates the server certificate. When TLS inspection substitutes your security solution's certificate, users encounter a warning that the session is "not secure." This protects against man-in-the-middle attacks and appears as a false positive in inspected environments.
ScreenMeet Beam (unattended): Beam will not connect if TLS inspection is enabled. This is an intentional implementation to reinforce connection security. No firewall or IP configuration resolves this; the inspection exception is required.
Session servers use dynamic addresses: Each session is served by a per-session host under *.screenmeet.com with a rotating, unpublished IP address. IP-based inspection exceptions cannot fully cover these hosts. Use hostname or application-level scoping instead. See ScreenMeet Network Whitelisting (Firewall and Proxy) for the static IP reference.

Warning example

Users in inspected environments may see: "WARNING: The connection to the support server may not be secure because of an SSL certificate mismatch. Certificate Issuer: CN=[Your Organization's Root CA]. Are you sure you wish to continue?" If the issuer shown is your security vendor's CA, TLS inspection is confirmed as the cause.

Industry Context

Certificate validation is standard across the remote support category, and every major vendor documents the same requirement. This exception is not unique to ScreenMeet.

BeyondTrust (Bomgar): clients validate the appliance certificate; deployments require exclusion from SSL interception.
TeamViewer: requires *.teamviewer.com excluded from SSL and deep packet inspection.
LogMeIn Rescue / GoTo Resolve: publishes dedicated guidance for decryption platforms using do-not-inspect rules over its domain set.
Splashtop: recommends a do-not-inspect rule on its application object, placed ahead of other policies.
Zoom and Microsoft Teams: instruct customers to exclude real-time media traffic from inspection; major decryption platforms ship predefined bypass configurations for both.

Leading decryption vendors recognize certificate-pinned applications as a legitimate bypass category in their own reference architectures. ScreenMeet's recommendation is at the conservative end of this range: decryption only is skipped, and all other policy enforcement remains active.

Why inspection yields little on this traffic

ScreenMeet session payloads are primarily WebRTC media, which is separately encrypted. Decrypting the outer TLS layer does not produce readable content for DLP or antivirus engines, so the visibility given up by the exception is smaller than for ordinary web traffic.

Compensating Security Controls

ScreenMeet provides application-level controls that restrict who can participate in sessions and what can move through them. Organizations pairing the inspection exception with these controls retain enforcement at the endpoints and inside the product itself.

Organization Restriction: deployed clients accept sessions only from your organization IDs (ORGRESTRICT and ORGRESTRICTLIST MSI parameters). This prevents your users from being drawn into sessions belonging to any other organization.
Certificate-Based Device Validation: ScreenMeet servers can reject any Windows or macOS device that does not present a certificate issued by your own CA, distributed at machine level via your MDM. Only managed devices can join your sessions. Note that client certificate authentication cannot operate through TLS inspection, so this control requires the inspection exception. Applies to desktop clients.
File Transfer controls: disable file transfer, set it one-way, or restrict it with the file extension blacklist and built-in antivirus scanning of all transferred files. A 2 GB per-session cap applies in all cases.
Session Recording: enforce always-on recording so every session produces an auditable record.
Additional options: disable console sessions so sessions start only from your CRM, disable URL invites, keep clipboard sharing off by default, remove transferred files at session close, and apply regional geo-fencing.

Recommended pairing

Organization Restriction plus Certificate-Based Device Validation limits sessions to your agents and your managed devices, enforced at both the endpoint and the server. Combined with file transfer scanning and recording, this replaces content controls at the application layer, where they operate on readable data.

Action Items

Add a TLS/SSL inspection exception for *.screenmeet.com, *.scrn.mt, and myhelpscreen.com.
Confirm port 443 is open over both TCP and UDP for these domains.
Narrow the exception using the scoping criteria your platform supports: users and groups, devices, application objects, locations, and remote-user policies.
Review the compensating controls above with your security team.
Verify with the ScreenMeet network and browser test tool from an affected machine.