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) {

        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(

    /**
     * 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

 * 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 {

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

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

{{/*
Formats volumeMount for MinIO TLS keys and trusted certs
*/}}
{{- define "minio.tlsKeysVolumeMount" -}}
{{- if .Values.tls.enabled }}
- name: cert-secret-volume
  mountPath: {{ .Values.certsPath }}
{{- end }}
{{- if or .Values.tls.enabled (ne .Values.trustedCertsSecret "") }}
{{- $casPath := printf "%s/CAs" .Values.certsPath | clean }}
- name: trusted-cert-secret-volume
  mountPath: {{ $casPath }}
{{- end }}

```
kubectl -n minio create secret generic minio-trusted-certs --from-file=keycloak.crt
```

The name of the generated secret can then be passed to Helm using a values file or the `--set` parameter:

```
trustedCertsSecret: "minio-trusted-certs"

or

--set trustedCertsSecret=minio-trusted-certs
```

### Create buckets after install

   *
   *
   * 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

 * 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.
 *

    <glob pattern="*.mmmp"/>
    <glob pattern="*.mmas"/>
  </mime-type>

  <mime-type type="application/vnd.minisoft-hp3000-save"/>
  <mime-type type="application/vnd.mitsubishi.misty-guard.trustweb"/>
  <mime-type type="application/vnd.mobius.daf">
    <glob pattern="*.daf"/>
  </mime-type>
  <mime-type type="application/vnd.mobius.dis">
    <glob pattern="*.dis"/>
  </mime-type>