Certificate-Based Device Validation

Overview

Certificate-Based Device Validation restricts ScreenMeet Remote Support so that only managed devices in your organization can join your sessions. Each managed device holds a device certificate issued by your certificate authority (CA). When the Remote Support client connects, it presents that certificate and the ScreenMeet service validates it against the issuing certificate configured for your organization. Devices without a valid certificate are rejected.

This article is for IT administrators and ScreenMeet organization administrators. It covers how the feature works, how to issue and install device certificates, how to enable validation in the ScreenMeet Console, and how to troubleshoot validation failures.

What Device Validation Protects

Validation applies to the end user's device, the machine that runs the Remote Support client. It does not apply to the agent's browser session. The control prevents unmanaged devices from joining your sessions and prevents your agents from supporting devices outside your organization.

Prerequisites

A certificate authority your organization controls, with the issuing certificate available in PEM format.
A method to distribute certificates to managed devices, typically an MDM solution. Manual installation is supported for testing.
Windows: ScreenMeet Remote Support client 23.10 or later. The private key, Extended Key Usage, and expiration filters require client 24.5 or later.
macOS: ScreenMeet Remote Support client 3.115.1544 or later.
Administrator access to the ScreenMeet Console.

How It Works

You configure your issuing certificate (PEM) and an Issuer Common Name filter in the ScreenMeet Console.
When an end user starts a Remote Support session, the service sends your validation policy to the client. The client searches the device certificate stores for certificates whose Issuer name contains the Common Name Filter text. On Windows the client scans every store in both the Current User and Local Machine scopes. On macOS it searches the login and System keychains.
The client keeps only certificates the device itself trusts. If the optional filters are enabled in your policy, it also discards certificates without a private key, without the required Extended Key Usage, or past their expiration date.
The client sends the remaining certificates as part of the session handshake. The ScreenMeet service verifies them against the issuing certificates configured for your organization. If verification passes, the session continues. If it fails, the connection is rejected and the end user sees an error code.

Step 1: Choose the Issuer Common Name

Decide on the Common Name (CN) of the certificate that issues your device certificates. This value must be consistent in three places:

The subject CN of your issuing certificate (PEM).
The Issuer field of every device certificate it issues.
The Common Name Filter field in the ScreenMeet Console.

The filter matches on the Issuer name text. Choose a name that is specific to the certificates you intend to allow.

Step 2: Issue Device Certificates

Using your issuing certificate, issue one device certificate per managed device. Your IT or PKI team normally performs this step. Each device certificate must meet the following requirements:

Issued by the certificate whose CN you entered as the Common Name Filter.
Trusted by the device. The issuing CA, and its root if different, must be installed in the device's trusted certificate stores, otherwise the client discards the certificate before sending it.
Installed with its private key, if the private key filter is enabled in your policy.
Carries the Extended Key Usage selected in your policy, typically Client Authentication (1.3.6.1.5.5.7.3.2), if the EKU filter is enabled.
Not expired, if expiration rejection is enabled in your policy.

Recommended Certificate Profile

Issue device certificates with a private key and the Client Authentication EKU even if those filters are off today, so you can tighten the policy later without re-enrolling devices. Distribute them as .pfx or .p12 files, or through your MDM's certificate enrollment, rather than as public-only .p7b or .cer files.

Step 3: Install Certificates on Managed Devices

Install device certificates through your MDM tool wherever possible. The steps below describe manual installation for testing.

Windows

Copy the device certificate file with its private key (.pfx) to the device.
Double-click the file to open the Certificate Import Wizard.
Select Local Machine and click Next.
Enter the private key password and click Next.
Select Place all certificates in the following store, choose Personal, and click Next.
Click Finish. Confirm the message The import was successful.

Install for Local Machine, Not Current User

When the Remote Support client runs elevated, it cannot read certificates installed only for the current user. Always install device certificates for the Local Machine so that validation works in elevated sessions.

macOS

Copy the device certificate (.p12, .cer, or .crt) to the device.
Open Keychain Access.
Select the System keychain in the left pane. Authenticate with administrator credentials if prompted.
Drag the certificate file into the System keychain, or double-click the file and select System when prompted.
Confirm the certificate appears under System > Certificates and is issued by the expected CA.

Step 4: Enable Device Validation in the ScreenMeet Console

Sign in to the ScreenMeet Console as an administrator.
Navigate to Organization > Settings and Policies > Device Validation.
Enable Device Validation Enabled.
Enable Enforce On Windows and/or Enforce On macOS.
Enter your issuer CN in Common Name Filter.
Paste the full contents of your issuing certificate, including the BEGIN CERTIFICATE and END CERTIFICATE lines, into Issuing certificate 1 - PEM Format. Up to three issuing certificates can be configured, which supports CA rotation.
Set the optional filters to match your certificate profile: require a private key, require a specific Extended Key Usage, and reject expired certificates. Leave a filter off if your certificates do not meet it, otherwise validation fails with error 4043.
Click Save.

Enforcement Applies Immediately

Once saved, every new Remote Support session for the enforced platform requires a valid device certificate. Confirm certificates are deployed to all managed devices before enabling enforcement in production.

Verification

Confirm the certificate on a Windows device

Open Manage Computer Certificates from the Start menu. The window title reads Certificates - Local Computer.
Open Personal > Certificates.
Confirm the device certificate is listed, the Issued By value contains your Common Name Filter, the General tab shows no trust warning, and, if the private key filter is enabled, the certificate icon shows a key.

Confirm the certificate on a macOS device

Open Keychain Access, select the System keychain, then select Certificates.
Confirm the device certificate is present and issued by the expected CA.

Confirm validation end to end

Start a Remote Support session from a managed device. The session should connect without a validation error.
Start a Remote Support session from a device without a certificate. The connection should be rejected with error 4043.

Troubleshooting

Error code	Meaning	What to check
`4043`	No matching device certificate was found on the device.	Confirm the certificate is installed for the Local Machine, the Issuer name contains the Common Name Filter text, the device trusts the issuing chain, and the certificate meets every filter enabled in your policy (private key, EKU, expiration).
`4044`	A certificate was found but is malformed or failed validation.	Confirm the certificate was issued by one of the issuing certificates configured in the Console, and that the PEM pasted there is the CA that signed the device certificate rather than a different CA in the chain.

On Windows, the Remote Support client debug log records every certificate store it scanned and every certificate it matched. Look for lines containing CertificatesHelper.FindCertificatesByIssuer, which report the number of matching certificates per store, and CertificatesHelper.GetCertificates, which list the Issuer, Subject, and Thumbprint of each certificate sent. A count of zero in every store indicates the certificate is not installed where the client can read it. Contact ScreenMeet Support with these log lines if validation fails after the checks above.