OpenSSL SHA1 Digest Names: What a Legacy Listing Means

Legacy digest listings read like a transcript of cryptographic decisions, and they are not one. Names such as SHA1, DSA-SHA1-old or RSA-SHA1-2 sit beside each other in old OpenSSL builds because the library registered several entry points around related hash machinery. An RSA or DSA label in that list says nothing about what OpenVPN did to a packet. What you are reading is the library's inventory, not the record of a session.

Three things have to be separated before any conclusion makes sense: the registered name, the digest computation underneath it, and the operation that consumes it.

A registration is an interface, not a strength rating

In OpenSSL 1.0.2 the digest registration table wires names, aliases and implementations together in one file. The legacy DSS1 descriptor is the clearest case: it reports SHA-1's output length and calls SHA-1's finalisation routine while carrying a name that suggests a different algorithm entirely. Extra letters in a registration therefore imply no different hash, no longer output and no new security level.

The same source preserves alias relationships for older callers, which explains why a listing looks crowded. That is documentation of compatibility, not a promise that a current OpenSSL provider exposes identical names.

Signing names do not create signatures

A signing framework can bind a digest to another algorithm's interface so existing callers keep compiling. A real public-key signature needs both a key and the signing step that uses it, and neither is supplied by a name in a menu. An RSA-flavoured digest entry is a name a caller may use, not evidence that each VPN packet carried an RSA signature.

This is the step where older write-ups drift into folklore. If you need to know how packets were authenticated, locate the option that selected the mechanism and read what it does in the version you actually run. The manual page shipped with that release is the only description that matches the binary in front of you. Archived guides describe the release they were written against, which may be several naming conventions behind.

Find the option that consumed the name

For the packet-authentication case documented by OpenVPN 2.6, auth selects a digest used by HMAC, a keyed message-authentication construction rather than a certificate signature. The signing algorithm of the TLS certificate is a separate property of the handshake.

With an AEAD data cipher the separate auth setting stops applying to the data channel, while its role for tls-auth remains a distinct question. A digest list therefore cannot tell you which hash protected the current packets, what TLS suite was negotiated, or how the peer certificate was signed. Only the effective configuration plus the version can answer that, and only for the connection in front of you.

Record what you actually have

Write down the OpenVPN version, the linked crypto library, the exact options in the profile and the result of a real connection. That set answers questions a screenshot of a digest menu cannot, and it survives the next upgrade because it names versions rather than impressions.

Above all, do not pick a legacy alias because its name sounds stronger or more specific. Choose the supported policy for the whole connection, and treat the old names as a record of how a library used to present itself.