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

[Jan Just Keijser]

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<openssl-users-bounces at openssl.org>  On Behalf Of Viktor
>>>> Dukhovni
>>>> Sent: Wednesday, 31 March, 2021 10:31
>>>> To:openssl-users at 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
>>
>>
>>
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210401/21729e0a/attachment-0001.html>