Runtime: Linux SslStream sends intermediate certificates in wrong order

[bartonjs]

When a certificate chain has 4 or more elements (end-entity -> low issuer -> ... -> high issuer -> root) the intermediate certificates are written in the wrong order on the wire.

• Create a certificate whose chain has 4 or more elements
• Trust the root
• Use the end-entity certificate in a server-role SslStream
• Connect to the endpoint using openssl s_client (e.g. openssl s_client -connect localhost:8000)
• Observe the certificate ordering

Expected:

Certificate chain
 0 s:/CN=End-Entity
   i:/CN=Low Issuer
 1 s:/CN=Low Issuer
   i:/CN=High Issuer
 2 s:/CN=High Issuer
   i:/CN=Trusted Root
---

Actual:

Certificate chain
 0 s:/CN=End-Entity
   i:/CN=Low Issuer
 1 s:/CN=High Issuer
   i:/CN=Trusted Root
 2 s:/CN=Low Issuer
   i:/CN=High Issuer
---

This puts our "long chain" implementation out of compliance with https://tools.ietf.org/html/rfc5246#section-7.4.2

      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  [...]

[bartonjs]

This will be fixed in the next releases (2.1.10, 2.2.4, 3.0 preview 4)