[openssl-users] Problem with x509_verify_certificate

[Ken]

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


------ Original Message ------
From: Ken <OpenSSL at k-h.us>
Sent: Thu, 22 Nov 2018 10:43:52 -0800
To: Openssl-users <openssl-users at openssl.org>

Subject: Re: [openssl-users] Problem with x509_verify_certificate
> 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/20181126/20f5a214/attachment.html>