<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body smarttemplateinserted="true" text="#000000" bgcolor="#FFFFFF">
<div id="smartTemplate4-template">Hi Viktor,<br>
<br>
It looks like FreeRDP was not setting a purpose when checking the
certificate, causing this issue. I added:<br>
<br>
<font face="Courier New, Courier, monospace">X509_STORE_CTX_set_default(csc,
"ssl_server");</font><br>
<br>
before the call to<br>
<br>
<font face="Courier New, Courier, monospace">if
(X509_verify_cert(csc) == 1)</font><br>
<br>
and this seems to make it work. I don't know if this is a "good"
way to fix this, but I sent this information off to the
maintainers of FreeRDP - hopefully, they can "do it right".<br>
<br>
<br>
<br>
<br>
<br>
As far as our previous message, I was having some "communications
issues" the day I wrote that:<br>
</div>
<br>
<br>
<blockquote type="cite"
cite="mid:20181121230406.GR4122@straasha.imrryr.org">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Perhaps you did not override CApath? And the default CApath succeeds
with old, but not the new code? For meaningful tests you need to
explicitly override both, and place just specific CA certs in CAfile,
leaving CApath empty.
</pre>
</blockquote>
That is what I did, just not what I wrote!<br>
<br>
<blockquote type="cite"
cite="mid:20181121230406.GR4122@straasha.imrryr.org">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">I tested the application, setting SSL_CERT_DIR and SSL_CERT_FILE, to the
empty directory and the CA file - did not help.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I don't believe I suggested setting SSL_CERT_FILE to an empty
directory, or an empty file. Though putting a freshly minted
self-signed root that has never signed any certificates into CAfile,
can be one test to check that your application fails when it should
definitely fail.
</pre>
</blockquote>
I meant that I set SSL_CERT_DIR to an empty directory, and
SSL_CERT_FILE to the CA file.<br>
<br>
<blockquote type="cite"
cite="mid:20181121230406.GR4122@straasha.imrryr.org">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
I compared
Starfield_Root_Certificate_Authority_-_G2.pem in the openssl directory
on the two systems - they are a binary match.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">But they're not the same, only the encapsulated X.509 certificates
are the same, but one is wrapped as a "trusted certificate" with a
specific trust EKU.
</pre>
</blockquote>
I meant that
"/var/lib/ca-certificates/openssl/Starfield_Root_Certificate_Authority_-_G2.pem"
is the same on OpenSUSE 42.3 and OpenSUSE 1.5.0<br>
<br>
<blockquote type="cite"
cite="mid:20181121230406.GR4122@straasha.imrryr.org">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">That is, they are NOT the same.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Well, that's "auxiliary" trust data outside the certificate. It
is part of a "TRUSTED CERTICATE" encapsulation of a CA certificate,
and can be used to limit the "purpose" for which a certificate is
valid.
If your application does not specify "serverAuth" as the "purpose"
being verified, then verification should fail.
</pre>
</blockquote>
This was the hint that helped me.<br>
<br>
<br>
Thanks!<br>
<br>
</body>
</html>