Same ca.crt filename, different certificate: what to compare

Two profiles both ship a file called ca.crt, one tunnel comes up and the other fails with a chain error. Opening the two files side by side rarely settles it, and turning verification off settles it in the wrong direction. The question the error is actually asking is narrower: which certificate does each process load as its trust anchor, and are the two the same object? Answer that first and the rest of the diagnosis has a direction. The file name is a packaging label, and the path written in the profile is not authoritative either, so everything depends on what the process actually reads.

Find the certificate the client actually loads

OpenVPN accepts the authority in two forms, and the form decides which bytes matter. A profile can point at an external file with ca, or embed the certificate inside a <ca> block in the profile itself. When both exist, the embedded block wins and the file sitting beside the profile is never opened.

Read the failing profile and find which form it uses before comparing anything. A copy pulled from a neighbouring directory, or from the package the other profile came from, tells you nothing about what this process trusts. The same holds for the path in the configuration: it resolves relative to wherever the client was started, which is not always the directory you are looking at. Read the profile, not the folder.

Certificates are identified by their contents: the public key, the subject and issuer, the validity window, and the signature over all of it. Two files with identical bytes are the same certificate whatever they are called, and two files with the same name can be unrelated authorities. The name is a packaging label, not an identity.

Fingerprint both copies with openssl

A fingerprint is a hash over the certificate's DER encoding, the form the signature covers, so line endings and header text cannot affect it. Compute it for each file and you have two colon-separated hex strings that either match or do not. Nothing else in the certificate has to be read to answer the comparison question.

openssl x509 -in /etc/openvpn/office/ca.crt -noout -fingerprint -sha256
openssl x509 -in ~/profiles/lab-ca.pem -noout -fingerprint -sha256

Pointing openssl at the profile itself is tempting, but it reads whichever certificate block appears first in the file, and a profile usually carries <cert> before <ca>. Extract the authority block, then fingerprint the extracted file, because that is the copy the client will actually use.

sed -n '/^<ca>$/,/^<\/ca>$/p' office.ovpn | sed '1d;$d' > /tmp/office-ca.pem
openssl x509 -in /tmp/office-ca.pem -noout -fingerprint -sha256

Identical fingerprints mean the trust material is the same and the chain error has some other cause, which is a different investigation. Different fingerprints mean different certificates, and that is where the next section starts.

Read a mismatch before assuming an attack

Different fingerprints mean different certificates and nothing more. A reissue, a rotation, a rebranded authority, or a stale bundle all produce different files with entirely legitimate histories. Which one belongs in the deployment is a question for the operator or the deployment record, not for the file's modification time. Archives copy timestamps, so a newer file is not automatically the correct anchor.

A root that signs itself is normal, so finding one is not evidence of a problem. The verifier's job is to build a path from the server certificate to the anchor it was handed, and a chain error usually means that path could not be completed.

Check whether the failing profile's anchor is an authority the deployment still issues from. If the fingerprint matches nothing in the deployment record, the profile is simply out of date, and no amount of client-side tuning will fix that.

Repair trust without switching verification off

The short-term fix is to disable verification or to add every certificate in the chain as an anchor. Both make the message disappear, and both change which servers the client will accept from then on. Turn verification back on, install the intended anchor, and re-test.

If the chain now builds but a different error appears, that is progress: name verification, validity dates, and revocation are separate checks with separate messages. Keep the fingerprint pair and the original error text together in the ticket, so the next person sees which anchor was loaded and which one was expected. A pair of fingerprints is small enough to paste into a handover note, and the next occurrence then takes five minutes instead of an afternoon.

Obtain the correct authority through the same authenticated channel that delivered the profile. Pulling a certificate off the server because its subject looks familiar is a different act, and it quietly widens what the client will trust.