[openssl-users] Problem with x509_verify_certificate

Ken OpenSSL at k-h.us
Thu Nov 22 18:43:52 UTC 2018


Hi Viktor,

It looks like FreeRDP was not setting a purpose when checking the 
certificate, causing this issue. I added:

X509_STORE_CTX_set_default(csc, "ssl_server");

before the call to

if (X509_verify_cert(csc) == 1)

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".





As far as our previous message, I was having some "communications 
issues" the day I wrote that:


>> 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.
> 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.
That is what I did, just not what I wrote!

>> I tested the application, setting SSL_CERT_DIR and SSL_CERT_FILE, to the
>> empty directory and the CA file - did not help.
> 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.
I meant that I set SSL_CERT_DIR to an empty directory, and SSL_CERT_FILE 
to the CA file.

>> 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.
> 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.
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

>> 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
> That is, they are NOT the same.
>
>> 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
> 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.
This was the hint that helped me.


Thanks!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181122/e9e7a80a/attachment.html>


More information about the openssl-users mailing list