Why does OpenSSL report google's certificate is "self-signed"?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Why does OpenSSL report google's certificate is "self-signed"?

Nan Xiao
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(00000003)
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
Reply | Threaded
Open this post in threaded view
|

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

Viktor Dukhovni
> On Mar 31, 2021, at 1:49 AM, Nan Xiao <[hidden email]> wrote:
>
> 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.

Most likely you haven't configured a suitable CAfile and/or CApath,
which contains the root CA that ultimately issued Google's certificate.

It looks like Google includes a self-signed root CA in the wire
certificate chain, and if no match is found in the trust store,
you'll get the reported error.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

RE: Why does OpenSSL report google's certificate is "self-signed"?

Michael Wojcik
> From: openssl-users <[hidden email]> On Behalf Of Viktor
> Dukhovni
> Sent: Wednesday, 31 March, 2021 10:31
> To: [hidden email]
> Subject: Re: Why does OpenSSL report google's certificate is "self-signed"?
>
> It looks like Google includes a self-signed root CA in the wire
> certificate chain, and if no match is found in the trust store,
> you'll get the reported error.

What do people think about this practice of including the root in the chain?

As far as I can see, neither PKIX (RFC 5280) nor the CA/BF Baseline Requirements say anything about the practice, though I may have missed something. I had a vague memory that some standard or "best practice" guideline somewhere said the server should send the chain up to but not including the root, but I don't know what that might have been.

On the one hand, including the root doesn't help with path validation: either some certificate along the chain is a trust anchor already, in which case there's no need to include the root; or it isn't, in which case the peer has no reason to trust the chain.

On the other, it's useful for debugging, and perhaps for quickly finding whether the highest intermediate in the chain is signed by a trusted root if that intermediate is missing an AKID (though we'd hope that isn't the case).

I can also see an application deferring trust to the user in this case: "this chain ends in this root, which you don't currently trust, but maybe you'd like to add it?". Which doesn't seem like a great plan either -- and PKIX says trust anchors should be added using a trustworthy out-of-band procedure, which this is not -- but I suppose it's a conceivable use case.

--
Michael Wojcik
Reply | Threaded
Open this post in threaded view
|

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

Viktor Dukhovni
> On Mar 31, 2021, at 1:43 PM, Michael Wojcik <[hidden email]> wrote:
>
> As far as I can see, neither PKIX (RFC 5280) nor the CA/BF Baseline Requirements say anything about the practice, though I may have missed something. I had a vague memory that some standard or "best practice" guideline somewhere said the server should send the chain up to but not including the root, but I don't know what that might have been.

Inclusion of the self-signed root is harmless.  The only case that
I know of where this is actually necessary is with DANE-TA(2) when
the TLSA RRset has a hash of the trusted root cert or public key.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

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

Blumenthal, Uri - 0553 - MITLL
For a Web GUI with the user at the console (e.g., a Web browser), it might be OK.

For my needs (devices talking to each other over austere links), sending the root CA very is both useless and wasteful. One you factor in the sizes of Post-Quantum keys and signatures - you’ll start disliking this idea even more.

Regards,
Uri

> On Mar 31, 2021, at 13:49, Viktor Dukhovni <[hidden email]> wrote:
>
> 
>>
>> On Mar 31, 2021, at 1:43 PM, Michael Wojcik <[hidden email]> wrote:
>>
>> As far as I can see, neither PKIX (RFC 5280) nor the CA/BF Baseline Requirements say anything about the practice, though I may have missed something. I had a vague memory that some standard or "best practice" guideline somewhere said the server should send the chain up to but not including the root, but I don't know what that might have been.
>
> Inclusion of the self-signed root is harmless.  The only case that
> I know of where this is actually necessary is with DANE-TA(2) when
> the TLSA RRset has a hash of the trusted root cert or public key.
>
> --
>    Viktor.
>

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Walter H.
In reply to this post by Viktor Dukhovni
On 31.03.2021 19:48, Viktor Dukhovni wrote:
>> On Mar 31, 2021, at 1:43 PM, Michael Wojcik <[hidden email]> wrote:
>>
>> As far as I can see, neither PKIX (RFC 5280) nor the CA/BF Baseline Requirements say anything about the practice, though I may have missed something. I had a vague memory that some standard or "best practice" guideline somewhere said the server should send the chain up to but not including the root, but I don't know what that might have been.
> Inclusion of the self-signed root is harmless.

do some admins this really?

I have more often the problem, that just the end SSL certificate is sent,
and without the intermediate certificate any validation is impossible;
in such case I download the intermediate just to complete the chain;

> The only case that
> I know of where this is actually necessary is with DANE-TA(2) when
> the TLSA RRset has a hash of the trusted root cert or public key.
>
this case is history, there doesn't exist any user agent, which has
implemented this;




smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Viktor Dukhovni
> On Mar 31, 2021, at 2:04 PM, Walter H. <[hidden email]> wrote:
>
> On 31.03.2021 19:48, Viktor Dukhovni wrote:
>>> On Mar 31, 2021, at 1:43 PM, Michael Wojcik <[hidden email]> wrote:
>>>
>>> As far as I can see, neither PKIX (RFC 5280) nor the CA/BF Baseline Requirements say anything about the practice, though I may have missed something. I had a vague memory that some standard or "best practice" guideline somewhere said the server should send the chain up to but not including the root, but I don't know what that might have been.
>> Inclusion of the self-signed root is harmless.
>
> do some admins this really?

Since it is possible to do, inevitably some will do it.

>> The only case that
>> I know of where this is actually necessary is with DANE-TA(2) when
>> the TLSA RRset has a hash of the trusted root cert or public key.
>>
> this case is history, there doesn't exist any user agent, which has implemented this;

Well, that's false, just because you're not familiar with it, does not
mean it does not exist.  OpenSSL, Postfix, Exim, Halon MTA, Cisco ESA,
PowerMTA, ... all support DANE, including DANE-TA(2).

Yes, no major browsers as yet supports DANE.  But not all TLS is HTTPS
and not all HTTPS is browsers viewing websites.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

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

Viktor Dukhovni
In reply to this post by Blumenthal, Uri - 0553 - MITLL
> On Mar 31, 2021, at 2:01 PM, Blumenthal, Uri - 0553 - MITLL <[hidden email]> wrote:
>
> For a Web GUI with the user at the console (e.g., a Web browser), it might be OK.
>
> For my needs (devices talking to each other over austere links), sending the root CA very is both useless and wasteful. One you factor in the sizes of Post-Quantum keys and signatures - you’ll start disliking this idea even more.

There's no urgency in post-quantum keys for CA signatures in TLS.  Their
future weakness does not compromise today's traffic.  Until actual scalable
QCs start cracking RSA and ECDSA in near real-time only the ephemeral key
agreement algorithm needs to be PQ-resistant now to future-proof session
confidentiality.

So certificates can continue to use RSA and ECDSA for quite some time.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

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

Blumenthal, Uri - 0553 - MITLL
You are right - there’s no urgency in PQ signatures

However, PQ KEM keys aren’t small. And, as I said, für austere links every unnecessary byte of crap hurts. 

Also, sending root certs seems (marginally) useful only when the recipient is a Web browser. And even then I  assume most of the IT people would want to block the ability of a “mere” user to add an “unblessed” trusted root. 

Regards,
Uri

On Mar 31, 2021, at 14:15, Viktor Dukhovni <[hidden email]> wrote:


On Mar 31, 2021, at 2:01 PM, Blumenthal, Uri - 0553 - MITLL <[hidden email]> wrote:

For a Web GUI with the user at the console (e.g., a Web browser), it might be OK.

For my needs (devices talking to each other over austere links), sending the root CA very is both useless and wasteful. One you factor in the sizes of Post-Quantum keys and signatures - you’ll start disliking this idea even more.

There's no urgency in post-quantum keys for CA signatures in TLS.  Their
future weakness does not compromise today's traffic.  Until actual scalable
QCs start cracking RSA and ECDSA in near real-time only the ephemeral key
agreement algorithm needs to be PQ-resistant now to future-proof session
confidentiality.

So certificates can continue to use RSA and ECDSA for quite some time.

--
   Viktor.


smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Viktor Dukhovni
> On Mar 31, 2021, at 2:42 PM, Blumenthal, Uri - 0553 - MITLL <[hidden email]> wrote:
>
> You are right - there’s no urgency in PQ signatures.
>
> However, PQ KEM keys aren’t small. And, as I said, für austere links every unnecessary byte of crap hurts.
>
> Also, sending root certs seems (marginally) useful only when the recipient is a Web browser. And even then I  assume most of the IT people would want to block the ability of a “mere” user to add an “unblessed” trusted root.

I am not trying to suggest that including the root CA in the server's
chain is a best practice.  I am sticking with mostly harmless.

And even with DANE, my recommendation is to use an intermediate CA
with the DANE-TA(2) records, and not rely on the root CA being part
of the transmitted chain.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

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

Jan Just Keijser-2
In reply to this post by Michael Wojcik
On 31/03/21 19:43, Michael Wojcik wrote:
From: openssl-users [hidden email] On Behalf Of Viktor
Dukhovni
Sent: Wednesday, 31 March, 2021 10:31
To: [hidden email]
Subject: Re: Why does OpenSSL report google's certificate is "self-signed"?

It looks like Google includes a self-signed root CA in the wire
certificate chain, and if no match is found in the trust store,
you'll get the reported error.
What do people think about this practice of including the root in the chain?

As far as I can see, neither PKIX (RFC 5280) nor the CA/BF Baseline Requirements say anything about the practice, though I may have missed something. I had a vague memory that some standard or "best practice" guideline somewhere said the server should send the chain up to but not including the root, but I don't know what that might have been.

On the one hand, including the root doesn't help with path validation: either some certificate along the chain is a trust anchor already, in which case there's no need to include the root; or it isn't, in which case the peer has no reason to trust the chain.

On the other, it's useful for debugging, and perhaps for quickly finding whether the highest intermediate in the chain is signed by a trusted root if that intermediate is missing an AKID (though we'd hope that isn't the case).

I can also see an application deferring trust to the user in this case: "this chain ends in this root, which you don't currently trust, but maybe you'd like to add it?". Which doesn't seem like a great plan either -- and PKIX says trust anchors should be added using a trustworthy out-of-band procedure, which this is not -- but I suppose it's a conceivable use case.


The only thing I'd like to add to this is that whenever I *do* include the root anchor in a website and run Qualys' ssllabs test on it, I get a (minor) warning:

Additional Certificates (if supplied)
Certificates provided     3 (5051 bytes)
Chain issues     Contains anchor

Unfortunately their documentation does not state *why* they print out this warning or why it would be bad, but I normally remove the trust anchor from the webserver certificate chain nevertheless.  It  could very well be that I'm not the only web admin that follows their advice in this respect.

JM2CW,

JJK / Jan Just Keijser






Reply | Threaded
Open this post in threaded view
|

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

Dr Paul Dale-2
Perhaps ask Qualys to answer your concerns directly?  They must have a reason for including this warning.



Pauli

On 1/4/21 5:43 pm, Jan Just Keijser wrote:
On 31/03/21 19:43, Michael Wojcik wrote:
From: openssl-users [hidden email] On Behalf Of Viktor
Dukhovni
Sent: Wednesday, 31 March, 2021 10:31
To: [hidden email]
Subject: Re: Why does OpenSSL report google's certificate is "self-signed"?

It looks like Google includes a self-signed root CA in the wire
certificate chain, and if no match is found in the trust store,
you'll get the reported error.
What do people think about this practice of including the root in the chain?

As far as I can see, neither PKIX (RFC 5280) nor the CA/BF Baseline Requirements say anything about the practice, though I may have missed something. I had a vague memory that some standard or "best practice" guideline somewhere said the server should send the chain up to but not including the root, but I don't know what that might have been.

On the one hand, including the root doesn't help with path validation: either some certificate along the chain is a trust anchor already, in which case there's no need to include the root; or it isn't, in which case the peer has no reason to trust the chain.

On the other, it's useful for debugging, and perhaps for quickly finding whether the highest intermediate in the chain is signed by a trusted root if that intermediate is missing an AKID (though we'd hope that isn't the case).

I can also see an application deferring trust to the user in this case: "this chain ends in this root, which you don't currently trust, but maybe you'd like to add it?". Which doesn't seem like a great plan either -- and PKIX says trust anchors should be added using a trustworthy out-of-band procedure, which this is not -- but I suppose it's a conceivable use case.


The only thing I'd like to add to this is that whenever I *do* include the root anchor in a website and run Qualys' ssllabs test on it, I get a (minor) warning:

Additional Certificates (if supplied)
Certificates provided     3 (5051 bytes)
Chain issues     Contains anchor

Unfortunately their documentation does not state *why* they print out this warning or why it would be bad, but I normally remove the trust anchor from the webserver certificate chain nevertheless.  It  could very well be that I'm not the only web admin that follows their advice in this respect.

JM2CW,

JJK / Jan Just Keijser







Reply | Threaded
Open this post in threaded view
|

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

Jan Just Keijser-2
On 01/04/21 09:49, Dr Paul Dale wrote:
Perhaps ask Qualys to answer your concerns directly?  They must have a reason for including this warning.


oh, I am not particularly /concerned/ about it  - it's just that I noticed Qualys spits out this warning whenever I do include the root anchor, without bothering to tell me *why*. A search points me to this discussion:
  https://qualys-secure.force.com/discussions/s/article/000003197

which says it is harmless to include the root anchor, except that it will increase your site's latency due to a (slightly) larger TLS handshake.

cheers,

JJK / Jan Just Keijser


On 1/4/21 5:43 pm, Jan Just Keijser wrote:
On 31/03/21 19:43, Michael Wojcik wrote:
From: openssl-users [hidden email] On Behalf Of Viktor
Dukhovni
Sent: Wednesday, 31 March, 2021 10:31
To: [hidden email]
Subject: Re: Why does OpenSSL report google's certificate is "self-signed"?

It looks like Google includes a self-signed root CA in the wire
certificate chain, and if no match is found in the trust store,
you'll get the reported error.
What do people think about this practice of including the root in the chain?

As far as I can see, neither PKIX (RFC 5280) nor the CA/BF Baseline Requirements say anything about the practice, though I may have missed something. I had a vague memory that some standard or "best practice" guideline somewhere said the server should send the chain up to but not including the root, but I don't know what that might have been.

On the one hand, including the root doesn't help with path validation: either some certificate along the chain is a trust anchor already, in which case there's no need to include the root; or it isn't, in which case the peer has no reason to trust the chain.

On the other, it's useful for debugging, and perhaps for quickly finding whether the highest intermediate in the chain is signed by a trusted root if that intermediate is missing an AKID (though we'd hope that isn't the case).

I can also see an application deferring trust to the user in this case: "this chain ends in this root, which you don't currently trust, but maybe you'd like to add it?". Which doesn't seem like a great plan either -- and PKIX says trust anchors should be added using a trustworthy out-of-band procedure, which this is not -- but I suppose it's a conceivable use case.


The only thing I'd like to add to this is that whenever I *do* include the root anchor in a website and run Qualys' ssllabs test on it, I get a (minor) warning:

Additional Certificates (if supplied)
Certificates provided     3 (5051 bytes)
Chain issues     Contains anchor

Unfortunately their documentation does not state *why* they print out this warning or why it would be bad, but I normally remove the trust anchor from the webserver certificate chain nevertheless.  It  could very well be that I'm not the only web admin that follows their advice in this respect.

JM2CW,

JJK / Jan Just Keijser








Reply | Threaded
Open this post in threaded view
|

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

Mark Hack
In reply to this post by Viktor Dukhovni
RFC6066

   Note that when a list of URLs for X.509 certificates is used, the
   ordering of URLs is the same as that used in the TLS Certificate
   message (see [RFC5246], Section 7.4.2), but opposite to the order in
   which certificates are encoded in PkiPath.  In either case, the
self-signed root certificate MAY be omitted from the chain, under the
   assumption that the server must already possess it in order to
   validate it.


On Wed, 2021-03-31 at 14:09 -0400, Viktor Dukhovni wrote:

> > On Mar 31, 2021, at 2:04 PM, Walter H. <[hidden email]>
> > wrote:
> >
> > On 31.03.2021 19:48, Viktor Dukhovni wrote:
> > > > On Mar 31, 2021, at 1:43 PM, Michael Wojcik <
> > > > [hidden email]> wrote:
> > > >
> > > > As far as I can see, neither PKIX (RFC 5280) nor the CA/BF
> > > > Baseline Requirements say anything about the practice, though I
> > > > may have missed something. I had a vague memory that some
> > > > standard or "best practice" guideline somewhere said the server
> > > > should send the chain up to but not including the root, but I
> > > > don't know what that might have been.
> > >
> > > Inclusion of the self-signed root is harmless.
> >
> > do some admins this really?
>
> Since it is possible to do, inevitably some will do it.
>
> > > The only case that
> > > I know of where this is actually necessary is with DANE-TA(2)
> > > when
> > > the TLSA RRset has a hash of the trusted root cert or public key.
> > >
> >
> > this case is history, there doesn't exist any user agent, which has
> > implemented this;
>
> Well, that's false, just because you're not familiar with it, does
> not
> mean it does not exist.  OpenSSL, Postfix, Exim, Halon MTA, Cisco
> ESA,
> PowerMTA, ... all support DANE, including DANE-TA(2).
>
> Yes, no major browsers as yet supports DANE.  But not all TLS is
> HTTPS
> and not all HTTPS is browsers viewing websites.
>

Reply | Threaded
Open this post in threaded view
|

RE: Why does OpenSSL report google's certificate is "self-signed"?

Michael Wojcik
> From: openssl-users <[hidden email]> On Behalf Of Mark
> Hack
> Sent: Thursday, 1 April, 2021 07:45
> To: [hidden email]
> Subject: Re: Why does OpenSSL report google's certificate is "self-signed"?
>
> RFC6066
>
>    Note that when a list of URLs for X.509 certificates is used, the
>    ordering of URLs is the same as that used in the TLS Certificate
>    message (see [RFC5246], Section 7.4.2), but opposite to the order in
>    which certificates are encoded in PkiPath.  In either case, the
> self-signed root certificate MAY be omitted from the chain, under the
>    assumption that the server must already possess it in order to
>    validate it.

Thanks! I thought I'd seen something about the question in some standard. Having seen this, I see that RFC 8446 (TLSv1.3) has essentially the same language: "a certificate that specifies a trust anchor MAY be omitted from the chain" (4.4.2). So servers are good either way.

--
Michael Wojcik
Reply | Threaded
Open this post in threaded view
|

RE: Why does OpenSSL report google's certificate is "self-signed"?

Michael Wojcik
In reply to this post by Jan Just Keijser-2
Thanks to everyone who responded. You've confirmed my impression:

- There doesn't appear to be any applicable standard which requires or forbids including the root, or even endorses or discourages it).

- It's harmless except for performance issues and possible low-severity flags from analyses like Qualys's. (I wouldn't be surprised to have a customer raise this -- many of our customers run various scanning tools -- but for the products I work with, customers configure certificate chains anyway, so it's not a product issue.)

- Performance issues are likely negligible in many cases, where servers aren't dealing with huge workloads, but it's worth remembering that eventually people will be deploying PQC and most of the NIST finalists involve significantly larger keys or signatures. (They don't *all* have much larger keys/signatures; Falcon has a small combined public key and signature, if memory serves.)

--
Michael Wojcik
Reply | Threaded
Open this post in threaded view
|

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

Blumenthal, Uri - 0553 - MITLL
In general - I concur, but there are nuances: sending root CA cert is mostly harmless, but mostly useless - except when there's a human on the receiving end that can and is allowed to make a decision to accept and trust that CA cert.

Re. PQC - even the "smallest" among them are much larger than what the Classic keys and signatures are. E.g., Falcon-1024 signature is 1330 bytes (or often less - say, 1200 bytes). Falcon-1024 public key is 1793 bytes. Compare to, e.g., ECC-384 sizes... NTRU public keys are "easier", but not by that much: 1230 bytes. Kyber public key is 1568 bytes. And I picked the *smallest* ones - those I'd consider using myself.  

There's also McEliece... __
--
Regards,
Uri
 
There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
                                                                                                                                     -  C. A. R. Hoare
 

On 4/1/21, 10:23, "openssl-users on behalf of Michael Wojcik" <[hidden email] on behalf of [hidden email]> wrote:

    Thanks to everyone who responded. You've confirmed my impression:

    - There doesn't appear to be any applicable standard which requires or forbids including the root, or even endorses or discourages it).

    - It's harmless except for performance issues and possible low-severity flags from analyses like Qualys's. (I wouldn't be surprised to have a customer raise this -- many of our customers run various scanning tools -- but for the products I work with, customers configure certificate chains anyway, so it's not a product issue.)

    - Performance issues are likely negligible in many cases, where servers aren't dealing with huge workloads, but it's worth remembering that eventually people will be deploying PQC and most of the NIST finalists involve significantly larger keys or signatures. (They don't *all* have much larger keys/signatures; Falcon has a small combined public key and signature, if memory serves.)

    --
    Michael Wojcik

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Peter Sylvester-4
In reply to this post by Michael Wojcik
On 01/04/2021 16:21, Michael Wojcik wrote:
Thanks to everyone who responded. You've confirmed my impression:

- There doesn't appear to be any applicable standard which requires or forbids including the root, or even endorses or discourages it).

rfc8446  page 65:

   ....  The sender's certificate MUST come in the first
   CertificateEntry in the list.  Each following certificate SHOULD
   directly certify the one immediately preceding it.  Because
   certificate validation requires that trust anchors be distributed
   independently, a certificate that specifies a trust anchor MAY be
   omitted from the chain, provided that supported peers are known to
   possess any omitted certificates.

   Note: Prior to TLS 1.3, "certificate_list" ordering required each
   certificate to certify the one immediately preceding it; however,
   some implementations allowed some flexibility.  Servers sometimes
   send both a current and deprecated intermediate for transitional
   purposes, and others are simply configured incorrectly, but these
   cases can nonetheless be validated properly.  For maximum
   compatibility, all implementations SHOULD be prepared to handle
   potentially extraneous certificates and arbitrary orderings from any
   TLS version, with the exception of the end-entity certificate which
   MUST be first.
Reply | Threaded
Open this post in threaded view
|

RE: Why does OpenSSL report google's certificate is "self-signed"?

Michael Wojcik
In reply to this post by Blumenthal, Uri - 0553 - MITLL
> From: Blumenthal, Uri - 0553 - MITLL <[hidden email]>
> Sent: Thursday, 1 April, 2021 10:09
> To: Michael Wojcik <[hidden email]>; [hidden email]
> Subject: Re: Why does OpenSSL report google's certificate is "self-signed"?
>
> In general - I concur, but there are nuances: sending root CA cert is mostly
> harmless, but mostly useless - except when there's a human on the receiving
> end that can and is allowed to make a decision to accept and trust that CA
> cert.

Agreed. I tried to capture the summary of pros and cons in the document I'm writing for our customers.

> Re. PQC - even the "smallest" among them are much larger than what the
> Classic keys and signatures are. E.g., Falcon-1024 signature is 1330 bytes
> (or often less - say, 1200 bytes). Falcon-1024 public key is 1793 bytes.
> Compare to, e.g., ECC-384 sizes... NTRU public keys are "easier", but not by
> that much: 1230 bytes. Kyber public key is 1568 bytes. And I picked the
> *smallest* ones - those I'd consider using myself.
>
> There's also McEliece...

Yeah, if NIST standardizes on Classic McEliece for KEM, that's going to give us some *big* keys.

Certainly for resource-constrained applications, like embedded or high-volume, it makes sense to omit the root even with ECC. A few KB here and there will add up.

--
Michael Wojcik
Reply | Threaded
Open this post in threaded view
|

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

David von Oheimb-2
In reply to this post by Nan Xiao

Hi Nan, Viktor, et al.,

From: openssl-users <openssl-users-bounces at openssl.org> 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(00000003)
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

12