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. <Walter.H@xxxxxxxxxxxxxxxxx> > > wrote: > > > > On 31.03.2021 19:48, Viktor Dukhovni wrote: > > > > On Mar 31, 2021, at 1:43 PM, Michael Wojcik < > > > > Michael.Wojcik@xxxxxxxxxxxxxx> 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. >
