|
Are you saying to test with
"openssl s_client -connect ..."?
I don't think I know how to interpret all of the output from that, but it looked to me like it was saying everything was okay when I tried it earlier (with no changes). I just tried it again with -CApath pointing to an empty directory, and -CAfile pointing to a new copy of the root CA certificate, which I just downloaded from the provider - I do not see any difference in the output. Then, I tried again, pointing to an incorrect CA - then I see some errors: "verify error:num=20:unable to get local issuer certificate" So, it seems to me like, without any changes, s_client -connect says the certificate is fine, but the application using x509_verify_certificate thinks something is wrong.... ------ Original Message ------
From: Viktor Dukhovni <openssl-users@xxxxxxxxxxxx> Sent: Mon, 19 Nov 2018 01:23:37 -0500 To: Openssl-users <openssl-users@xxxxxxxxxxx> Subject: Re: Problem with x509_verify_certificate On Nov 19, 2018, at 1:15 AM, Ken <OpenSSL@xxxxxx> wrote: There are no stale intermediate certificates on my computer.The evidence suggests otherwise.Also, strace shows that it is looking for the correct CA certificate (/var/lib/ca-certificates/openssl/4bfab552.0), and being told that it exists - but with the newer version of openssl, it never tries to open the CA certificate (the older version does).The newer code uses a "trusted first" policy, which means that the intermediate certificate comes from the trust store, not the peer. When it fails to validate (as reported, the failure is verifying the issuer, not leaf certificate) one can reasonably conclude that there's something wrong with an intermediate issuer certificate in the trust store. You can check by creating a new file that contains just the expected root CA and nothing else, and setting CAfile to that, and CApath to an empty directory. Please report the results. |
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
