|
Hi Viktor,
Is it "better" to use
X509_STORE_CTX_set_default(csc,
"ssl_server");
or something more like
purpose =
X509_PURPOSE_SSL_SERVER;
verify_param = X509_STORE_CTX_get0_param(csc);
X509_VERIFY_PARAM_set_purpose(verify_param, purpose);
X509_verify_cert(csc)
When we tried the second option, it did not make any difference.
When I added
X509_STORE_CTX_set0_param(csc,verify_param);
X509_verify_cert(csc)
started returning error X509_V_ERR_CERT_CHAIN_TOO_LONG: certificate chain too
long
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!
|
