Toggle Mono's Test Root Trust Safely with setreg

setreg flips one Mono setting: whether Mono trusts its own self-signed test root certificates for the current user. You will inspect that setting, turn it on or off for a controlled test, and verify the change actually took, rather than trusting a banner or an exit code. The examples use setreg from mono-devel version 6.8.0.105+dfsg-3.6ubuntu2, whose program reports Mono Set Registry version 6.8.0.105.

• Time: about ten minutes.
• You need: a shell and the Mono development tools package.
• Privileges: none. setreg changes the current user's trust store, not a machine-wide setting. Do not add sudo unless your own account cannot reach its Mono configuration.
• Do not: use a production trust store for your first test.

1. Check the installed command

Confirm which executable is on your path and record the package version. These are read-only checks:

$ command -v setreg
/usr/bin/setreg
$ dpkg-query -W -f='${Package} ${Version}\n' mono-devel
mono-devel 6.8.0.105+dfsg-3.6ubuntu2
$ setreg -help

The installed help option is documented as -help, with -h, -? and /? also accepted. The program's banner identifies the setting as Trusting Test Roots (Mono and Microsoft). The manual describes the command shape as setreg [options] [feature] [true|false].

2. Inspect the current setting

Run setreg without a feature or value. It prints the current configuration and does not request a change:

$ setreg
Mono Set Registry - version 6.8.0.105
Change settings for public key cryptography

Current configuration
1	Trusting Test Roots (Mono and Microsoft)	FALSE

On this installation, the command exits with status 0 and reports FALSE initially. Your result may be TRUE if another process or an earlier test has already changed the current user's setting. The row that matters is feature 1, not the wording of the banner above it.

The manpage calls feature 1 a trust-store operation. Setting it to TRUE adds two self-signed test certificates, one associated with Microsoft and one with Mono, to the current user's trust store. Setting it to FALSE removes them. This is security-sensitive: a certificate signed by one of those test roots can then be accepted as trusted by Mono applications for that user.

3. Enable test-root trust only for a controlled test

Before changing anything, confirm the application you are testing genuinely needs Mono's test roots. Never enable this setting as a general workaround for a broken certificate chain, and do not use it to make an unknown production endpoint look trustworthy.

When the test is authorised, enable feature 1:

$ setreg 1 true
$ printf 'setreg status: %s\n' "$?"
setreg status: 0

Status 0 means the operation completed for the current user. It does not prove that every Mono process has reloaded its certificate state, so restart the test application if its certificate store is cached.

$ setreg
Current configuration
1	Trusting Test Roots (Mono and Microsoft)	TRUE

The header and surrounding wording can vary with the installed build, but feature 1 should now show TRUE. Do not assume a silent command, or a zero exit status alone, proves the intended policy took hold: look at the row.

4. Revoke the setting when the test ends

Leaving test roots trusted widens certificate acceptance beyond the normal trust anchors. Treat the change like a temporary debugging switch and undo it as soon as the test no longer needs it:

$ setreg 1 false
$ setreg
Current configuration
1	Trusting Test Roots (Mono and Microsoft)	FALSE

This is the recovery command for the change made above: it removes the two test roots from the current user's trust store. If the setting was already TRUE before your work, do not blindly restore FALSE. Record the initial value first and restore that instead.

There is no service restart in this workflow, but an already-running process may still hold cached certificate objects or validation decisions. Stop and restart the test process according to its normal operating procedure, then inspect the setting again. Do not restart an unrelated production service just because setreg completed.

5. Exercise the command without touching your real account

For a first run, use a temporary home directory. This keeps Mono's per-user state separate from your normal account and lets you practise both directions without touching the real trust store:

$ test_home=$(mktemp -d /tmp/setreg-home.XXXXXX)
$ HOME="$test_home" setreg
$ HOME="$test_home" setreg 1 true
$ HOME="$test_home" setreg
$ HOME="$test_home" setreg 1 false
$ HOME="$test_home" setreg
Current configuration
1	Trusting Test Roots (Mono and Microsoft)	FALSE

The temporary directory name is a placeholder generated by mktemp. Keep it private while testing, and remove it with your normal temporary-file housekeeping once finished. The final check should show FALSE. If changing HOME does not isolate the result on your build, stop rather than experimenting against your real account: the setting may live in another per-user location.

Common traps

• Do not confuse test roots with a fix for real certificates. A failed production TLS check should be investigated through the endpoint chain, hostname, clock and CA deployment. Trusting self-signed test roots changes policy; it does not repair any of those causes.
• Do not use feature numbers from memory. This installed manpage documents feature 1 only, the test-root switch. Do not invent another number or pass a certificate filename.
• Use the literal values the documented syntax accepts. The verified examples use lowercase true and false. Keep the feature and value as separate shell arguments.
• Do not reach for root first. The setting is for the current user. Elevated execution can modify a different user's environment and make the result harder to diagnose.
• Treat -q cautiously. The manual describes it as limited console display, but this installed build still printed its banner and current configuration when invoked with -q. Do not write scripts that depend on it suppressing all output; check the exit status and configuration row instead.