OpenSSL dgst: Create Checksums and Verify Digital Signatures

Overview

A software vendor publishes a new application package:

application-release.tar.gz

along with a SHA-256 checksum.

Before installing that package on a server, you want to answer:

Is the file I downloaded exactly the same file the vendor published?

Later, your own team distributes an internal deployment artifact and needs stronger assurance than a checksum alone.

You want recipients to be able to answer:

Was this file actually signed by the expected private key?

The OpenSSL dgst command handles both workflows.

It can:

• calculate SHA-256 and other message digests;
• compare file hashes;
• generate binary or hexadecimal digests;
• sign a file using a private key;
• verify that signature with the corresponding public key;
• work with RSA, DSA, ECDSA, and supported modern signature algorithms;
• output hashes in formats useful for shell scripts;
• process standard input as well as files.

The official OpenSSL dgst documentation describes the command as a tool for performing message-digest operations and generating or verifying digital signatures. OpenSSL uses SHA-256 as the default digest when none is explicitly selected.

This tutorial uses two practical system-administration scenarios:

1. verifying the SHA-256 checksum of a downloaded deployment artifact;
2. digitally signing an internally distributed file and verifying that signature on another system.

What is a message digest?

A message digest is a fixed-length value calculated from arbitrary input data.

For example:

application-release.tar.gz
        ↓
      SHA-256
        ↓
6eae...f417

Even a tiny change to the file should produce a different digest.

Message digests are commonly used for:

• file-integrity verification;
• software-download checksums;
• comparing files across systems;
• detecting accidental corruption;
• digital-signature operations;
• identifying files in automation.

A digest is also commonly called a:

hash
checksum
fingerprint

depending on context.

Technically, those terms are not always interchangeable, but administrators frequently use them this way when discussing file integrity.

What does openssl dgst do?

The basic syntax is:

openssl dgst [digest] [options] file

For example:

openssl dgst -sha256 application-release.tar.gz

A shorter equivalent is:

openssl sha256 application-release.tar.gz

OpenSSL permits supported digest names to be used directly as subcommands.

The output resembles:

SHA2-256(application-release.tar.gz)= 6eae...

If you do not explicitly select a digest, OpenSSL uses SHA-256 by default:

openssl dgst application-release.tar.gz

For scripts and documentation, I recommend specifying the digest explicitly:

openssl dgst -sha256 application-release.tar.gz

That makes the intended algorithm obvious.

OpenSSL version compatibility

This article covers:

• OpenSSL 3.0;
• OpenSSL 3.1;
• OpenSSL 3.2;
• OpenSSL 3.3;
• OpenSSL 3.4;
• OpenSSL 3.5 LTS;
• OpenSSL 4.0.

Check your installed version:

openssl version

For detailed build information:

openssl version -a

The core digest and signature workflow remains consistent:

openssl dgst -sha256 file
openssl dgst -sha256 -sign private.key -out signature.bin file
openssl dgst -sha256 -verify public.key -signature signature.bin file

OpenSSL 3.0

OpenSSL 3.0 is the minimum version covered by this series.

The command supports:

• file digests;
• RSA, DSA, and ECDSA-style signatures;
• HMAC and MAC options;
• provider configuration.

The older:

-engine
-engine_impl

options were deprecated in OpenSSL 3.0.

OpenSSL 3.5 LTS

OpenSSL 3.5 adds documented:

-provparam

support alongside the normal provider options.

It also documents one-shot signature algorithms such as Ed25519, Ed448, and ML-DSA. For algorithms that only support one-shot signing, you must not explicitly select a digest such as -sha256; OpenSSL handles the required signing behavior internally.

OpenSSL 4.0

OpenSSL 4.0 removes:

-engine
-engine_impl

from openssl dgst.

It also adds:

-hmac-env
-hmac-stdin

for obtaining HMAC keys from an environment variable or standard input.

The normal SHA-256 hashing and public-key signature workflows remain unchanged.

Real-world scenario 1: verify a downloaded software package

Assume you downloaded:

application-release.tar.gz

The publisher provides this SHA-256 digest:

a4d91b4f8f2d0db4e648f24896544ac0e09aa3525bb27e5d67fe31e6794f117a

Your job is to calculate the local file’s SHA-256 digest and compare it with the independently published value.

Step 1: Calculate the SHA-256 digest

Run:

openssl dgst \
  -sha256 \
  application-release.tar.gz

Example output:

SHA2-256(application-release.tar.gz)= a4d91b4f8f2d0db4e648f24896544ac0e09aa3525bb27e5d67fe31e6794f117a

Compare only the hexadecimal digest:

a4d91b4f8f2d0db4e648f24896544ac0e09aa3525bb27e5d67fe31e6794f117a

If it matches the trusted checksum exactly, the file contents match the file used to calculate that digest.

Step 2: Understand what checksum verification proves

A matching digest proves:

Downloaded file bytes
        =
Original hashed file bytes

It helps detect:

• corrupted transfers;
• incomplete downloads;
• accidental modification;
• substitution when the trusted checksum itself remains authentic.

But a checksum alone does not prove who created the file.

If an attacker can replace both:

application-release.tar.gz

and:

published checksum

the malicious file can still match the malicious checksum.

For authenticity, use a digital signature whose verification key was obtained through a trusted channel.

Step 3: Output only the digest in a script-friendly form

OpenSSL’s default output includes the algorithm and filename.

You can extract the hash:

openssl dgst \
  -sha256 \
  application-release.tar.gz |
awk '{print $2}'

Example:

a4d91b4f8f2d0db4e648f24896544ac0e09aa3525bb27e5d67fe31e6794f117a

Store it:

actual_hash="$(
  openssl dgst \
    -sha256 \
    application-release.tar.gz |
  awk '{print $2}'
)"

Then compare:

expected_hash="a4d91b4f8f2d0db4e648f24896544ac0e09aa3525bb27e5d67fe31e6794f117a"
if [ "$actual_hash" = "$expected_hash" ]; then
    echo "Checksum verified"
else
    echo "Checksum mismatch" >&2
    exit 1
fi

This is useful in deployment scripts.

Step 4: Use coreutils-style output

OpenSSL provides:

-r

to output the digest in a format similar to utilities such as sha1sum.

Run:

openssl dgst \
  -sha256 \
  -r \
  application-release.tar.gz

Example:

a4d91b4f8f2d0db4e648f24896544ac0e09aa3525bb27e5d67fe31e6794f117a *application-release.tar.gz

This can be easier to process in scripts.

Step 5: Hash more than one file

You can specify multiple files:

openssl dgst \
  -sha256 \
  file-one.tar.gz \
  file-two.tar.gz \
  file-three.tar.gz

Each file receives its own digest.

This is useful for:

• release directories;
• backup verification;
• migration validation;
• checking replicated files.

The official documentation notes, however, that signing and verification options should be used only when operating on a single file.

Step 6: Hash standard input

If no filename is provided, OpenSSL reads standard input.

For example:

printf '%s' 'Example data' |
openssl dgst -sha256

This is useful in shell pipelines.

Be careful with:

echo

because it normally adds a newline.

These two commands produce different hashes:

echo 'Example data' |
openssl dgst -sha256

and:

printf '%s' 'Example data' |
openssl dgst -sha256

The newline is part of the input data.

Step 7: Compare two local files

Assume:

original.tar.gz
copied.tar.gz

should be identical.

Calculate:

openssl dgst \
  -sha256 \
  original.tar.gz \
  copied.tar.gz

If both hashes match, the file contents are identical for practical integrity-checking purposes.

For automation:

hash_one="$(
  openssl dgst -sha256 original.tar.gz |
  awk '{print $2}'
)"
hash_two="$(
  openssl dgst -sha256 copied.tar.gz |
  awk '{print $2}'
)"
if [ "$hash_one" = "$hash_two" ]; then
    echo "Files match"
else
    echo "Files differ"
fi

This can be useful after:

• SFTP transfers;
• backups;
• storage migrations;
• artifact replication.

Step 8: Calculate SHA-512

Use:

openssl dgst \
  -sha512 \
  application-release.tar.gz

Or:

openssl sha512 \
  application-release.tar.gz

Whether SHA-256 or SHA-512 is appropriate depends on the interoperability and security requirements.

For general modern applications, OpenSSL specifically recommends SHA-256 for new or algorithm-agile applications. It notes that older digests such as SHA-1 and MD5 are still encountered mainly for compatibility with existing formats and protocols.

Step 9: List available digest algorithms

Run:

openssl list -digest-algorithms

The exact output depends on:

• OpenSSL version;
• providers;
• build configuration;
• system security policy.

You may see algorithms such as:

SHA256
SHA384
SHA512
SHA3-256
SHA3-384
SHA3-512
BLAKE2b512
BLAKE2s256
SHAKE128
SHAKE256

The official documentation recommends this command for discovering which digest algorithms the installed OpenSSL build supports.

For more OpenSSL capability-discovery techniques, see How to List OpenSSL Commands and Get Command Help.

Step 10: Avoid MD5 for new integrity workflows

You may still encounter:

openssl dgst -md5 file

or:

openssl md5 file

in old documentation.

OpenSSL continues to support older digest algorithms in some environments for compatibility, but its documentation recommends SHA-256 for new or agile applications.

For new checksum workflows, prefer:

openssl dgst -sha256 file

unless a particular protocol or vendor requires another digest.

Step 11: Use hexadecimal output

For normal digest operations, hexadecimal output is already the default.

Explicitly:

openssl dgst \
  -sha256 \
  -hex \
  file.bin

The result is human-readable hexadecimal.

Use this when the expected value is published as a normal checksum string.

Step 12: Output the digest as binary

Use:

openssl dgst \
  -sha256 \
  -binary \
  file.bin \
  > file.sha256.bin

This writes the raw 32-byte SHA-256 digest.

Check:

wc -c file.sha256.bin

Expected:

32

Binary digest output is useful when:

• another protocol expects raw digest bytes;
• feeding the result into another cryptographic operation;
• building interoperability test cases.

For ordinary checksum comparisons, hexadecimal output is easier.

Step 13: Create colon-separated hexadecimal output

Use:

openssl dgst \
  -sha256 \
  -c \
  file.bin

The output resembles:

A4:D9:1B:4F:...

This style is more common with fingerprints than file checksums, but can be useful for certain tooling or documentation.

Real-world scenario 2: digitally sign an artifact

A checksum provides integrity only if the checksum itself is trusted.

A digital signature provides a stronger model.

Assume your team distributes:

deployment-package.tar.gz

The signing system has:

release-signing.key
release-signing.pub

The private key stays on the signing system.

The public key can be distributed to systems that need to verify releases.

The workflow is:

deployment-package.tar.gz
          ↓
SHA-256 digest
          ↓
Sign with private key
          ↓
deployment-package.sig

The verifier later performs:

deployment-package.tar.gz
          +
deployment-package.sig
          +
release-signing.pub
          ↓
Signature verification

Step 14: Generate a private signing key

For an RSA example:

openssl genpkey \
  -algorithm RSA \
  -pkeyopt rsa_keygen_bits:3072 \
  -out release-signing.key

Protect it:

chmod 600 release-signing.key

Validate:

openssl pkey \
  -in release-signing.key \
  -check \
  -noout

The private key should remain restricted to the authorized signing system.

Step 15: Extract the public key

Run:

openssl pkey \
  -in release-signing.key \
  -pubout \
  -out release-signing.pub

Inspect:

openssl pkey \
  -pubin \
  -in release-signing.pub \
  -text \
  -noout

The public key can be distributed to verifier systems without exposing the private signing key.

Step 16: Sign the file with SHA-256

Run:

openssl dgst \
  -sha256 \
  -sign release-signing.key \
  -out deployment-package.sig \
  deployment-package.tar.gz

OpenSSL hashes the file and signs the result using the private key.

The signature output is binary by default for signing operations.

Check:

file deployment-package.sig

Do not expect the signature to be readable text.

The official OpenSSL documentation uses the same general -sha256 -sign privatekey -out signature file workflow.

Step 17: Verify the signature

On the receiving system, provide:

deployment-package.tar.gz
deployment-package.sig
release-signing.pub

Run:

openssl dgst \
  -sha256 \
  -verify release-signing.pub \
  -signature deployment-package.sig \
  deployment-package.tar.gz

Expected:

Verified OK

If the file or signature does not match:

Verification Failure

OpenSSL documents -verify as using the public key supplied in the specified file.

Step 18: Demonstrate tamper detection

Copy the package:

cp \
  deployment-package.tar.gz \
  modified-package.tar.gz

Modify it:

printf '\n' >> modified-package.tar.gz

Now verify the existing signature:

openssl dgst \
  -sha256 \
  -verify release-signing.pub \
  -signature deployment-package.sig \
  modified-package.tar.gz

Expected:

Verification Failure

The signature was created for the exact original file bytes.

Even a one-byte change invalidates the signature.

What digital signature verification proves

A successful verification establishes that:

The file matches the signature
        +
The signature was produced using
the private key corresponding to
the supplied public key

But it does not automatically establish who owns that public key.

You still need a trusted method of obtaining:

release-signing.pub

Possible methods include:

• configuration management;
• a trusted repository;
• a certificate;
• a known public-key fingerprint;
• a secure provisioning process.

Public-key authenticity is part of the trust model.

Step 19: Verify with the private key

OpenSSL also provides:

-prverify

which verifies using a private key:

openssl dgst \
  -sha256 \
  -prverify release-signing.key \
  -signature deployment-package.sig \
  deployment-package.tar.gz

This is usually more useful during testing on the signing system.

Normal recipients should receive only the public key and use:

-verify

There is no reason to distribute the private signing key merely so another system can verify a signature.

Step 20: Sign with an encrypted private key

Generate an encrypted key:

openssl genpkey \
  -algorithm RSA \
  -pkeyopt rsa_keygen_bits:3072 \
  -aes-256-cbc \
  -out release-signing.key

When signing:

openssl dgst \
  -sha256 \
  -sign release-signing.key \
  -out deployment-package.sig \
  deployment-package.tar.gz

OpenSSL prompts for the passphrase.

For automation, openssl dgst supports:

-passin

using OpenSSL’s standard passphrase-source syntax.

Avoid putting real passphrases directly into shell command history.

Step 21: Use a certificate’s public key for verification

Sometimes the signing public key is distributed in an X.509 certificate rather than a standalone public-key file.

Assume:

release-signer.crt

Extract its public key:

openssl x509 \
  -in release-signer.crt \
  -pubkey \
  -noout \
  -out release-signer.pub

Then verify:

openssl dgst \
  -sha256 \
  -verify release-signer.pub \
  -signature deployment-package.sig \
  deployment-package.tar.gz

If the signing certificate matters to your trust model, validate it separately:

openssl verify \
  -CAfile trusted-ca.pem \
  release-signer.crt

This is an important distinction.

openssl dgst verifies the signature itself. It does not perform the broader certificate identity and chain-processing workflow used by CMS, S/MIME, or X.509. OpenSSL explicitly notes this limitation.

For certificate validation, see OpenSSL verify.

openssl dgst versus openssl cms

Both commands can create digital signatures, but they solve different problems.

openssl dgst

Produces a raw cryptographic signature.

You manage:

data file
signature file
public key

separately.

Example:

deployment.tar.gz
deployment.sig
release-signing.pub

openssl cms

Creates a structured CMS object that can include:

• signer certificate;
• signed attributes;
• content;
• certificate chains;
• multiple signers.

Use openssl dgst when you want a simple raw-signature workflow.

Use openssl cms when you need a standardized cryptographic message container.

See OpenSSL cms: Sign, Verify, Encrypt, and Decrypt Files.

Step 22: Sign with ECDSA

Generate an EC private key:

openssl genpkey \
  -algorithm EC \
  -pkeyopt ec_paramgen_curve:P-256 \
  -out ecdsa-signing.key

Extract the public key:

openssl pkey \
  -in ecdsa-signing.key \
  -pubout \
  -out ecdsa-signing.pub

Sign:

openssl dgst \
  -sha256 \
  -sign ecdsa-signing.key \
  -out file.sig \
  file.bin

Verify:

openssl dgst \
  -sha256 \
  -verify ecdsa-signing.pub \
  -signature file.sig \
  file.bin

OpenSSL determines the signing algorithm from the private key information when signing.

Step 23: Ed25519 behaves differently

Ed25519 is a one-shot signature algorithm.

Do not run:

openssl dgst \
  -sha256 \
  -sign ed25519.key \
  file.bin

OpenSSL’s documentation specifically says that for one-shot signing algorithms such as Ed25519 and Ed448, a digest must not be set explicitly.

Instead:

openssl dgst \
  -sign ed25519.key \
  -out file.sig \
  file.bin

Verify:

openssl dgst \
  -verify ed25519.pub \
  -signature file.sig \
  file.bin

For one-shot algorithms, OpenSSL buffers the input rather than applying a separately selected digest.

OpenSSL 3.5/4.0 documentation also notes a 16 MB input limit for one-shot algorithms handled by dgst.

Step 24: ML-DSA and OpenSSL 3.5+

Modern OpenSSL versions also document ML-DSA one-shot signing algorithms such as:

ML-DSA-44
ML-DSA-65
ML-DSA-87

As with Ed25519, do not explicitly specify:

-sha256

for these algorithms when using openssl dgst.

Availability depends on:

• OpenSSL version;
• providers;
• build configuration.

Check:

openssl list -signature-algorithms

before designing automation around a particular signature type.

Step 25: Understand XOF digests

OpenSSL supports extendable-output functions such as:

SHAKE128
SHAKE256

These can produce digests of selectable length.

Use:

-xoflen

For example:

openssl dgst \
  -shake128 \
  -xoflen 32 \
  file.bin

OpenSSL’s provider documentation notes that SHAKE128 should use at least 32 bytes for its maximum 128-bit security strength, while SHAKE256 should use at least 64 bytes for its maximum 256-bit strength.

This is a specialized workflow.

For normal administrative checksum operations:

SHA-256

is simpler and widely interoperable.

Step 26: Generate an HMAC

openssl dgst supports:

-hmac

For example:

openssl dgst \
  -sha256 \
  -hmac 'example-secret' \
  file.bin

An HMAC combines:

secret key
+
message
+
hash function

and provides integrity plus shared-secret authentication.

However, OpenSSL explicitly recommends the dedicated:

openssl mac

command instead of the legacy dgst -hmac, -mac, and -macopt options for new workflows.

So while you may encounter:

openssl dgst -sha256 -hmac ...

in existing scripts, prefer:

openssl mac

when building new MAC-based processes.

OpenSSL 4.0 HMAC improvements

OpenSSL 4.0 adds:

-hmac-env

and:

-hmac-stdin

These allow the HMAC key to come from:

• an environment variable;
• standard input.

This avoids putting the HMAC secret directly into the process argument list.

These options do not exist in OpenSSL 3.0, so they should not be used in scripts that must run across the full 3.0–4.0 range.

Step 27: Do not convert signatures to hex unless necessary

By default, digital signatures produced by openssl dgst -sign are binary.

Keep them binary:

deployment-package.sig

If you transform a signature into hexadecimal, OpenSSL cannot directly verify that hex text.

The official documentation notes that hexadecimal signatures must first be converted back to binary using a utility such as:

xxd -r

before verification.

For ordinary signature workflows:

binary signature

is simpler.

Step 28: Base64-encode a signature for text transport

If you need to send the binary signature through a text-only system, Base64 is usually easier than hexadecimal.

Create the signature:

openssl dgst \
  -sha256 \
  -sign release-signing.key \
  -out deployment-package.sig \
  deployment-package.tar.gz

Encode it:

openssl base64 \
  -in deployment-package.sig \
  -out deployment-package.sig.b64

On the receiving system:

openssl base64 \
  -d \
  -in deployment-package.sig.b64 \
  -out deployment-package.sig

Then verify normally:

openssl dgst \
  -sha256 \
  -verify release-signing.pub \
  -signature deployment-package.sig \
  deployment-package.tar.gz

Step 29: Use exit codes in automation

A verification script should rely on the command exit status.

Example:

if openssl dgst \
  -sha256 \
  -verify release-signing.pub \
  -signature deployment-package.sig \
  deployment-package.tar.gz
then
    echo "Signature valid"
else
    echo "Signature verification failed" >&2
    exit 1
fi

Do not merely search output for:

Verified OK

when the shell can evaluate the actual result.

This makes the script clearer and less fragile.

Step 30: Build a release-verification script

Create:

cat > verify-release.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
artifact="deployment-package.tar.gz"
signature="deployment-package.sig"
public_key="release-signing.pub"
for file in "$artifact" "$signature" "$public_key"; do
    if [ ! -r "$file" ]; then
        echo "ERROR: cannot read $file" >&2
        exit 1
    fi
done
echo "SHA-256:"
openssl dgst -sha256 "$artifact"
echo
echo "Verifying digital signature..."
if openssl dgst \
    -sha256 \
    -verify "$public_key" \
    -signature "$signature" \
    "$artifact"
then
    echo "Release signature verified."
else
    echo "ERROR: release signature invalid." >&2
    exit 1
fi
EOF

Make executable:

chmod +x verify-release.sh

Run:

./verify-release.sh

This provides both:

human-readable checksum
+
cryptographic signature verification

before deployment.

Step 31: Check providers if a digest is unavailable

List providers:

openssl list -providers

Then digests:

openssl list -digest-algorithms

If an expected algorithm is unavailable, possible causes include:

• provider not loaded;
• algorithm disabled;
• OpenSSL build configuration;
• system cryptographic policy;
• FIPS restrictions.

Do not assume every OpenSSL 3 installation exposes identical algorithms.

For OpenSSL inventory techniques, see How to List OpenSSL Commands and Get Command Help.

Common openssl dgst errors

Unknown option or digest

Check:

openssl dgst -help

Then:

openssl list -digest-algorithms

You may be using:

• an unavailable digest;
• an option added in a newer OpenSSL release;
• syntax intended for another command.

Error opening file

Check:

ls -l file.bin

Confirm:

• path;
• permissions;
• working directory;
• filename spelling.

Could not read private key

Test:

openssl pkey \
  -in release-signing.key \
  -check \
  -noout

Possible causes include:

• wrong key file;
• encrypted key without passphrase;
• damaged PEM structure;
• permissions.

Verification Failure

Possible causes include:

• file changed after signing;
• wrong public key;
• wrong signature file;
• wrong digest algorithm;
• signature corrupted during transfer.

Check the digest selection first.

If signing used:

-sha256

verification must normally use the corresponding signature setup:

-sha256

for algorithms where an external digest is used.

Key type not supported for this operation

The selected signing algorithm may behave differently from RSA/ECDSA.

For one-shot algorithms such as Ed25519, do not explicitly specify a digest.

Error with Ed25519 and -sha256

Remove:

-sha256

and sign directly:

openssl dgst \
  -sign ed25519.key \
  -out file.sig \
  file.bin

Input too large with one-shot signature algorithm

OpenSSL documents a 16 MB input limit in dgst for one-shot algorithms such as Ed25519, Ed448, and ML-DSA.

For larger structured signing workflows, consider a format/tool designed for that requirement.

HMAC key visible in process list

Avoid:

openssl dgst \
  -sha256 \
  -hmac 'real-production-secret' \
  file.bin

in sensitive automation.

For OpenSSL 4.0, -hmac-env and -hmac-stdin offer safer input options, but for new MAC designs OpenSSL recommends the dedicated openssl mac command.

Important openssl dgst options

For the complete syntax, see the official OpenSSL 3.5 dgst documentation.

Useful openssl dgst commands

SHA-256 checksum:

openssl dgst \
  -sha256 \
  file.bin

SHA-512:

openssl dgst \
  -sha512 \
  file.bin

Coreutils-style output:

openssl dgst \
  -sha256 \
  -r \
  file.bin

Raw binary digest:

openssl dgst \
  -sha256 \
  -binary \
  file.bin \
  > file.sha256.bin

Sign:

openssl dgst \
  -sha256 \
  -sign private.key \
  -out file.sig \
  file.bin

Verify:

openssl dgst \
  -sha256 \
  -verify public.key \
  -signature file.sig \
  file.bin

List digests:

openssl list -digest-algorithms

Frequently asked questions

What does openssl dgst do?

openssl dgst calculates message digests and can also create and verify raw digital signatures based on those digest operations.

What is the default openssl dgst algorithm?

SHA-256 is the default digest.

For clarity, explicitly specify:

openssl dgst -sha256 file

How do I get a SHA-256 checksum with OpenSSL?

Run:

openssl dgst \
  -sha256 \
  file.bin

Is openssl sha256 the same as openssl dgst -sha256?

Yes.

A supported digest can be used directly as an OpenSSL subcommand:

openssl sha256 file.bin

is equivalent to selecting SHA-256 through dgst.

How do I verify a downloaded file checksum?

Calculate:

openssl dgst \
  -sha256 \
  downloaded-file.tar.gz

and compare the hexadecimal result with the checksum supplied through a trusted source.

How do I digitally sign a file?

Run:

openssl dgst \
  -sha256 \
  -sign private.key \
  -out file.sig \
  file.bin

How do I verify the signature?

Run:

openssl dgst \
  -sha256 \
  -verify public.key \
  -signature file.sig \
  file.bin

A valid result returns:

Verified OK

Does a SHA-256 checksum prove who created the file?

No.

A checksum primarily provides file-integrity comparison.

Use a trusted digital signature when you need authenticity.

Is SHA-1 still supported?

It may remain available for compatibility depending on your OpenSSL build and providers, but OpenSSL recommends SHA-256 for new or algorithm-agile applications.

Should I use MD5?

Not for new security-sensitive checksum or signature workflows.

Use SHA-256 or another modern digest appropriate for your interoperability requirements.

Can openssl dgst sign with RSA?

Yes.

OpenSSL determines the signing algorithm from the supplied private key. RSA, DSA, and ECDSA signatures are among the conventional supported cases.

Can openssl dgst sign with Ed25519?

Yes, but do not specify a separate digest such as -sha256. Ed25519 is a one-shot signature algorithm.

Can I verify a signature using a certificate?

openssl dgst -verify expects public-key input.

Extract the public key:

openssl x509 \
  -in signer.crt \
  -pubkey \
  -noout \
  -out signer.pub

Then verify using signer.pub.

Does openssl dgst validate the signer’s certificate?

No.

The raw signature operation does not perform the certificate identity and chain validation used by formats such as X.509, CMS, and S/MIME.

Validate the certificate separately using:

openssl verify

Should I use dgst -hmac?

It still exists for compatibility, but OpenSSL recommends the dedicated:

openssl mac

command for new MAC workflows.

Does openssl dgst work with OpenSSL 4.0?

Yes.

The normal digest, sign, and verify operations remain available. OpenSSL 4.0 removes the deprecated ENGINE options and adds -hmac-env and -hmac-stdin.

Practical software-release verification workflow

Assume you receive:

application-release.tar.gz
application-release.sig
release-signing.pub

Calculate the checksum

openssl dgst \
  -sha256 \
  application-release.tar.gz

Verify the signature

openssl dgst \
  -sha256 \
  -verify release-signing.pub \
  -signature application-release.sig \
  application-release.tar.gz

Expected:

Verified OK

Only after both the artifact and trusted public-key workflow are understood should the package proceed to deployment.

The complete trust flow is:

Downloaded artifact
       ↓
Calculate SHA-256
       ↓
Compare trusted checksum
       ↓
Verify digital signature
       ↓
Trusted public key?
       ↓
Deploy

Security considerations

Do not confuse:

hash

with:

digital signature

A hash can tell you that two byte streams match.

A signature can additionally prove that the matching content was signed by the private key corresponding to a trusted public key.

Protect:

release-signing.key

carefully.

If an attacker obtains it, they can create valid signatures for malicious files.

Recommended controls include:

• restrictive permissions;
• encryption at rest;
• limited administrator access;
• offline or isolated signing systems;
• HSM-backed signing keys for higher-value workflows;
• documented public-key distribution;
• key rotation procedures.

Privacy considerations

openssl dgst output normally exposes little personal information, but release scripts and command examples can still reveal:

• private filesystem paths;
• usernames;
• internal artifact names;
• internal repository names;
• server names.

Use generic paths and filenames in public documentation.

Never publish:

private signing keys
private-key passphrases
real production secrets

This article uses generic names such as:

application-release.tar.gz
release-signing.key
release-signing.pub

rather than environment-specific details.

Related OpenSSL guides

• Browse the complete OpenSSL Commands Guide.
• Create structured signed messages with OpenSSL cms.
• Validate X.509 signer certificates with OpenSSL verify.
• Learn how to list OpenSSL commands and supported algorithms.
• Inspect cryptographic structures with OpenSSL asn1parse.
• Generate and inspect public/private keys with the broader OpenSSL Commands Guide.

External references

• OpenSSL 3.5 dgst documentation
• OpenSSL 3.0 dgst documentation
• OpenSSL 4.0 dgst documentation
• OpenSSL list documentation
• OpenSSL pkey documentation
• OpenSSL mac documentation
• OpenSSL passphrase options

Conclusion

The openssl dgst command handles two closely related but distinct jobs:

File hashing
     +
Digital signatures

For integrity checking:

openssl dgst \
  -sha256 \
  file.bin

For signing:

openssl dgst \
  -sha256 \
  -sign private.key \
  -out file.sig \
  file.bin

For verification:

openssl dgst \
  -sha256 \
  -verify public.key \
  -signature file.sig \
  file.bin

The practical system-administration workflow is:

Artifact
   ↓
Calculate SHA-256
   ↓
Compare checksum
   ↓
Verify signature
   ↓
Confirm trusted public key
   ↓
Deploy

Use SHA-256 as a sensible modern default unless a protocol or application requires something else. OpenSSL itself recommends SHA-256 for new or algorithm-agile applications.

And remember the difference between the two security properties:

Checksum
    ↓
"Did the file change?"
Digital signature
    ↓
"Did the file change, and was it signed
by the holder of this private key?"

That distinction is what makes openssl dgst particularly valuable for software-release verification, deployment artifacts, backup validation, and lightweight digital-signature workflows.