Home / Alt manpages / makecert(1)

  • makecert(1)
  • User command
  • linux

Create a Safe Local Test Certificate with Mono makecert

You will finish with a self-signed X.509 certificate and its private key for local testing. 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 or a sensible default for public TLS.

The route

Jump straight to the step you need, or tick off Done means at the end.

Allow about fifteen minutes. You need a shell, the mono-devel package, and a directory where you can keep test credentials. The commands do not need sudo. Keep the private key away from shared directories and do not reuse it outside the test environment.

1. Confirm the installed command

Check the binary and package before copying an example. 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. The final argument is the certificate file to create. Options such as -n, -r and -sv control the subject, signing arrangement and 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. The 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

Replace /home/your-user in the displayed path with 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 command 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 a 1024-bit RSA pair. -m 1 asks for a one-month validity period, calculated from the not-before time. The certificate is written to demo.cer.

The name uses the reserved .invalid suffix so it is clearly a test identity. A self-signed certificate will not become trusted merely 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

File sizes and timestamps vary. The useful checks are that both paths exist, both files have content, and the mode is 600 or another mode that excludes group and other access. If either file is more open, correct 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 command's exit status by rerunning it only with new output names. Shell redirection or a later command can otherwise hide which step failed.

5. Add server identity and usage constraints when testing TLS

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

The OID is for server authentication. The -alt file is read as DNS entries, so use host names rather than URLs, ports or paths. 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 legacy algorithm and validity traps

This installed utility documents only MD5 and SHA1 for -a. Do not select MD5, and do not interpret the available SHA1 option as a recommendation for new public certificates. Modern certificate authorities and TLS stacks have their own supported workflows. MakeCert is useful 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 a reproducible validity window is required. 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 putting them in automation.

Do not use -cy authority casually. It marks an authority certificate that may be used to 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. This guide creates only a self-signed leaf-like test certificate.

7. Remove the test material when 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 contains no files 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 replace the directory name only with the exact directory you created for this test. If you need the files for a later test, keep the directory and restrict it with chmod 700 instead.

Done means

  • makecert and the installed Mono package version were confirmed.
  • A self-signed certificate and private key were created in an isolated directory.
  • The subject, one-month validity and generated paths were explicit.
  • Both files were checked for content and private permissions.
  • Any DNS names were supplied as subject alternative names, not hidden in a common name alone.
  • The certificate was kept out of system trust stores and production services.
  • The test key and certificate were removed, or the directory remains deliberately protected for another test.