First-Time Setup

What it is. A self-signed X.509 v3 certificate:

• Subject: CN=Arise RDP Signing
• SHA-1 thumbprint: 879BBF3F595E949E5F0AB977EE8F8C6724B9CFB0
• Key: RSA 2048, SHA-256 signature, CAPI provider, non-exportable private key
• Extensions: BasicConstraints = CA:TRUE, KeyUsage = DigitalSignature, KeyCertSign, EKU = 1.3.6.1.5.5.7.3.3 (Code Signing)
• Validity: 2026-05-15 → 2036-05-15 (10 years)

Where the private key lives. Only in Cert:\LocalMachine\My on the Arise portal server (go.arisesoftware.co.nz, 103.96.110.15). The AriseGuard ASP.NET Core process invokes rdpsign.exe against the private key to sign each per-session .rdp file at request time. The private key never leaves that machine.

Why CA:TRUE. mstsc’s chain validation refuses to anchor on a non-CA certificate even when it’s in Trusted Root Certification Authorities. Without CA:TRUE, the “Verify the publisher” dialog appears forever and the “Remember my choices” tick fails to persist. With CA:TRUE, chain validation accepts the cert as a trust anchor and publisher trust can be established normally.

Why self-signed. A publicly trusted OV code-signing cert (e.g. ssl.com eSigner, Certum Cloud Signing) is on the roadmap and would remove client-side install entirely. Until that’s in place, the self-signed cert + this one-time per-machine install is the working path.

Two layers of trust govern whether mstsc shows the verify dialog for a signed .rdp file:

1. Chain trust (certificate stores) decides whether the file’s publisher is recognised. Cert must validate via a trusted root and be trusted as a publisher. Without this you get the orange “Unknown publisher” warning. With it you get publisher name shown, Clipboard/Printers pre-ticked, username pre-filled.
2. Bypass list (registry policy) decides whether the yellow “Verify the publisher” dialog appears at all. The publisher’s thumbprint must be listed in SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\TrustedCertThumbprints under either HKCU or HKLM, and AllowSignedFiles=1 (DWORD) must also be present in the same key.

The three install paths and what each touches:

Why the script’s registry write sometimes fails. Many MDMs and AD GPOs lock the Policies subtree under HKCU with an ACL that denies user write — precisely because that key is meant to be set by management policy, not by user-mode software. On such machines:

• Cert-store writes succeed (chain trust works → publisher recognised, redirects + username work)
• HKCU registry write fails → bypass list not populated → verify dialog appears every session
• The “Remember my choices” tick targets the same locked HKCU key and also silently fails
• Running the script as admin writes to HKLM instead, which the same MDMs typically permit (since HKLM is intentionally writable by admins for org-managed apps), giving the “no dialog ever” result

The script detects admin via WindowsPrincipal.IsInRole(WindowsBuiltInRole.Administrator) and reports Mode: ADMIN or Mode: USER, then prints either SUCCESS, PARTIAL SUCCESS, or FAILED based on which writes actually persisted.

What it allows: mstsc honours signed-`.rdp` settings (redirect flags, pre-filled username, gateway settings) and skips the verify-publisher dialog — only for files whose signing-cert thumbprint matches the explicit allowlist value 879BBF3F…4B9CFB0.

What it does NOT allow:

• Any other signed .rdp file from a different publisher → still prompts (their thumbprint isn’t in TrustedCertThumbprints)
• Unsigned .rdp files → still get “Unknown publisher”
• Anything outside mstsc — the bypass list only affects mstsc.exe’s dialog logic
• The cert has EKU = Code Signing only — not Server Auth, Client Auth, S/MIME, or Document Signing. Windows will refuse to use it for those purposes even though it’s in Trusted Root

Theoretical concern with CA:TRUE. Because the cert has CA:TRUE and lives in Trusted Root, in principle Arise could issue further certs that chain off this root and have them trusted by your machines for whatever EKUs Arise puts on them. The mitigation is that the private key never leaves 103.96.110.15\Cert:\LocalMachine\My (non-exportable), and the only thing on that machine that uses the key is the AriseGuard portal’s rdpsign.exe invocation. If that’s an unacceptable risk in your environment, deploy only the cert (Trusted Root) and skip the bypass-list registry write — users get the verify dialog once and tick “Remember my choices”, no scripts run.

Goal: push the cert + bypass-list policy to all domain-joined or Intune-managed machines so users never see the install prompt or the verify dialog.

Group Policy (domain-joined):

1. Computer Configuration → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities → Import → select arise-rdp-signing.cer
2. Computer Configuration → Preferences → Windows Settings → Registry → New Registry Item:
   • Hive: HKEY_LOCAL_MACHINE
   • Key: SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
   • Value name: TrustedCertThumbprints
   • Value type: REG_SZ
   • Value data: 879BBF3F595E949E5F0AB977EE8F8C6724B9CFB0
3. Repeat: AllowSignedFiles = 1 (DWORD) in the same key

Intune (Endpoint Manager):

• Devices → Configuration profiles → Trusted certificate profile, upload arise-rdp-signing.cer, destination Computer certificate store - Root
• Devices → Configuration profiles → Settings catalog or Custom (OMA-URI) profile with two registry settings targeting the HKLM Terminal Services policy key shown above

After deployment, no per-user install is needed. Users get the same “no dialog ever” result as the admin install path described in the Setup Guide.

Contact support@arisesoftware.co.nz for the .cer file out-of-band, or fetch it directly from /AriseGuard/files/arise-rdp-signing.cer (797 bytes, SHA-1 thumbprint as above).

Scripted: arise-rdp-untrust.cmd detects admin and cleans accordingly:

• User mode: removes the cert from CurrentUser\Root and CurrentUser\TrustedPublisher, deletes the HKCU policy values, clears any HKCU\SOFTWARE\Microsoft\Terminal Server Client\PublisherBypassList entries set by “Remember my choices”. Warns if LocalMachine entries are also present (won’t touch them without admin).
• Admin mode: all of the above PLUS removes the cert from LocalMachine\Root + LocalMachine\TrustedPublisher and the HKLM policy values.

Manual:

• Cert: certmgr.msc (user) or certlm.msc (machine) → Trusted Root + Trusted Publishers → find Arise RDP Signing → right-click → Delete
• Registry: delete HKCU|HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\TrustedCertThumbprints and AllowSignedFiles. Delete the empty Terminal Services key if nothing else lives there.

After removal, the next .rdp session reverts to “Unknown publisher” warning + manual Clipboard/Printers ticks + manual username entry, but functionally works.

Short answer: on the roadmap. A publicly trusted OV code-signing certificate would chain to roots Windows already trusts, so no client-side cert install would be needed at all — users would just get the verify-publisher dialog once and tick “Remember my choices”.

Candidates evaluated:

• SSL.com eSigner — OV code-signing cert with cloud HSM. Confirmed to work with the rdpsign.exe signing path.
• Certum SimplySign — cloud HSM. Need to verify compatibility before purchase.
• Azure Trusted Signing (formerly Code Signing) — not available to NZ-registered orgs as of 2026-05.

Switching the codebase is trivial: only the RdpSignCertificateThumbprint in appsettings.Production.json changes. Both rdpsign.exe and the cert-store lookup are identical regardless of cert origin.