OpenSSL chain build error diagnostics - Re: Why does OpenSSL report google's certificate is "self-signed"?

[David von Oheimb]

Hi Nan, Viktor, et al.,

/From: openssl-users https://mta.openssl.org/mailman/listinfo/openssl-users>> On Behalf Of
Viktor//Dukhovni //Sent: Wednesday, 31 March, 2021 10:31/
> Most likely you haven't configured a suitable CAfile and/or CApath,
> which contains the root CA that ultimately issued Google's certificate.

Yeah, that is the usual reason.

> It looks like Google includes a self-signed root CA in the wire
> certificate chain,
>
Not really. @Viktor, see the diagnostic output of the alternative call

   openssl s_client -connect google.com:443

that Nan provided below (and which is easy to reproduce):

> ---
> Certificate chain
>  0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN =
> *.google.com
>i:C = US, O = Google Trust Services, CN = GTS CA 1O1
>  1 s:C = US, O = Google Trust Services, CN = GTS CA 1O1
>i:OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
> ---
This chain does not include the root cert (which would be by GlobalSign
in this case).

@all, contrbuting to the discussion that spawned over the last couple of
days on whether the server should include the root of its chain:
IMO is should be advised not to include the root cert (i.e., the trust
anchor).
While the (needless) extra amount of data is usually not a problem,
the main problem that I see is that the receiver may be mislead to
accept the root cert as trusted although when received this way it is
not trustworthy.
Instead, when verifying the server chain, the receiver must already have
a trust store containing (root) certs that are considered trusted,
and for the chain received from the server there should be a suitable
trust anchor (which typically takes the form of a self-signed cert) in
that trust store.


> and if no match is found in the trust store,
> you'll get the reported error.
The reason must be something else. Note that the error was
X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT,
which means that the chain built contains only one element, and this
element is self-signed and not trusted.
So it cannot be the chain  *.google.com ->  GTS CA 1O1 -> GlobalSign.

@Nan, I find this error very unexpected - something pretty strange must
have happened in your application.
If no suitable trusted root is available in the trust store, the error
thrown should have been
20 ("unable to get local issuer certificate") =
X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY.

BTW, many of those OpenSSL verify error codes are IMHO pretty hard to
(correctly) understand and therefore should be re-phrased for clarity.
And unfortunately OpenSSL by default does not give much further
diagnostics on cert verification errors.
I advise using `X509_STORE_CTX_print_verify_cb()` which I added last
year to the master as part of the CMP contribution.
This can be done simply as follows:

    X509_STORE_set_verify_cb(my_X509_STORE, X509_STORE_CTX_print_verify_cb);

On X509_verify_cert() error, this provides in the error queue not only
the error code and string, but also the cert for which the error occurred
as well as the set of untrusted certs and the set of trust anchor certs
that were available for chain building in the current X509_STORE_CTX.

Regards,

   David


On 31.03.21 07:49, Nan Xiao wrote:
> Hi OpenSSL users,
>
> Greetings from me!
>
> I am using the master branch of OpenSSL and testing client-arg program
> (in demos/bio) with "google.com:443":
>
> # LD_LIBRARY_PATH=/root/openssl/build gdb --args ./client-arg -connect
> "google.com:443"
> ..
> (gdb)
> 91 if (BIO_do_connect(sbio) <= 0) {
> (gdb)
> 97 if (BIO_do_handshake(sbio) <= 0) {
> (gdb) p ssl->verify_result
> $1 = 18
>
> The connection is successful, but the ssl->verify_result is 18, i.e.,
> X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT. I am a little confused why
> OpenSSL reports google's certificate is "self-signed"? And it should
> be not. The following result is from "openssl s_client":
>
> # openssl s_client -connect google.com:443
> CONNECTED(0003)
> depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
> verify return:1
> depth=1 C = US, O = Google Trust Services, CN = GTS CA 1O1
> verify return:1
> depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN
> = *.google.com
> verify return:1
> ---
> Certificate chain
>  0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN =
> *.google.com
>i:C = US, O = Google Trust Services, CN = GTS CA 1O1
>  1 s:C = US, O = Google Trust Services, CN = GTS CA 1O1
>i:OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
> ---
>
> Anyone can give some clues? Thanks very much in advance!
>
> Best Regards
> Nan Xiao
>

Re: openssl-users Digest, Vol 77, Issue 4

[Dr Paul Dale]

I would be **very** concerned about bypassing a blocking RAND.  It is 
almost certainly blocking because it does not have enough randomness to 
satisfy your request.  By skipping this, you are likely getting poor 
quality random values and this can effectively negate any security you 
are gaining from the encryption.


Good random numbers are fundamental to modern cryptography.  Without 
them, there is no security.  I cannot stress this enough.  Do not try to 
second guess or bypass the RNG.



Pauli

On 3/4/21 6:41 pm, Vishwanath Mahajanshetty wrote:


Thank You Paul and Matthias for your help.

The reason I am trying to have separate RAND_METHOD for two threads 
is, the first thread which runs DNS *bind* code registers for 
RAND_METHOD through dnssec module in it. It registers via either 
ENGINE_set_default_RAND() or RAND_set_rand_method() based on 
OPENSSL_NO_ENGINE is defined or not. But problem is, under some 
circumstances the random number generator enters into blocking mode 
and starts to wait for some events on some FDs and it blocks in 
select() system call. dst__entropy_getdata()  from bind code is doing 
this. I am not sure under what cases it enters into blocking mode.


So If I use this RND_METHOD in second thread (basically this thread 
does different task of handling *DoT*, Dns Over TLS, connections, 
which is not related to first thread wrt SSL functionalities), then 
while creating SSL_CTX this thread gets stuck in select() system call 
randomly (happens very rarely as decided by dst__entropy_getdata()); 
this can happen at any time of SSL connection lifetime whenever it 
wants to get random data.


I agree with you that we should have done this as separate process 
instead of new thread; but I am trying figure out if I can somehow 
avoid this situation.


As you mentioned, I tried to look into implementation of RAND_bytes() 
and drbg_bytes().


When SSL_CTX_new() calls RAND_bytes(), it calls RAND_get_rand_method() 
which returns RAND_METHOD set by *bind* thread. So if I avoid 
configuring RAND_METHOD in *bind* thread, then RAND_get_rand_method() 
will return *rand_meth *which is OpenSSL default RAND_METHOD; but if I 
do this change bind thread will move away from its RAND_METHOD 
functions and start using OpenSSL default functions which may change 
its behaviour.


So I am still confused how can I do *bind* thread to use its own 
RAND_METHOD and *DoT* thread to use default OpenSSL RAND_METHOD. It 
would be really helpful if you can explain this with little more 
details (are there any APIs I can call from one thread to use its 
specific RAND_METHOD but other threads continue to use OpenSSL default 
RAND_METHOD?).


Thank You,

Vishwanath M

*From: *openssl-users-requ...@openssl.org 


*Sent: *02 April 2021 04:58 PM
*To: *openssl-users@openssl.org 
*Subject: *openssl-users Digest, Vol 77, Issue 4

Send openssl-users mailing list submissions to
    openssl-users@openssl.org

To subscribe or unsubscribe via the World Wide Web, visit
https://mta.openssl.org/mailman/listinfo/openssl-users 


or, via email, send a message with subject or body 'help' to
    openssl-users-requ...@openssl.org

You can reach the person managing the list at
    openssl-users-ow...@openssl.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."


Today's Topics:

   1. Re: Regarding RAND_set_rand_method (Dr Paul Dale)
   2. RE: Regarding RAND_set_rand_method (Dr. Matthias St. Pierre)


--

Message: 1
Date: Fri, 2 Apr 2021 16:51:28 +1000
From: Dr Paul Dale 
To: openssl-users@openssl.org
Subject: Re: Regarding RAND_set_rand_method
Message-ID: <1781ab4c-2e2b-fa3b-8b3c-fb4fc5bd3...@openssl.org>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

There isn't an easy a way to do what you want in 1.1.1.
RAND_set_rand_method replaces the RNG for all of OpenSSL.? In theory
your RAND_METHOD could detect which thread it is running in and do
different things for each.? I'm not sure this is a good idea however.

Why aren't the random number from your first thread good enough for the
second?? Good random numbers are just that - random.? It should be
impossible to distinguish the two streams.

In OpenSSL 3.0 there are ways to achieve what you're wanting.


Pauli

On 2/4/21 4:24 pm, Vishwanath Mahajanshetty wrote:
>
> Hi,
>
> I have some doubts/questions on how to use methods (for ex:
> RAND_set_rand_method) in multi threaded application which use OpenSSL.
> In my application (running on OpenSSL 1.1.1d) there are two threads
> which use OpenSSL, both threads perform very different operations. The
> issue I am facing is as below:
>
> Thread T1 calls RAND_set_rand_method() and sets RAND_METHOD structure.
> This is very specific to T1s use case. Whe

RE: openssl-users Digest, Vol 77, Issue 4

[Vishwanath Mahajanshetty]

Thank You Paul and Matthias for your help.

The reason I am trying to have separate RAND_METHOD for two threads is, the 
first thread which runs DNS bind code registers for RAND_METHOD through dnssec 
module in it. It registers via either ENGINE_set_default_RAND() or 
RAND_set_rand_method() based on OPENSSL_NO_ENGINE is defined or not. But 
problem is, under some circumstances the random number generator enters into 
blocking mode and starts to wait for some events on some FDs and it blocks in 
select() system call. dst__entropy_getdata()  from bind code is doing this. I 
am not sure under what cases it enters into blocking mode.

So If I use this RND_METHOD in second thread (basically this thread does 
different task of handling DoT, Dns Over TLS, connections, which is not related 
to first thread wrt SSL functionalities), then while creating SSL_CTX this 
thread gets stuck in select() system call randomly (happens very rarely as 
decided by dst__entropy_getdata()); this can happen at any time of SSL 
connection lifetime whenever it wants to get random data.

I agree with you that we should have done this as separate process instead of 
new thread; but I am trying figure out if I can somehow avoid this situation.

As you mentioned, I tried to look into implementation of RAND_bytes() and 
drbg_bytes().

When SSL_CTX_new() calls RAND_bytes(), it calls RAND_get_rand_method() which 
returns RAND_METHOD set by bind thread. So if I avoid configuring RAND_METHOD 
in bind thread, then RAND_get_rand_method() will return rand_meth which is 
OpenSSL default RAND_METHOD; but if I do this change bind thread will move away 
from its RAND_METHOD functions and start using OpenSSL default functions which 
may change its behaviour.

So I am still confused how can I do bind thread to use its own RAND_METHOD and 
DoT thread to use default OpenSSL RAND_METHOD. It would be really helpful if 
you can explain this with little more details (are there any APIs I can call 
from one thread to use its specific RAND_METHOD but other threads continue to 
use OpenSSL default RAND_METHOD?).

Thank You,
Vishwanath M



From: 
openssl-users-requ...@openssl.org
Sent: 02 April 2021 04:58 PM
To: openssl-users@openssl.org
Subject: openssl-users Digest, Vol 77, Issue 4

Send openssl-users mailing list submissions to
openssl-users@openssl.org

To subscribe or unsubscribe via the World Wide Web, visit
https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
openssl-users-requ...@openssl.org

You can reach the person managing the list at
openssl-users-ow...@openssl.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."


Today's Topics:

   1. Re: Regarding RAND_set_rand_method (Dr Paul Dale)
   2. RE: Regarding RAND_set_rand_method (Dr. Matthias St. Pierre)


--

Message: 1
Date: Fri, 2 Apr 2021 16:51:28 +1000
From: Dr Paul Dale 
To: openssl-users@openssl.org
Subject: Re: Regarding RAND_set_rand_method
Message-ID: <1781ab4c-2e2b-fa3b-8b3c-fb4fc5bd3...@openssl.org>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

There isn't an easy a way to do what you want in 1.1.1.
RAND_set_rand_method replaces the RNG for all of OpenSSL.? In theory
your RAND_METHOD could detect which thread it is running in and do
different things for each.? I'm not sure this is a good idea however.

Why aren't the random number from your first thread good enough for the
second?? Good random numbers are just that - random.? It should be
impossible to distinguish the two streams.

In OpenSSL 3.0 there are ways to achieve what you're wanting.


Pauli

On 2/4/21 4:24 pm, Vishwanath Mahajanshetty wrote:
>
> Hi,
>
> I have some doubts/questions on how to use methods (for ex:
> RAND_set_rand_method) in multi threaded application which use OpenSSL.
> In my application (running on OpenSSL 1.1.1d) there are two threads
> which use OpenSSL, both threads perform very different operations. The
> issue I am facing is as below:
>
> Thread T1 calls RAND_set_rand_method() and sets RAND_METHOD structure.
> This is very specific to T1s use case. When thread T2 wants to create
> SSL_CTX it calls SSL_CTX_new() which then calls RAND_priv_bytes(). I
> am observing that the function RAND_priv_bytes() is calling the
> function set by T1 by RAND_METHOD in RAND_set_rand_method().
>
> Essentially RAND_METHOD function set by thread T1 are getting called
> by thread T2.
>
> *Q1: I want to know is there any way to avoid this problem? I want
> thread T2 to call default RAND methods and avoid calling methods set
> by thread T1. This is not only for RAND methods, but for any other
> methods.*
>
> **
>
> Q2: Also, is it possible to run OpenSSL as separate instance per
> thread (where each thread ca