OpenVPN Without a CA: How peer-fingerprint Verifies Peers

A small deployment reaches for fingerprints because a certificate authority looks like infrastructure nobody has time to run. The instinct is reasonable, and the shortcut people take instead, copying one data-channel secret to both ends, is not. A peer-fingerprint setup keeps the TLS structure intact: each side still holds its own private key and certificate, and each side still verifies the other. What changes is where the verification is anchored, from a trusted issuer to a short list of pinned digests. Because a digest covers the whole certificate rather than a name, renewal turns into the operation that costs real time.

What the fingerprint actually commits to

A certificate fingerprint is a digest of the entire DER-encoded certificate, not of its public key and not of its subject name. Two certificates with identical names and the same key but different validity dates therefore have different fingerprints. That is what makes pinning precise, and it is also what makes renewal disruptive. A pin cannot mean trusting a key in general, because it names one artifact at one moment in its life. Anyone may know the digest, and knowing it proves nothing by itself.

openssl x509 -in server.crt -noout -fingerprint -sha256
openssl x509 -in client-07.crt -noout -fingerprint -sha256

Possession of the matching private key is what proves the peer holds that certificate, and the digest is how the other side decides whether it expected that certificate at all. That separation is why this design is not the legacy shared-secret arrangement: a shared key authenticates anyone who knows the same bytes, while a pin authenticates one certificate. A different device gets its own entry rather than a copy of the same secret, which is a small difference in files and a large one in blast radius.

The map is reciprocal, not symmetric

Each endpoint needs two things: its own private key with its certificate, and a statement about which peer certificates it will accept. On the client that statement is the server certificate's digest; on the server it is the list of enrolled client digests. An official small-setup example for Community 2.6 shows the arrangement with peer-fingerprint, and it is worth reading before choosing this trust model for a real deployment. The two directions are not one list reversed, and they do not fail at the same moment.

Adding a device edits an allowlist on the server, without copying an existing client's private material and without moving the server key anywhere. The two directions also fail independently, which is useful during diagnosis: whichever side closes the handshake is the side whose expectation was not met. If the client rejects the server, the digest does not match the certificate being presented. If the server rejects the client, that client's digest is missing from the list, or the client is presenting a certificate other than the one that was enrolled.

Enrolment: how a new device joins

Generate the new device's key and certificate where the private key will live, then move only the public artifact to the party that needs to pin it. Transfer the expected digest through a channel you already trust, and compare the complete certificate rather than a name that looks familiar. A digest copied from the same unverified download as the certificate proves only that the two files agree with each other. That is a consistency check rather than an identity check, and it is the quietest way this design gets weakened.

On the server, adding the digest is a configuration change that goes through the normal manager and is followed by a reconnect. Confirm that the new device connects and that a device whose digest was removed no longer does. A test that covers only the positive case leaves the allowlist unverified, which is exactly the state you will be in six months from now.

Renewal is the expensive moment

Every certificate expires, and a new certificate has a new digest even when the key and the names stay the same. Under an issuer, renewal is transparent to peers that trust that issuer; under pinning, it is an enrolment event for every peer that pins the certificate.

Plan the order before the expiry date rather than after it. Distribute the new digest to the parties that verify it, apply the change, and only then swap the certificate on the endpoint. That order leaves no window in which the two sides disagree about which certificate is current. Keep the list itself under review as well, because a pinned list accumulates entries for devices retired months ago. Every stale entry is an identity that still authenticates if its key survives, so removing one is a security action rather than housekeeping.

What the trust map does not decide

Authentication is one layer, and the pinned map says nothing about the address pool, the pushed routes, the path MTU or the firewall policy. Those remain separate configuration with separate failure modes. A tunnel that authenticates and passes no traffic is a different investigation from one that never comes up.

The map also does not scale indefinitely, and an issuer-based PKI is where larger deployments end up. That preference is about operations rather than cryptography, since adding and retiring identities through one authority is cheaper than editing a list on every peer as the fleet grows. Where a client implementation does not support the option, the answer is a compatible trust model that client documents, or a supported replacement. Suppressing the verification warning does not add that support, and the entire value of the design is that verification still happens.