Generate and Check an Encrypted DSA Key with openssl gendsa

You will turn a DSA parameter file into an encrypted private key, check that the key is valid, and keep the temporary material in a directory with restricted permissions. Allow about ten minutes. You need the OpenSSL command line tools and a parameter file, or permission to create one for a test.

DSA is a legacy algorithm. Use this workflow when an existing application or protocol specifically requires DSA. For new designs, follow the application's current guidance instead of choosing DSA merely because this command is available.

1. Confirm the OpenSSL version and command

The installed manpage belongs to the Ubuntu openssl package, version 3.0.13 on this machine. Check the executable before relying on examples, because a different OpenSSL earlier in PATH can have different help text:

$ command -v openssl
/home/linuxbrew/.linuxbrew/bin/openssl
$ /usr/bin/openssl version
OpenSSL 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13)
$ /usr/bin/openssl gendsa -help

If you are following the package-aligned examples below, use /usr/bin/openssl explicitly. The command form is openssl gendsa [options] paramfile. The final argument is a DSA parameter file, not an existing private key.

Checkpoint: run /usr/bin/openssl gendsa -help and confirm that it identifies dsaparam-file as its positional input.

2. Prepare parameters in a private temporary directory

If you already have a parameter file, check its path and skip generation. For a disposable test, create parameters with dsaparam:

umask 077
WORKDIR=$(mktemp -d /tmp/openssl-gendsa.XXXXXX)
/usr/bin/openssl dsaparam -out "$WORKDIR/parameters.pem" 1024
ls -l "$WORKDIR/parameters.pem"

The number passed to dsaparam is the parameter size. The parameter file determines the size of the private key that gendsa creates. Keep this file private while it is being used, even though it is not itself the private key. The umask setting and temporary directory reduce accidental exposure; neither replaces the host's normal access controls.

Do not use sudo for this test. Elevated privileges are only appropriate when the destination or input is deliberately protected and your operational procedure requires them.

3. Generate an encrypted private key

Put the encryption option before the parameter filename. This example uses AES-256 and a disposable passphrase only to make the command non-interactive:

/usr/bin/openssl gendsa \
    -aes256 \
    -passout pass:replace-this-test-passphrase \
    -out "$WORKDIR/dsa-private-key.pem" \
    "$WORKDIR/parameters.pem"
stat -c 'key mode: %a' "$WORKDIR/dsa-private-key.pem"
sed -n '1p' "$WORKDIR/dsa-private-key.pem"

Expected output includes a restrictive mode such as 600 and a header like -----BEGIN ENCRYPTED PRIVATE KEY-----. The exact file mode can also be affected by the process umask.

Warning: -passout pass:... puts the passphrase in the shell command and possibly in process inspection or shell history. It is suitable only for a throwaway local test. For a real key, omit it and let OpenSSL prompt, or use a passphrase source appropriate to your deployment. Never paste a production passphrase into an article, script, ticket or command history.

Another easy trap is omitting the cipher. With no encryption option, gendsa writes an unencrypted private key. The command does not add protection by default. Also keep every option before the parameter filename: the manpage warns that encryption options after that argument are ignored.

4. Verify the key without printing its secret

Use pkey -check with the same passphrase source. This reads the encrypted key, checks its internal consistency and suppresses key details:

$ /usr/bin/openssl pkey \
    -in "$WORKDIR/dsa-private-key.pem" \
    -passin pass:replace-this-test-passphrase \
    -check -noout
Key is valid

Key is valid is the checkpoint that the file can be decrypted and passes OpenSSL's key check. A wrong passphrase normally produces an error instead. Do not treat the existence of a PEM file as proof that it is usable.

For an existing parameter file, a failure can mean the file is not a DSA parameter file, is truncated, or is unreadable. Check the path and permissions first. Do not overwrite the original parameter file while investigating.

5. Keep the output safe and remove the test material

Do not place a private key in a shared working directory, source repository or service configuration unless that is an intentional, reviewed deployment step. -out writes to the path you provide; without it, the key goes to standard output, where it is easy to leak into a terminal capture or log.

After verification, remove only the disposable files created for this test:

rm -f -- "$WORKDIR/dsa-private-key.pem" "$WORKDIR/parameters.pem"
rmdir -- "$WORKDIR"

Warning: deletion is irreversible if you have not retained a required key and its passphrase. For a real deployment, use your approved key backup and rotation procedure instead of this cleanup example. There is no OpenSSL undo command for a deleted private key.