Re: Problem with x509_verify_certificate

[Ken <OpenSSL@xxxxxx>]

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!

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