<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 31/03/21 19:43, Michael Wojcik
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DM6PR18MB2700F39E813BA3F6BFBBB7E7F97C9@DM6PR18MB2700.namprd18.prod.outlook.com">
<blockquote type="cite">
<pre wrap="">From: openssl-users <a class="moz-txt-link-rfc2396E" href="mailto:openssl-users-bounces@openssl.org"><openssl-users-bounces@openssl.org></a> On Behalf Of Viktor
Dukhovni
Sent: Wednesday, 31 March, 2021 10:31
To: <a class="moz-txt-link-abbreviated" href="mailto:openssl-users@openssl.org">openssl-users@openssl.org</a>
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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
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:<br>
<br>
Additional Certificates (if supplied)<br>
Certificates provided 3 (5051 bytes)<br>
<b>Chain issues Contains anchor</b><br>
<br>
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.<br>
<br>
JM2CW,<br>
<br>
JJK / Jan Just Keijser<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>