*
   *
   * The victim's gets a non-CA certificate signed by a CA, and pins the CA root and/or
   * intermediate. This is business as usual.
   *
   * ```
   *   pinnedRoot (trusted by CertificatePinner)
   *     -> pinnedIntermediate (trusted by CertificatePinner)
   *       -> realVictim
   * ```
   *
   * The attacker compromises a CA. They take the public key from an intermediate certificate

-----------------------

The above example uses a self-signed certificate. This is convenient for testing but not
representative of real-world HTTPS deployment. To get closer to that we can use `HeldCertificate`
to generate a trusted root certificate, an intermediate certificate, and a server certificate.
We use `certificateAuthority(int)` to create certificates that can sign other certificates. The

        selfSigned.certificate,
        trusted.certificate,
      )
    assertThat(cleaner.clean(list(certB, certA), "hostname")).isEqualTo(
      list(certB, certA, trusted, selfSigned),
    )
    assertThat(cleaner.clean(list(certB, certA, trusted), "hostname")).isEqualTo(
      list(certB, certA, trusted, selfSigned),
    )
    assertThat(cleaner.clean(list(certB, certA, trusted, selfSigned), "hostname"))
      .isEqualTo(

      val toVerify = result[result.size - 1] as X509Certificate

      // If this cert has been signed by a trusted cert, use that. Add the trusted certificate to
      // the end of the chain unless it's already present. (That would happen if the first
      // certificate in the chain is itself a self-signed and trusted CA certificate.)
      val trustedCert = trustRootIndex.findByIssuerAndSignature(toVerify)
      if (trustedCert != null) {

 * called certificate authorities (CAs).
 *
 * Browsers and other HTTP clients need a set of trusted root certificates to authenticate their
 * peers. Sets of root certificates are managed by either the HTTP client (like Firefox), or the
 * host platform (like Android). In July 2018 Android had 134 trusted root certificates for its HTTP
 * clients to trust.
 *

    /**
     * Configure the certificate chain to use when being authenticated. The first certificate is
     * the held certificate, further certificates are included in the handshake so the peer can
     * build a trusted path to a trusted root certificate.
     *
     * The chain should include all intermediate certificates but does not need the root certificate
     * that we expect to be known by the remote peer. The peer already has that certificate so

   *
   * This class exploits knowledge of Android implementation details. This class is potentially
   * much faster to initialize than [BasicTrustRootIndex] because it doesn't need to load and
   * index trusted CA certificates.
   */
  internal data class CustomTrustRootIndex(
    private val trustManager: X509TrustManager,
    private val findByIssuerAndSignatureMethod: Method,
  ) : TrustRootIndex {

 * certificate is signed by the certificate that follows, and the last certificate is a trusted CA
 * certificate.
 *
 * Use of the chain cleaner is necessary to omit unexpected certificates that aren't relevant to
 * the TLS handshake and to extract the trusted CA certificate for the benefit of certificate
 * pinning.
 */
abstract class CertificateChainCleaner {

import okhttp3.internal.toCanonicalHost
import okio.ByteString
import okio.ByteString.Companion.decodeBase64
import okio.ByteString.Companion.toByteString

/**
 * Constrains which certificates are trusted. Pinning certificates defends against attacks on
 * certificate authorities. It also prevents connections through man-in-the-middle certificate
 * authorities either known or unknown to the application's user.

 *  Fix: Handshake now returns peer certificates in canonical order: each certificate is signed by
    the certificate that follows and the last certificate is signed by a trusted root.

 *  Fix: Don't lose HTTP/2 flow control bytes when incoming data races with a stream close. If this
    happened enough then eventually the connection would stall.