Re: OpenSSL chain build error diagnostics - Re: Why does OpenSSL report google's certificate is "self-signed"?
Hi David, Viktor and all other people,
Thanks very much for all your detailed explanation and time!
Best Regards
Nan Xiao
On Sun, Apr 4, 2021 at 3:21 AM David von Oheimb wrote:
>
> Hi Nan, Viktor, et al.,
>
> From: 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
>
OpenSSL chain build error diagnostics - Re: Why does OpenSSL report google's certificate is "self-signed"?
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: Why does OpenSSL report google's certificate is "self-signed"?
> From: Blumenthal, Uri - 0553 - MITLL > Sent: Thursday, 1 April, 2021 10:09 > To: Michael Wojcik ; openssl-users@openssl.org > 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
Re: Why does OpenSSL report google's certificate is "self-signed"?
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.
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. 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" 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 Description: S/MIME cryptographic signature
RE: Why does OpenSSL report google's certificate is "self-signed"?
> From: openssl-users On Behalf Of Mark > Hack > Sent: Thursday, 1 April, 2021 07:45 > To: openssl-users@openssl.org > 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
RE: Why does OpenSSL report google's certificate is "self-signed"?
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
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. On Wed, 2021-03-31 at 14:09 -0400, Viktor Dukhovni wrote: > > On Mar 31, 2021, at 2:04 PM, Walter H. > > wrote: > > > > On 31.03.2021 19:48, Viktor Dukhovni wrote: > > > > On Mar 31, 2021, at 1:43 PM, Michael Wojcik < > > > > michael.woj...@microfocus.com> 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. >
Re: Why does OpenSSL report google's certificate is "self-signed"?
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/03197 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 On Behalf Of Viktor Dukhovni Sent: Wednesday, 31 March, 2021 10:31 To:openssl-users@openssl.org 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
Re: Why does OpenSSL report google's certificate is "self-signed"?
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 On Behalf Of Viktor Dukhovni Sent: Wednesday, 31 March, 2021 10:31 To:openssl-users@openssl.org 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
Re: Why does OpenSSL report google's certificate is "self-signed"?
On 31/03/21 19:43, Michael Wojcik wrote: From: openssl-users On Behalf Of Viktor Dukhovni Sent: Wednesday, 31 March, 2021 10:31 To: openssl-users@openssl.org 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
Re: Why does OpenSSL report google's certificate is "self-signed"?
> On Mar 31, 2021, at 2:42 PM, Blumenthal, Uri - 0553 - MITLL > 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.
Re: Why does OpenSSL report google's certificate is "self-signed"?
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 wrote: > > >> >> On Mar 31, 2021, at 2:01 PM, Blumenthal, Uri - 0553 - MITLL >> 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 Description: S/MIME cryptographic signature
Re: Why does OpenSSL report google's certificate is "self-signed"?
> On Mar 31, 2021, at 2:01 PM, Blumenthal, Uri - 0553 - MITLL > 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.
Re: Why does OpenSSL report google's certificate is "self-signed"?
> On Mar 31, 2021, at 2:04 PM, Walter H. wrote: > > On 31.03.2021 19:48, Viktor Dukhovni wrote: >>> On Mar 31, 2021, at 1:43 PM, Michael Wojcik >>> 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.
Re: Why does OpenSSL report google's certificate is "self-signed"?
On 31.03.2021 19:48, Viktor Dukhovni wrote: On Mar 31, 2021, at 1:43 PM, Michael Wojcik 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 Description: S/MIME Cryptographic Signature
Re: Why does OpenSSL report google's certificate is "self-signed"?
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 wrote: > > >> >> On Mar 31, 2021, at 1:43 PM, Michael Wojcik >> 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 Description: S/MIME cryptographic signature
Re: Why does OpenSSL report google's certificate is "self-signed"?
> On Mar 31, 2021, at 1:43 PM, Michael Wojcik > 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.
RE: Why does OpenSSL report google's certificate is "self-signed"?
> From: openssl-users On Behalf Of Viktor > Dukhovni > Sent: Wednesday, 31 March, 2021 10:31 > To: openssl-users@openssl.org > 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
Re: Why does OpenSSL report google's certificate is "self-signed"?
> On Mar 31, 2021, at 1:49 AM, Nan Xiao 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.
