Create a Safe Local Test Certificate with Mono makecert
Mono makecert builds a self-signed X.509 certificate and private key for local testing in a couple of commands, no certificate authority required. The examples use Mono MakeCert 6.8.0.105 from mono-devel version 6.8.0.105+dfsg-3.6ubuntu2, as installed on this machine. This is a legacy test utility, not a certificate authority and not a sensible default for public TLS.
The route
Jump straight to the step you need, or tick off Done means at the end.
- 1. Confirm the Installed Command
- 2. Create an Isolated Working Directory
- 3. Generate the Self-Signed Certificate
- 4. Verify the Result and Permissions
- 5. Add Server Identity and Usage Constraints for TLS Testing
- 6. Avoid the Legacy Algorithm and Validity Traps
- 7. Remove the Test Material When You Are Finished
Allow about fifteen minutes. You need a shell, the mono-devel package, and a directory where you can keep test credentials. None of the commands need sudo. Keep the private key out of shared directories and do not reuse it outside the test environment.
1. Confirm the Installed Command
Check the binary and package before copying anything below. This is read-only:
$ command -v makecert
/usr/bin/makecert
$ makecert -?
Mono MakeCert - version 6.8.0.105
X.509 Certificate Builder
...
$ dpkg-query -W -f='${Package} ${Version}\n' mono-devel
mono-devel 6.8.0.105+dfsg-3.6ubuntu2
The command shape is makecert [options] certificate, where the final argument is the certificate file to create. Options such as -n, -r and -sv control the subject, the signing arrangement and the subject private key.
Checkpoint
If command -v finds nothing, stop here and install the package through your normal system-management process. Do not download an unrelated replacement binary just to match this guide.
2. Create an Isolated Working Directory
Choose a new directory for the certificate and key. This example uses a path under your home directory and locks the directory to your account:
$ umask 077
$ mkdir -p "$HOME/makecert-demo"
$ cd "$HOME/makecert-demo"
$ pwd
/home/your-user/makecert-demo
Swap /home/your-user in the displayed path for your actual home directory. The umask affects files created by the shell and by makecert during this session; it is not a substitute for checking permissions afterwards.
Do not point the output at a directory used by a live web server, a system trust store or a source-control checkout. This workflow creates private material and is deliberately unprivileged.
3. Generate the Self-Signed Certificate
Run this from the empty working directory:
$ makecert -r \
-n 'CN=demo.example.invalid' \
-sv demo.pvk \
-m 1 \
demo.cer
Mono MakeCert - version 6.8.0.105
X.509 Certificate Builder
...
Success
-r makes the certificate self-signed. -n sets its subject distinguished name. The -sv path is the subject private-key file; if it does not exist, MakeCert creates a new key pair, documented by this version as 1024-bit RSA. -m 1 asks for a one-month validity period, calculated from the not-before time. The certificate itself lands in demo.cer.
The name uses the reserved .invalid suffix so it is obviously a test identity. A self-signed certificate does not become trusted just because its common name looks like a real host name.
Security warning
Do not put a real password, production host name or production private key into a throwaway test directory. This MakeCert build supports PKCS#12 export with -p12, but the manpage also records that PVK files with passwords are not supported. Treat the generated PVK as unencrypted private material.
4. Verify the Result and Permissions
Check that both files exist, are non-empty, and are not readable by other users:
$ ls -l demo.pvk demo.cer
-rw------- 1 your-user your-group 620 ... demo.pvk
-rw------- 1 your-user your-group 453 ... demo.cer
$ test -s demo.pvk && test -s demo.cer && echo 'certificate and key are non-empty'
certificate and key are non-empty
$ stat -c '%a %n' demo.pvk demo.cer
600 demo.pvk
600 demo.cer
Sizes and timestamps will vary. What matters: both paths exist, both files have content, and the mode is 600 or something else that excludes group and other access. If either file is more open, fix only these test files:
$ chmod 600 demo.pvk demo.cer
$ stat -c '%a %n' demo.pvk demo.cer
If MakeCert reports success but a file is missing, stop before using the certificate. Check the current directory with pwd and inspect the exit status by rerunning the command with new output names, since shell redirection or a later command can otherwise hide which step failed.
5. Add Server Identity and Usage Constraints for TLS Testing
The basic example is enough to test file handling, but a TLS client may inspect extensions. The manpage supports a subject alternative name file, one DNS name per line, and the server-authentication extended key usage OID:
$ printf '%s\n' 'demo.example.invalid' 'localhost' > names.txt
$ makecert -r \
-n 'CN=demo.example.invalid' \
-alt names.txt \
-eku 1.3.6.1.5.5.7.3.1 \
-sv tls-demo.pvk \
-m 1 \
tls-demo.cer
Success
That OID is for server authentication. The -alt file is read as DNS entries, so use host names rather than URLs, ports or paths, and keep names.txt private if the names reveal internal systems. Verify it before generation:
$ sed -n '1,10p' names.txt
demo.example.invalid
localhost
Use the generated certificate only in the test client or server that needs it. A browser or TLS library will normally warn, because the certificate is self-signed and is not anchored in the system trust store. Do not silence that warning by importing this certificate into a workstation-wide or production trust store.
6. Avoid the Legacy Algorithm and Validity Traps
This installed utility documents only MD5 and SHA1 for -a. Do not select MD5, and do not read the available SHA1 option as a recommendation for new public certificates. Modern certificate authorities and TLS stacks have their own supported workflows; MakeCert earns its keep here for compatibility tests where the test boundary is understood.
The default validity period is not a durable policy. Set -m explicitly for a short-lived test, or use -b and -e when you need a reproducible validity window. The date syntax is accepted by the installed program rather than defined in detail by the short manpage, so test the exact dates on this machine before automating them.
Do not reach for -cy authority casually. It marks an authority certificate that may sign other certificates, while -cy end marks an end-entity certificate. A test CA is a separate exercise with a chain, trust distribution and revocation decisions of its own. This guide only creates a self-signed leaf-like test certificate.
7. Remove the Test Material When You Are Finished
There is no service to restart and no trust configuration to undo. When the test is over, remove only the directory you created, after confirming it holds nothing you need:
$ pwd
/home/your-user/makecert-demo
$ find . -maxdepth 1 -type f -printf '%f\n'
demo.pvk
demo.cer
names.txt
$ cd ..
$ rm -rf -- makecert-demo
$ test ! -e makecert-demo && echo 'test directory removed'
test directory removed
Warning
rm -rf is irreversible. Check pwd and the file list first, and swap in only the exact directory you created for this test. Need the files for a later test? Keep the directory and lock it down with chmod 700 instead.
Done means
- Confirmed the version.
makecertand the installed Mono package version were checked. - Created certificate and key. Both exist in an isolated directory.
- Kept it explicit. The subject, one-month validity and generated paths were deliberate, not defaults you forgot about.
- Verified files and permissions. Both files have content and private permissions.
- Named the hosts properly. Any DNS names went in as subject alternative names, not hidden in a common name alone.
- Kept it out of production. The certificate stayed out of system trust stores and live services.
- Cleaned up, or locked down. The test key and certificate were removed, or the directory stays deliberately protected for another test.