Re: Problem with x509_verify_certificate

[Ken <OpenSSL@xxxxxx>]

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@xxxxxxxxxxxx>
Sent: Tue, 20 Nov 2018 08:56:58 -0500
To: Openssl-users <openssl-users@xxxxxxxxxxx>

Subject: Re: Problem with x509_verify_certificate

On Nov 20, 2018, at 1:31 AM, Ken <OpenSSL@xxxxxx> 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.

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

Attachment: openssl-Starfield_Root_Certificate_Authority_-_G2.pem
Description: application/pem-file

Attachment: pem-Starfield_Root_Certificate_Authority_-_G2.pem
Description: application/pem-file

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users