<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body smarttemplateinserted="true">
<div id="smartTemplate4-template">Hi Viktor,<br>
<br>
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.<br>
<br>
<br>
<br>
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....)<br>
<br>
<br>
<br>
I tested the application, setting SSL_CERT_DIR and SSL_CERT_FILE,
to the empty directory and the CA file - did not help.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
Then I compared the output of<br>
openssl x509 -in
/var/lib/ca-certificates/openssl/Starfield_Root_Certificate_Authority_-_G2.pem
-noout -text<br>
and<br>
openssl x509 -in
/var/lib/ca-certificates/pem/Starfield_Root_Certificate_Authority_-_G2.pem
-noout -text<br>
<br>
The only difference is that the one from openssl ends with:<br>
<br>
"<br>
Trusted Uses:<br>
TLS Web Server Authentication<br>
No Rejected Uses.<br>
Alias: Starfield Root Certificate Authority - G2<br>
"<br>
<br>
whereas the one from pem has nothing there. (I am also attaching
the two certificates.)<br>
<br>
<br>
<br>
<br>
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?<br>
<br>
<br>
<br>
<br>
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.<br>
<br>
</div>
<br>
<br>
<br>
<div id="smartTemplate4-quoteHeader">------ Original Message ------<br>
From: Viktor Dukhovni <a class="moz-txt-link-rfc2396E" href="mailto:openssl-users@dukhovni.org"><openssl-users@dukhovni.org></a><br>
Sent: Tue, 20 Nov 2018 08:56:58 -0500<br>
To: Openssl-users <a class="moz-txt-link-rfc2396E" href="mailto:openssl-users@openssl.org"><openssl-users@openssl.org></a><br>
<br>
Subject: Re: [openssl-users] Problem with x509_verify_certificate<br>
</div>
<blockquote type="cite"
cite="mid:97E1765C-68B9-4FCF-BDA3-5B9C1CC81380@dukhovni.org">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Nov 20, 2018, at 1:31 AM, Ken <a class="moz-txt-link-rfc2396E" href="mailto:OpenSSL@k-h.us"><OpenSSL@k-h.us></a> wrote:
Are you saying to test with "openssl s_client -connect ..."?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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).
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Then, I tried again, pointing to an incorrect CA - then I see some errors:
"verify error:num=20:unable to get local issuer certificate"
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Which suggests that it worked the first time.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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....
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<br>
</body>
</html>