Trust the wrong root certificate on a Mono host and every application sharing that store inherits the mistake. certmgr is the tool for inspecting Mono certificate stores, exporting a certificate, and knowing the boundaries before you import or delete trust material.
The examples target certmgr 6.8.0.105 from mono-devel 6.8.0.105+dfsg-3.6ubuntu2, installed here as /usr/bin/certmgr. Allow about fifteen minutes; you need a shell and a certificate file only for the import examples. The first half is read-only. Importing, deleting, downloading a server chain and importing a private key all change security state, so treat those as maintenance operations and keep a recovery copy wherever the format allows it.
Check the executable and package before trusting examples written for a different Mono release. This is an ordinary, unprivileged check:
$ command -v certmgr
/usr/bin/certmgr
$ certmgr -help
Mono Certificate Manager - version 6.8.0.105
Usage: certmgr [action] [object-type] [options] store [filename]
The installed help also shows a separate form for -ssl and the available object types. The manpage describes certificates as -c, -cert or -certificate; use the short -c form in scripts, so the command shape is easy to compare against the local help.
Checkpoint: if the version or usage line differs, run certmgr -help again and adjust the later command shape to match the installed program.
A store name selects a purpose, not a filename:
With no -m, certmgr works on the current user's stores:
$ certmgr -list -c Trust
Mono Certificate Manager - version 6.8.0.105
Manage X.509 certificates and CRL from stores.
A store with no certificates may print only the banner. On a populated store, each certificate carries a Unique Hash, and that hash, not the certificate filename, is what deletion uses to identify it. List another store just by swapping the final name:
$ certmgr -list -c My
$ certmgr -list -c CA
These commands read the user store and need no sudo. Do not confuse an empty Mono store with the operating system's OpenSSL or browser store: Mono applications use stores Mono itself understands, and the exact location is implementation detail, not a safe API to depend on.
Add -m when you specifically mean the machine certificate stores:
$ certmgr -list -c -m Trust
Mono Certificate Manager - version 6.8.0.105
Self-signed X.509 v3 Certificate
Unique Hash: 71B437F087F3700FFD4E2FA46F42B6B810D7BF19ADFEDF951C023EDD65B50B05
Certificate names and hashes are host-specific, so your output will differ. The important check is that -m is present and you are listing Trust. Machine stores are normally restricted: listing might work as your own account on one installation while adding or deleting needs elevated privileges on another.
Safety boundary: never add -m just to make one application trust a certificate. Machine trust affects other users and services. Test the user store first, identify the exact process that needs the trust, and use the narrowest store that meets it.
Use -put with the hash from a listing when another tool needs a copy. The output filename is the final argument:
$ certmgr -put -c Trust CERTIFICATE_HASH /tmp/mono-root.cer
$ file /tmp/mono-root.cer
/tmp/mono-root.cer: Certificate, Version=3
Replace CERTIFICATE_HASH with the complete value printed by -list. The default output is DER binary, with a .cer filename convention. This reads the store and writes a new file; it does not remove or alter the stored certificate. Pick a destination that is not already holding something valuable, because writing to an existing path can replace it.
For a Base64 PEM-style export, the installed help lists -pem:
$ certmgr -put -c -pem Trust CERTIFICATE_HASH /tmp/mono-root.pem
$ head -n 1 /tmp/mono-root.pem
-----BEGIN CERTIFICATE-----
Confirm the export with a certificate parser you already have, such as openssl x509 -in /tmp/mono-root.pem -noout -subject -issuer for the PEM form. Do not delete the temporary copy until you have checked the right certificate actually came out.
Warning: importing a certificate into Trust changes which Mono applications accept which certificate chains. Only import a root certificate after verifying its fingerprint through a separate, trusted channel. A file being readable, or named .cer, does not make it trustworthy.
For a DER-encoded X.509 certificate, use -add and -c:
$ openssl x509 -in /path/to/root.cer -inform DER -noout -subject -issuer -fingerprint -sha256
$ certmgr -add -c Trust /path/to/root.cer
$ certmgr -list -c Trust
That first command is a verification aid, not part of certmgr itself. If the source is PEM rather than DER, drop -inform DER when inspecting it, then use whatever format your installed certmgr accepts. Keep the import unprivileged unless you deliberately add -m:
$ certmgr -add -c -m Trust /path/to/root.cer
That machine-store form may need sudo on your host. Do not respond to an access error by blindly retrying as root: confirm a machine-wide trust change is genuinely required first, and record the certificate hash from the listing that follows.
Warning: -del changes trust state and can break Mono applications or reinstate an unwanted trust decision. Before deleting, export the exact certificate with -put and save the output somewhere protected, then list the store again and copy the hash carefully:
$ certmgr -put -c Trust CERTIFICATE_HASH /tmp/certificate-before-delete.cer
$ certmgr -del -c Trust CERTIFICATE_HASH
$ certmgr -list -c Trust
Use -m on the listing, export and deletion commands together whenever the certificate is in the machine store. The argument to -del is a hash, not a filename. If you delete the wrong user-store certificate, the practical undo is to verify the saved file and add it straight back:
$ certmgr -add -c Trust /tmp/certificate-before-delete.cer
$ certmgr -list -c Trust
For machine stores, restore with sudo certmgr -add -c -m Trust ... only after checking the file and the intended scope. A restored certificate may come back with the same displayed hash or a different one depending on the file and Mono release, so verify by subject and fingerprint too, not just by listing.
-ssl downloads certificates from a TLS session and asks for confirmation on each one received. It can add several certificates to appropriate stores at once, and a server is not obliged to send its root certificate. Because it downloads data and changes trust, never treat a live site as a casual test target:
$ certmgr -ssl https://service.example.test
Replace the example URL only once you have confirmed the endpoint, its certificate chain, and the stores certmgr will actually modify. Review every prompt, and never approve a root certificate just because the TLS handshake completed.
-importKey imports a private key from a PKCS#12 file into Mono's key-pair store, which is a different act from importing a public certificate; the password protects sensitive material while it is being read:
$ certmgr -importKey My /path/to/client-identity.p12
Password: [enter it without recording it in shell history]
Use -p only when your local operational policy actually permits a password on the command line: command-line arguments can be visible to other processes. Protect the PKCS#12 file, keep it out of shared temporary directories, and never put a real password in a copied example. If a service will use the key, test the complete certificate and key pairing before you replace an existing identity.
-m.