[openssl-users] Problem with x509_verify_certificate
Ken
OpenSSL at k-h.us
Wed Nov 21 19:36:46 UTC 2018
Hi Viktor,
I tested using s_client, on both systems, with no options, with CAfile
pointing to the correct CA, and with CAfile pointing to the WRONG CA
file - the only time it failed was on the new version, with the wrong
file. (Results attached.) I guess the new version is better at checking
things.
You are right, x509_verify_certificate() is a function in the program,
that then makes calls to openssl. (But I did not dig back into that
today....)
I tested the application, setting SSL_CERT_DIR and SSL_CERT_FILE, to the
empty directory and the CA file - did not help.
Then, I tested setting SSL_CERT_DIR to /var/lib/ca-certificates/openssl
(which seems to be the default, and did not change anything), and then
setting SSL_CERT_DIR to /var/lib/ca-certificates/pem/ - this made
FreeRDP happy with the certificate.
This implies that there is something wrong with the CA in the openssl
directory, but the one in the pem directory is okay? I compared
Starfield_Root_Certificate_Authority_-_G2.pem in the openssl directory
on the two systems - they are a binary match.
Then I compared the output of
openssl x509 -in
/var/lib/ca-certificates/openssl/Starfield_Root_Certificate_Authority_-_G2.pem
-noout -text
and
openssl x509 -in
/var/lib/ca-certificates/pem/Starfield_Root_Certificate_Authority_-_G2.pem
-noout -text
The only difference is that the one from openssl ends with:
"
Trusted Uses:
TLS Web Server Authentication
No Rejected Uses.
Alias: Starfield Root Certificate Authority - G2
"
whereas the one from pem has nothing there. (I am also attaching the two
certificates.)
Since I am trying to make a RDP connection, does this mean that the
openssl version of the CA is not valid, because it says "Web Server
Authentication". And, the new version makes more extensive checks that
the old version?
I now have a work-around to make this application work, but I would like
to know what really is going on - what changed to cause this.
------ Original Message ------
From: Viktor Dukhovni <openssl-users at dukhovni.org>
Sent: Tue, 20 Nov 2018 08:56:58 -0500
To: Openssl-users <openssl-users at openssl.org>
Subject: Re: [openssl-users] Problem with x509_verify_certificate
>> On Nov 20, 2018, at 1:31 AM, Ken <OpenSSL at k-h.us> wrote:
>>
>> Are you saying to test with "openssl s_client -connect ..."?
> Test both with s_client and with your application if possible.
> In both cases configure the CApath empty and the CAfile to hold
> just the appropriate trust anchor. If your application does not
> provide a way to specify the CAfile and CApath, OpenSSL defaults
> can be overridden via environment variables:
>
> SSL_CERT_DIR
> SSL_CERT_FILE
>
>> 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).
> Try "s_client -quiet". For example, a failure:
>
> $ openssl s_client -quiet -starttls smtp -connect localhost:25
> depth=0 CN = [...]
> verify error:num=20:unable to get local issuer certificate
> verify return:1
> depth=0 CN = [...]
> verify error:num=21:unable to verify the first certificate
> verify return:1
>
> and a success:
>
> $ openssl s_client -quiet -starttls smtp -connect localhost:25 -CAfile rsacert.pem -partial_chain
> depth=0 CN = [...]
> verify return:1
>
>> 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.
> You really do need to be much more precise. Is it failing? Succeeding?
> What version of OpenSSL is this particular s_client associated with?
> At this point likely post the peer certificate chain (as reported by:
>
> sleep 2 | openssl s_client -showcerts -connect someaddr:someport 2>/dev/null
> | openssl crl2pkcs7 -nocert -certfile /dev/stdin
> | openssl pkcs7 -print_certs
>
>> Then, I tried again, pointing to an incorrect CA - then I see some errors:
>> "verify error:num=20:unable to get local issuer certificate"
> Which suggests that it worked the first time.
>
>> 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....
> Well, which trust store is the application using? And what is this
> x509_verify_certificate() you speak of? I only know about
> X509_verify_cert(3). Which requires an appopriately initialized
> X509_STORE_CTX, with suitable trust store settings.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181121/d527832b/attachment-0001.html>
-------------- next part --------------
openSUSE Leap 42.3 / OpenSSL 1.0.2j-fips 26 Sep 2016
# s_client with "no" options:
$ openssl s_client -quiet -connect owa.xxxxx.com:3389
depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2
verify return:1
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2
verify return:1
depth=0 OU = Domain Control Validated, CN = owa.xxxxx.com
verify return:1
# s_client, specifying correct CA:
$ openssl s_client -quiet -connect owa.xxxxx.com:3389 -CApath ~/empty/ -CAfile sfroot-g2.crt
depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2
verify return:1
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2
verify return:1
depth=0 OU = Domain Control Validated, CN = owa.xxxxx.com
verify return:1
# s_client, specifying *WRONG* CA:
$ openssl s_client -quiet -connect owa.xxxxx.com:3389 -CApath ~/empty/ -CAfile gdroot-g2.crt
depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2
verify return:1
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2
verify return:1
depth=0 OU = Domain Control Validated, CN = owa.xxxxx.com
verify return:1
openSUSE Leap 15.0 / OpenSSL 1.1.0i-fips 14 Aug 2018
# s_client with "no" options:
$ openssl s_client -quiet -connect owa.xxxxx.com:3389
depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2
verify return:1
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2
verify return:1
depth=0 OU = Domain Control Validated, CN = owa.xxxxx.com
verify return:1
# s_client, specifying correct CA:
$ openssl s_client -quiet -connect owa.xxxxx.com:3389 -CApath ~/empty/ -CAfile sfroot-g2.crt
depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2
verify return:1
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2
verify return:1
depth=0 OU = Domain Control Validated, CN = owa.xxxxx.com
verify return:1
# s_client, specifying *WRONG* CA:
$ openssl s_client -quiet -connect owa.xxxxx.com:3389 -CApath ~/empty/ -CAfile gdroot-g2.crt
openssl s_client -quiet -connect owa.xxxxx.com:3389 -CApath ~/empty/ -CAfile gdroot-g2.crt
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2
verify error:num=20:unable to get local issuer certificate
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssl-Starfield_Root_Certificate_Authority_-_G2.pem
Type: application/x-pem-file
Size: 1492 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181121/d527832b/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pem-Starfield_Root_Certificate_Authority_-_G2.pem
Type: application/x-pem-file
Size: 1399 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181121/d527832b/attachment-0003.bin>
More information about the openssl-users
mailing list