Key Fingerprints

A fingerprint is a compact digest that identifies a key or certificate. When you configure a partner's host key, PGP key, or certificate in Files.com, comparing fingerprints helps confirm that you received the public material the partner intended. It is a practical alternative to reading out an entire encoded key, provided the expected fingerprint comes from a source you already trust.

Names, email addresses, and filenames help you find a key, but someone can put those same labels on a different key. Comparing fingerprints checks the underlying object using the agreed fingerprint scheme.

Comparable Values

When a partner quotes a fingerprint, ask what it identifies and how it was calculated. An SSH public-key fingerprint, an OpenPGP fingerprint, an X.509 certificate fingerprint, and the checksum of an exported file are different values. Even two fingerprints of the same key can look different when the digest algorithm or display format differs.

SSH tools can display the same key using SHA-256 or older MD5 fingerprints. A SHA-256 fingerprint commonly begins with SHA256: followed by Base64 text, while MD5 commonly appears as colon-separated hexadecimal pairs. These look different because they use different digest algorithms and encodings, even when the key is unchanged.

For a comparison, calculate the required representation from the original public key and compare the entire value, including its algorithm. Changing punctuation or encoding cannot turn a SHA-256 digest into an MD5 digest. At Files.com, we recommend SHA-256 for a new SSH fingerprint exchange when both systems support it.

SSH Fingerprints

OpenSSH can calculate either representation from a public-key file:

ssh-keygen -lf partner-host.pub -E sha256
ssh-keygen -lf partner-host.pub -E md5

The output includes the key's size, fingerprint, comment, and type. Compare the fingerprint and key type against the operator's expected identity. A server can have separate RSA and Ed25519 host keys, each with its own fingerprint. A user login key is also separate from the server host key, even if both use the same algorithm.

When connecting to Files.com, obtain the expected SFTP host key for the hostname's configured provider. A custom domain can present a custom host identity, so the default Files.com fingerprint is not always the right value for that endpoint.

OpenPGP Fingerprints

GnuPG can inspect a received public-key file without importing it:

gpg --show-keys --with-fingerprint partner-public.asc

For a key already in your keyring, use its identifier:

gpg --fingerprint FULL_KEY_FINGERPRINT

Confirm the full primary-key fingerprint with the partner, together with the intended identity, expiration, and use. OpenPGP keys can have signing and encryption subkeys; the primary key identifies the overall key, while a particular operation can refer to a subkey. GnuPG's --with-subkey-fingerprint option displays those additional fingerprints when needed. Use the full fingerprint for confirmation; a short key ID or matching email address alone is insufficient.

The GPG Key Manager displays MD5 hashes of the stored key text. Those hashes help identify stored entries; they are not OpenPGP fingerprints. Changes to the exported text's armor or line endings can change that MD5 value while leaving the underlying OpenPGP key unchanged. Use the original public key and GnuPG when comparing the fingerprint a partner quotes.

Certificate Fingerprints

OpenSSL prints a SHA-256 fingerprint of a public certificate:

openssl x509 -in partner-certificate.pem -noout -fingerprint -sha256

This identifies the whole certificate. Renewing a certificate changes its dates and signature, so it changes the certificate fingerprint even when the same public key is reused. A partner that pins the certificate needs to update that pin; a partner that pins only the public key can keep the same value when that key is reused. Confirm which value its configuration expects.

For ordinary CA-based TLS trust, a client validates the certificate's chain and hostname rather than comparing a manually maintained fingerprint. Certificates & Trust explains how renewal works under these different trust models.

Independent Confirmation

The expected fingerprint needs a source independent of the connection you are checking. You might confirm it by phone with the partner's known administrator or obtain it through their authenticated partner portal. Copying the fingerprint from a first-connection prompt and comparing it with that same prompt tells you nothing about who operates the endpoint.

Record the approved hostname, environment, key type, full fingerprint, and the contact or source that confirmed it. During a planned change, verify the replacement through that established relationship. Keep private keys out of the comparison; public material is sufficient.

First Connections and Changed Host Keys

On a first SSH connection, a client that has no trusted key for the endpoint may ask whether to accept the presented host key. Confirm its fingerprint before acceptance. For unattended jobs, configure the verified host key or fingerprint before the first run so the job does not depend on someone answering a prompt.

OpenSSH stores recognized host keys in known_hosts, commonly under the account's .ssh directory; an administrator can also supply system-wide trusted keys. Other clients maintain their own cache or explicit connection-profile setting. The account running a scheduled job can have a different trust store from the person testing it on a laptop.

A changed-host-key warning means the server is presenting a different identity from the one the client trusts for that endpoint. There can be a legitimate explanation, such as a planned key replacement, a different hostname or port, a DNS destination you did not expect, or a service configuration change. The server operator needs to confirm the expected key through the established channel before you trust the new identity.

Once verified, update that endpoint's trust entry using the client's supported process and test as the account that runs the job. Deleting the entire trust store or disabling host-key checking would remove the check while leaving the reason for the changed identity unresolved.