Problem with x509_verify_certificate

classic Classic list List threaded Threaded
16 messages Options
Ken
Reply | Threaded
Open this post in threaded view
|

Problem with x509_verify_certificate

Ken
I use an application, FreeRDP (https://github.com/FreeRDP/FreeRDP), which uses x509_verify_certificate to check the validity of a certificate on a RDP server.

Under openSUSE Leap 42.3 (which uses openssl version "1.0.2j-fips  26 Sep 2016") everything works great.

But, when I upgrade to openSUSE Leap 15.0 (which uses openssl version "1.1.0i-fips  14 Aug 2018") I get an error when connecting to servers that use publicly-signed certificates:

Certificate details:
        Subject: OU = Domain Control Validated, CN = owa.xxxxx.com
        Issuer: C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2
        Thumbprint: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
The above X.509 certificate could not be verified, possibly because you do not have
the CA certificate in your certificate store, or the certificate has expired.
Please look at the OpenSSL documentation on how to add a private CA to the store.
Do you trust the above certificate? (Y/T/N)


On both versions, strace shows is it checking for /var/lib/ca-certificates/openssl/4bfab552.0 (which exists, and is the correct CA) - but with openssl version "1.1.0i-fips  14 Aug 2018", it never opens that file. (With openssl version "1.0.2j-fips  26 Sep 2016", it does open/read that file, which it seems like it work need to, in order to find out if it matches the certificate.)


Any idea what changed? (Or, better question, what needs to be changed to make this application work again?)


Thanks,
Ken

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with x509_verify_certificate

Felipe Gasper-2
Maybe the set of stores root certificates changed with the update?

Try openssl s_client to debug it?

On Nov 17, 2018, at 8:57 PM, Ken <[hidden email]> wrote:

I use an application, FreeRDP (https://github.com/FreeRDP/FreeRDP), which uses x509_verify_certificate to check the validity of a certificate on a RDP server.

Under openSUSE Leap 42.3 (which uses openssl version "1.0.2j-fips  26 Sep 2016") everything works great.

But, when I upgrade to openSUSE Leap 15.0 (which uses openssl version "1.1.0i-fips  14 Aug 2018") I get an error when connecting to servers that use publicly-signed certificates:

Certificate details:
        Subject: OU = Domain Control Validated, CN = owa.xxxxx.com
        Issuer: C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2
        Thumbprint: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
The above X.509 certificate could not be verified, possibly because you do not have
the CA certificate in your certificate store, or the certificate has expired.
Please look at the OpenSSL documentation on how to add a private CA to the store.
Do you trust the above certificate? (Y/T/N)


On both versions, strace shows is it checking for /var/lib/ca-certificates/openssl/4bfab552.0 (which exists, and is the correct CA) - but with openssl version "1.1.0i-fips  14 Aug 2018", it never opens that file. (With openssl version "1.0.2j-fips  26 Sep 2016", it does open/read that file, which it seems like it work need to, in order to find out if it matches the certificate.)


Any idea what changed? (Or, better question, what needs to be changed to make this application work again?)


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

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Ken
Reply | Threaded
Open this post in threaded view
|

Re: Problem with x509_verify_certificate

Ken
I think that the output from s_client (see attached) says that it passed, for both versions.

Also, the output from s_client shows it looking for the correct CA file on both versions (and shows that the file exists), but it only opens the CA file under openssl version "1.0.2j-fips  26 Sep 2016".



------ Original Message ------
From: Felipe Gasper [hidden email]
Sent: Sat, 17 Nov 2018 22:23:58 -0500
To: Openssl-users [hidden email]

Subject: Re: [openssl-users] Problem with x509_verify_certificate
Maybe the set of stores root certificates changed with the update?

Try openssl s_client to debug it?

On Nov 17, 2018, at 8:57 PM, Ken <[hidden email]> wrote:

I use an application, FreeRDP (https://github.com/FreeRDP/FreeRDP), which uses x509_verify_certificate to check the validity of a certificate on a RDP server.

Under openSUSE Leap 42.3 (which uses openssl version "1.0.2j-fips  26 Sep 2016") everything works great.

But, when I upgrade to openSUSE Leap 15.0 (which uses openssl version "1.1.0i-fips  14 Aug 2018") I get an error when connecting to servers that use publicly-signed certificates:

Certificate details:
        Subject: OU = Domain Control Validated, CN = owa.xxxxx.com
        Issuer: C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2
        Thumbprint: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
The above X.509 certificate could not be verified, possibly because you do not have
the CA certificate in your certificate store, or the certificate has expired.
Please look at the OpenSSL documentation on how to add a private CA to the store.
Do you trust the above certificate? (Y/T/N)


On both versions, strace shows is it checking for /var/lib/ca-certificates/openssl/4bfab552.0 (which exists, and is the correct CA) - but with openssl version "1.1.0i-fips  14 Aug 2018", it never opens that file. (With openssl version "1.0.2j-fips  26 Sep 2016", it does open/read that file, which it seems like it work need to, in order to find out if it matches the certificate.)


Any idea what changed? (Or, better question, what needs to be changed to make this application work again?)


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



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

1.0.2j-fips.txt (3K) Download Attachment
1.1.0i-fips.txt (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problem with x509_verify_certificate

Viktor Dukhovni
In reply to this post by Ken
I would suggest running "c_rehash" on the directory, making sure it is
the c_rehash for OpenSSL 1.1.x, and not some other version.

> On Nov 17, 2018, at 8:57 PM, Ken <[hidden email]> wrote:
>
> On both versions, strace shows is it checking for /var/lib/ca-certificates/openssl/4bfab552.0 (which exists, and is the correct CA) - but with openssl version "1.1.0i-fips  14 Aug 2018", it never opens that file. (With openssl version "1.0.2j-fips  26 Sep 2016", it does open/read that file, which it seems like it work need to, in order to find out if it matches the certificate.)
>
> Any idea what changed? (Or, better question, what needs to be changed to make this application work again?)

The way that DN hashes are computed changed from 0.9.8 to 1.0.0, but IIRC then
remained stable, so I would not expect a change between 1.0.2 and 1.1.0.

It is difficult to offer more help without copies of the certificates in question.

The main change between 1.1.0 and 1.0.2 is that "trusted_first" is now
the default behaviour and cannot be changed.  This means that intermediate
certificates supplied with the peer chain are used only when no issuer is
present in the trust store.  This can lead to a different chain being
computed in some cases.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with x509_verify_certificate

Viktor Dukhovni
In reply to this post by Ken
Most likely there's a stale (expired) copy of the intermediate certificate in
question in the trust store, but the peer (server) sent an unexpired version
in the handshake.  The solution is to remove the stale intermediate from
the trust store.

> On Nov 17, 2018, at 8:57 PM, Ken <[hidden email]> wrote:
>
> I use an application, FreeRDP (https://github.com/FreeRDP/FreeRDP), which uses x509_verify_certificate to check the validity of a certificate on a RDP server.
>
> Under openSUSE Leap 42.3 (which uses openssl version "1.0.2j-fips  26 Sep 2016") everything works great.
>
> But, when I upgrade to openSUSE Leap 15.0 (which uses openssl version "1.1.0i-fips  14 Aug 2018") I get an error when connecting to servers that use publicly-signed certificates:
>
> Certificate details:
>         Subject: OU = Domain Control Validated, CN = owa.xxxxx.com
>         Issuer: C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU =http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2
>         Thumbprint: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
> The above X.509 certificate could not be verified, possibly because you do not have
> the CA certificate in your certificate store, or the certificate has expired.
> Please look at the OpenSSL documentation on how to add a private CA to the store.
> Do you trust the above certificate? (Y/T/N)
>
>
> On both versions, strace shows is it checking for /var/lib/ca-certificates/openssl/4bfab552.0 (which exists, and is the correct CA) - but with openssl version "1.1.0i-fips  14 Aug 2018", it never opens that file. (With openssl version "1.0.2j-fips  26 Sep 2016", it does open/read that file, which it seems like it work need to, in order to find out if it matches the certificate.)
>
>
> Any idea what changed? (Or, better question, what needs to be changed to make this application work again?)

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Ken
Reply | Threaded
Open this post in threaded view
|

Re: Problem with x509_verify_certificate

Ken
In reply to this post by Viktor Dukhovni
"c_rehash" did not make any difference.



------ Original Message ------
From: Viktor Dukhovni [hidden email]
Sent: Sun, 18 Nov 2018 00:54:46 -0500
To: Openssl-users [hidden email]

Subject: Re: [openssl-users] Problem with x509_verify_certificate
I would suggest running "c_rehash" on the directory, making sure it is
the c_rehash for OpenSSL 1.1.x, and not some other version.

On Nov 17, 2018, at 8:57 PM, Ken [hidden email] wrote:

On both versions, strace shows is it checking for /var/lib/ca-certificates/openssl/4bfab552.0 (which exists, and is the correct CA) - but with openssl version "1.1.0i-fips  14 Aug 2018", it never opens that file. (With openssl version "1.0.2j-fips  26 Sep 2016", it does open/read that file, which it seems like it work need to, in order to find out if it matches the certificate.)

Any idea what changed? (Or, better question, what needs to be changed to make this application work again?)
The way that DN hashes are computed changed from 0.9.8 to 1.0.0, but IIRC then
remained stable, so I would not expect a change between 1.0.2 and 1.1.0.

It is difficult to offer more help without copies of the certificates in question.

The main change between 1.1.0 and 1.0.2 is that "trusted_first" is now
the default behaviour and cannot be changed.  This means that intermediate
certificates supplied with the peer chain are used only when no issuer is
present in the trust store.  This can lead to a different chain being
computed in some cases.



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with x509_verify_certificate

Viktor Dukhovni
In that case, remove stale, possibly expired intermediate CAs from
your CAfile/CApath as mentioned in an earlier message.  Then c_rehash
once more.

> On Nov 19, 2018, at 1:03 AM, Ken <[hidden email]> wrote:
>
> "c_rehash" did not make any difference.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Ken
Reply | Threaded
Open this post in threaded view
|

Re: Problem with x509_verify_certificate

Ken
In reply to this post by Viktor Dukhovni
 
There are no stale intermediate certificates on my computer.

(This was a fresh install, on a new drive. I should have never said "upgrade".)

Also, strace shows that it is looking for the correct CA certificate (/var/lib/ca-certificates/openssl/4bfab552.0), and being told that it exists - but with the newer version of openssl, it never tries to open the CA certificate (the older version does).



------ Original Message ------
From: Viktor Dukhovni [hidden email]
Sent: Sun, 18 Nov 2018 01:00:50 -0500
To: Openssl-users [hidden email]

Subject: Re: [openssl-users] Problem with x509_verify_certificate
Most likely there's a stale (expired) copy of the intermediate certificate in
question in the trust store, but the peer (server) sent an unexpired version
in the handshake.  The solution is to remove the stale intermediate from
the trust store.

On Nov 17, 2018, at 8:57 PM, Ken [hidden email] wrote:

I use an application, FreeRDP (https://github.com/FreeRDP/FreeRDP), which uses x509_verify_certificate to check the validity of a certificate on a RDP server.

Under openSUSE Leap 42.3 (which uses openssl version "1.0.2j-fips  26 Sep 2016") everything works great.

But, when I upgrade to openSUSE Leap 15.0 (which uses openssl version "1.1.0i-fips  14 Aug 2018") I get an error when connecting to servers that use publicly-signed certificates:

Certificate details:
        Subject: OU = Domain Control Validated, CN = owa.xxxxx.com
        Issuer: C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU =http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2
        Thumbprint: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
The above X.509 certificate could not be verified, possibly because you do not have
the CA certificate in your certificate store, or the certificate has expired.
Please look at the OpenSSL documentation on how to add a private CA to the store.
Do you trust the above certificate? (Y/T/N) 


On both versions, strace shows is it checking for /var/lib/ca-certificates/openssl/4bfab552.0 (which exists, and is the correct CA) - but with openssl version "1.1.0i-fips  14 Aug 2018", it never opens that file. (With openssl version "1.0.2j-fips  26 Sep 2016", it does open/read that file, which it seems like it work need to, in order to find out if it matches the certificate.)


Any idea what changed? (Or, better question, what needs to be changed to make this application work again?)

    


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with x509_verify_certificate

Viktor Dukhovni


> On Nov 19, 2018, at 1:15 AM, Ken <[hidden email]> wrote:
>
> There are no stale intermediate certificates on my computer.

The evidence suggests otherwise.

> Also, strace shows that it is looking for the correct CA certificate
> (/var/lib/ca-certificates/openssl/4bfab552.0), and being told that it
> exists - but with the newer version of openssl, it never tries to open
> the CA certificate (the older version does).

The newer code uses a "trusted first" policy, which means that the
intermediate certificate comes from the trust store, not the peer.
When it fails to validate (as reported, the failure is verifying
the issuer, not leaf certificate) one can reasonably conclude that
there's something wrong with an intermediate issuer certificate in
the trust store.

You can check by creating a new file that contains just
the expected root CA and nothing else, and setting CAfile to
that, and CApath to an empty directory.  Please report the results.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Ken
Reply | Threaded
Open this post in threaded view
|

Re: Problem with x509_verify_certificate

Ken
Are you saying to test with "openssl s_client -connect ..."?

I don't think I know how to interpret all of the output from that, but it looked to me like it was saying everything was okay when I tried it earlier (with no changes).

I just tried it again with -CApath pointing to an empty directory, and -CAfile pointing to a new copy of the root CA certificate, which I just downloaded from the provider - I do not see any difference in the output.

Then, I tried again, pointing to an incorrect CA - then I see some errors: "verify error:num=20:unable to get local issuer certificate"



So, it seems to me like, without any changes, s_client -connect says the certificate is fine, but the application using x509_verify_certificate thinks something is wrong....



------ Original Message ------
From: Viktor Dukhovni [hidden email]
Sent: Mon, 19 Nov 2018 01:23:37 -0500
To: Openssl-users [hidden email]

Subject: Re: [openssl-users] Problem with x509_verify_certificate

On Nov 19, 2018, at 1:15 AM, Ken [hidden email] wrote:

There are no stale intermediate certificates on my computer.
The evidence suggests otherwise.

Also, strace shows that it is looking for the correct CA certificate
(/var/lib/ca-certificates/openssl/4bfab552.0), and being told that it
exists - but with the newer version of openssl, it never tries to open
the CA certificate (the older version does).
The newer code uses a "trusted first" policy, which means that the
intermediate certificate comes from the trust store, not the peer.
When it fails to validate (as reported, the failure is verifying
the issuer, not leaf certificate) one can reasonably conclude that
there's something wrong with an intermediate issuer certificate in
the trust store.

You can check by creating a new file that contains just
the expected root CA and nothing else, and setting CAfile to
that, and CApath to an empty directory.  Please report the results.



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with x509_verify_certificate

Viktor Dukhovni
> On Nov 20, 2018, at 1:31 AM, Ken <[hidden email]> wrote:
>
> Are you saying to test with "openssl s_client -connect ..."?

Test both with s_client and with your application if possible.
In both cases configure the CApath empty and the CAfile to hold
just the appropriate trust anchor.  If your application does not
provide a way to specify the CAfile and CApath, OpenSSL defaults
can be overridden via environment variables:

        SSL_CERT_DIR
        SSL_CERT_FILE

> I don't think I know how to interpret all of the output from that,
> but it looked to me like it was saying everything was okay when I
> tried it earlier (with no changes).

Try "s_client -quiet".  For example, a failure:

  $ openssl s_client -quiet -starttls smtp -connect localhost:25
  depth=0 CN = [...]
  verify error:num=20:unable to get local issuer certificate
  verify return:1
  depth=0 CN = [...]
  verify error:num=21:unable to verify the first certificate
  verify return:1

and a success:

  $ openssl s_client -quiet -starttls smtp -connect localhost:25 -CAfile rsacert.pem -partial_chain
  depth=0 CN = [...]
  verify return:1

> I just tried it again with -CApath pointing to an empty directory, and -CAfile
> pointing to a new copy of the root CA certificate, which I just downloaded from
> the provider - I do not see any difference in the output.

You really do need to be much more precise. Is it failing?  Succeeding?
What version of OpenSSL is this particular s_client associated with?
At this point likely post the peer certificate chain (as reported by:

        sleep 2 | openssl s_client -showcerts -connect someaddr:someport 2>/dev/null
                | openssl crl2pkcs7 -nocert -certfile /dev/stdin
                | openssl pkcs7 -print_certs

> Then, I tried again, pointing to an incorrect CA - then I see some errors:
> "verify error:num=20:unable to get local issuer certificate"

Which suggests that it worked the first time.

> So, it seems to me like, without any changes, s_client -connect says
> the certificate is fine, but the application using x509_verify_certificate
> thinks something is wrong....

Well, which trust store is the application using?  And what is this
x509_verify_certificate() you speak of?  I only know about
X509_verify_cert(3).  Which requires an appopriately initialized
X509_STORE_CTX, with suitable trust store settings.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Ken
Reply | Threaded
Open this post in threaded view
|

Re: Problem with x509_verify_certificate

Ken
Hi Viktor,

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.



You are right, x509_verify_certificate() is a function in the program, that then makes calls to openssl. (But I did not dig back into that today....)



I tested the application, setting SSL_CERT_DIR and SSL_CERT_FILE, to the empty directory and the CA file - did not help.

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.

This implies that there is something wrong with the CA in the openssl directory, but the one in the pem directory is okay? I compared Starfield_Root_Certificate_Authority_-_G2.pem in the openssl directory on the two systems - they are a binary match.


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

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
"

whereas the one from pem has nothing there. (I am also attaching the two certificates.)




Since I am trying to make a RDP connection, does this mean that the openssl version of the CA is not valid, because it says "Web Server Authentication". And, the new version makes more extensive checks that the old version?




I now have a work-around to make this application work, but I would like to know what really is going on - what changed to cause this.




------ Original Message ------
From: Viktor Dukhovni [hidden email]
Sent: Tue, 20 Nov 2018 08:56:58 -0500
To: Openssl-users [hidden email]

Subject: Re: [openssl-users] Problem with x509_verify_certificate
On Nov 20, 2018, at 1:31 AM, Ken [hidden email] wrote:

Are you saying to test with "openssl s_client -connect ..."?
Test both with s_client and with your application if possible.
In both cases configure the CApath empty and the CAfile to hold
just the appropriate trust anchor.  If your application does not
provide a way to specify the CAfile and CApath, OpenSSL defaults
can be overridden via environment variables:

	SSL_CERT_DIR
	SSL_CERT_FILE

I don't think I know how to interpret all of the output from that,
but it looked to me like it was saying everything was okay when I
tried it earlier (with no changes).
Try "s_client -quiet".  For example, a failure:

  $ openssl s_client -quiet -starttls smtp -connect localhost:25
  depth=0 CN = [...]
  verify error:num=20:unable to get local issuer certificate
  verify return:1
  depth=0 CN = [...]
  verify error:num=21:unable to verify the first certificate
  verify return:1

and a success:

  $ openssl s_client -quiet -starttls smtp -connect localhost:25 -CAfile rsacert.pem -partial_chain
  depth=0 CN = [...]
  verify return:1

I just tried it again with -CApath pointing to an empty directory, and -CAfile
pointing to a new copy of the root CA certificate, which I just downloaded from
the provider - I do not see any difference in the output.
You really do need to be much more precise. Is it failing?  Succeeding?
What version of OpenSSL is this particular s_client associated with?
At this point likely post the peer certificate chain (as reported by:

	sleep 2 | openssl s_client -showcerts -connect someaddr:someport 2>/dev/null
                | openssl crl2pkcs7 -nocert -certfile /dev/stdin
                | openssl pkcs7 -print_certs

Then, I tried again, pointing to an incorrect CA - then I see some errors:
"verify error:num=20:unable to get local issuer certificate"
Which suggests that it worked the first time.

So, it seems to me like, without any changes, s_client -connect says
the certificate is fine, but the application using x509_verify_certificate
thinks something is wrong....
Well, which trust store is the application using?  And what is this
x509_verify_certificate() you speak of?  I only know about
X509_verify_cert(3).  Which requires an appopriately initialized
X509_STORE_CTX, with suitable trust store settings.



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

s_client tests.txt (4K) Download Attachment
openssl-Starfield_Root_Certificate_Authority_-_G2.pem (1K) Download Attachment
pem-Starfield_Root_Certificate_Authority_-_G2.pem (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problem with x509_verify_certificate

Viktor Dukhovni
On Wed, Nov 21, 2018 at 11:36:46AM -0800, Ken wrote:

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

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

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

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

> Since I am trying to make a RDP connection, does this mean that the
> openssl version of the CA is not valid, because it says "Web Server
> Authentication". And, the new version makes more extensive checks that
> the old version?

It is valid, but has a restricted purpose.  Your application needs
to specify that purpose, but FreeRDP may not specify its peer as a
"TLS Web Server" (really TLS server) when doing certificate verification.

> I now have a work-around to make this application work, but I would like
> to know what really is going on - what changed to cause this.

The chain "extended Key Usage" is checked more consistently in
OpenSSL 1.1.x.

>  OpenSSL 1.0.2j-fips  26 Sep 2016

Note that in OpenSSL 1.0.2, the "s_client" command *always* loads the
*default* CAfile and default CApath, in *addition* to any CAfile
and CApath you might specify.  You need to point SSL_CERT_DIR to
an empty directory and SSL_CERT_FILE at the desired CAfile to make
sure that only the trusted certificates you want to test are used.

>
> # s_client with "no" options:
> $ openssl s_client -quiet -connect owa.xxxxx.com:3389
> depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2
> verify return:1
> depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2
> verify return:1
> depth=0 OU = Domain Control Validated, CN = owa.xxxxx.com
> verify return:1

This succeeds.

>
> # s_client, specifying correct CA:
> $ openssl s_client -quiet -connect owa.xxxxx.com:3389 -CApath ~/empty/ -CAfile sfroot-g2.crt
> depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2
> verify return:1
> depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2
> verify return:1
> depth=0 OU = Domain Control Validated, CN = owa.xxxxx.com
> verify return:1

This likewise.

> # s_client, specifying *WRONG* CA:
> $ openssl s_client -quiet -connect owa.xxxxx.com:3389 -CApath ~/empty/ -CAfile gdroot-g2.crt
> depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2
> verify return:1
> depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2
> verify return:1
> depth=0 OU = Domain Control Validated, CN = owa.xxxxx.com
> verify return:1

Probably still finds the right CA in the default CApath or CAfile.

> OpenSSL 1.1.0i-fips  14 Aug 2018

Note that to reduce WTF surprises, OpenSSL 1.1.x only loads the
*default* CAfile and CApath when you don't specify either on the
command-line, and you don't disable these with "-no-CAfile" or
"-no-CApath".  So the in tests below, you're not getting more than
what you ask for:

> # s_client with "no" options:
> $ openssl s_client -quiet -connect owa.xxxxx.com:3389
> depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2
> verify return:1
> depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2
> verify return:1
> depth=0 OU = Domain Control Validated, CN = owa.xxxxx.com
> verify return:1

This succeeds.

> # s_client, specifying correct CA:
> $ openssl s_client -quiet -connect owa.xxxxx.com:3389 -CApath ~/empty/ -CAfile sfroot-g2.crt
> depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2
> verify return:1
> depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2
> verify return:1
> depth=0 OU = Domain Control Validated, CN = owa.xxxxx.com
> verify return:1

This also succeeds.

> # s_client, specifying *WRONG* CA:
> $ openssl s_client -quiet -connect owa.xxxxx.com:3389 -CApath ~/empty/ -CAfile gdroot-g2.crt
> openssl s_client -quiet -connect owa.xxxxx.com:3389 -CApath ~/empty/ -CAfile gdroot-g2.crt
> depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certs.starfieldtech.com/repository/, CN = Starfield Secure Certificate Authority - G2
> verify error:num=20:unable to get local issuer certificate

Fails as expected.

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Ken
Reply | Threaded
Open this post in threaded view
|

Re: Problem with x509_verify_certificate

Ken
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
Ken
Reply | Threaded
Open this post in threaded view
|

Re: 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 [hidden email]
Sent: Thu, 22 Nov 2018 10:43:52 -0800
To: Openssl-users [hidden email]

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!




--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with x509_verify_certificate

Viktor Dukhovni
> On Nov 26, 2018, at 1:08 PM, Ken <[hidden email]> wrote:
>
> Is it "better" to use
>
> X509_STORE_CTX_set_default(csc, "ssl_server");

This does take care of all the niggly details, but see below...

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

The comment in check_purpose() in crypto/x509/x509_vfy.c may prove
illuminating:

    /*
     * For trusted certificates we want to see whether any auxiliary trust
     * settings trump the purpose constraints.
     *
     * This is complicated by the fact that the trust ordinals in
     * ctx->param->trust are entirely independent of the purpose ordinals in
     * ctx->param->purpose!
     *
     * What connects them is their mutual initialization via calls from
     * X509_STORE_CTX_set_default() into X509_VERIFY_PARAM_lookup() which sets
     * related values of both param->trust and param->purpose.  It is however
     * typically possible to infer associated trust values from a purpose value
     * via the X509_PURPOSE API.
     *
     * Therefore, we can only check for trust overrides when the purpose we're
     * checking is the same as ctx->param->purpose and ctx->param->trust is
     * also set.
     */

The solution is to call:

        X509_STORE_CTX_set_purpose(csc, X509_PURPOSE_SSL_SERVER)

which also takes care of all the "trust" bits.  The separation between
purpose values and trust values is rather obscure.  Sorry about that.
Most applications don't have to delve this deep.

> When I added X509_STORE_CTX_set0_param(csc,verify_param);

This is not valid, because you don't own the reference to verify_param,
and so cannot "give it away".  The object ends up freed.  This is why
Rust has a borrow-checker...  Time to start rewriting OpenSSL in Rust.

--
        Viktor.

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