Closed vlk-charles closed 3 months ago
Double check that "peer.crt" you expect is really what the server is using.
Your test using tls-verify.sh
is not conclusive in this case. The script gets called multiple times with each leaf of the chain only after successfully verifying the certificate. As server cert verification fails, tls-cerify.sh will not get called for it. The call you are seeing is probably with a higher depth certificate presented by the server. You can confirm that by also printing out the arguments passed to the script -- the first arg is depth and second arg the subject (DN) of the certificate. See whether depth = 0, and CN in the subject matches that of the server.
Alternatively, as a test, trust the logs for a moment, use the fingerprint that it reports as the one to expect. This will allow the handshake to complete and you can extract all certificates presented by the server using --tls-export-cert
and check.
You are totally right. I thought I had checked this multiple times. This is a simple deployment where peer.crt
is a self-signed certificate generated by the server. It didn't occur to me that it uses that (CA) certificate to sign another generated certificate and then both get sent as a chain during the handshake. What also threw me off was that both of these certificates have the same issuer DN, subject DN and validity period.
I apologize for the unwanted noise and thank you for the pointer. Not a bug and works as intended.
@vlk-charles Please, could you clarify which certificate fingerprint was sent ?
@TinCanTech No fingerprint was "sent" over the network. At first I was telling the client to verify against 9d:89:83:58:c6:58:06:87:45:fe:62:26:16:3e:d9:11:f9:14:48:6d:0c:8b:20:4b:87:99:75:8a:d4:aa:35:54
as written in the original report as I thought that was the only certificate being used. After @selvanair's helpful comment, I tried using the fingerprint mentioned in
2024-03-07 11:45:41 TLS Error: --tls-verify/--peer-fingerprintcertificate hash verification failed. (got fingerprint: 9a:26:3e:4e:a3:9c:73:af:1d:7e:1f:d1:6a:b8:8f:61:29:26:ed:a7:42:d0:37:f9:4d:0c:9c:20:fc:34:3e:da
The verification worked and I used --tls-export-cert
in combination with a --tls-verify
script to see that there are actually two different (albeit similar) certificates. One for each of the above mentioned fingerprints.
Describe the bug Cannot obtain a working hash from a certificate for OpenVPN's
peer-fingerprint
option. The output fromopenssl x509 -fingerprint
is not accepted. Instead the client reports a different value as the peer's certificate fingerprint. It is not known how it derived this value. The manual page simply says:To Reproduce
Note the line:
Where did this value come from? Also the formatting is a little wrong. A space and a closing parenthesis are missing.
Expected behavior Either
peer-fingerprint
should use the "standard" (i.e. the hash of the DER content) or the calculation method should be documented.Version information:
Additional context I did make sure
peer.crt
is actually the certificate presented by the server. It can also be seen in thetls_digest_sha256_1
variable if I use atls-verify
script:tls-verify.sh
is trivial: