*
 *  * The client's handshake certificates must have a [held certificate][HeldCertificate] (a
 *    certificate and its private key). The client must also have a (possibly-empty) chain of
 *    intermediate certificates to establish trust from a root certificate to the client's
 *    certificate. The root certificate is not included in this chain.
 *  * The server's handshake certificates must include a set of trusted root certificates. They

The domains are securely verified and the certificates are generated automatically. This also allows automating the renewal of these certificates.

For testing purposes, here is [how to create self-signed certificates](https://github.com/minio/minio/tree/master/docs/tls#3-generate-self-signed-certificates).

## 2. Create Kubernetes secret

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
int specifies how many intermediate certificates are allowed beneath it in the chain.

```java
HeldCertificate rootCertificate = new HeldCertificate.Builder()
    .certificateAuthority(1)
    .build();

1. [Install MinIO Server](#install-minio-server)
2. [Use an Existing Key and Certificate with MinIO](#use-an-existing-key-and-certificate-with-minio)
3. [Generate and use Self-signed Keys and Certificates with MinIO](#generate-use-self-signed-keys-certificates)
4. [Install Certificates from Third-party CAs](#install-certificates-from-third-party-cas)

    // Add a bad intermediate CA and have that issue a rogue certificate for localhost. Prepare
    // an SSL context for an attacking webserver. It includes both these rogue certificates plus the
    // trusted good certificate above. The attack is that by including the good certificate in the
    // chain, we may trick the certificate pinner into accepting the rouge certificate.
    val compromisedIntermediateCa =
      HeldCertificate

credentials via the STS API. It can authenticate via a client certificate and obtain a access/secret key pair as well as a session token. These credentials are associated to an S3 policy at the MinIO server.

In case of certificate-based authentication, MinIO has to map the client-provided certificate to an S3 policy. MinIO does this via the subject common name field of the X.509 certificate. So, MinIO will associate a certificate with a subject `CN = foobar` to a S3 policy named `foobar`....

            |    certificate: ${CertificatePinner.pin(cert)}
            |    DN: ${cert.subjectDN.name}
            |    subjectAltNames: ${OkHostnameVerifier.allSubjectAltNames(cert)}
            """.trimMargin(),
          )
        } else {
          throw SSLPeerUnverifiedException(
            "Hostname ${address.url.host} not verified (no certificates)",
          )
        }
      }

FROM golang:1.24-alpine as build

ARG TARGETARCH
ARG RELEASE

ENV GOPATH=/go
ENV CGO_ENABLED=0

# Install curl and minisign
RUN apk add -U --no-cache ca-certificates && \
    apk add -U --no-cache curl && \
    go install aead.dev/minisign/cmd/minisign@v0.2.1

# Download minio binary and signature files
RUN curl -s -q https://dl.min.io/server/minio/hotfixes/linux-${TARGETARCH}/archive/minio.${RELEASE} -o /go/bin/minio && \

  /** Returns a possibly-empty list of certificates that identify this peer. */
  @get:JvmName("localCertificates") val localCertificates: List<Certificate>,
  // Delayed provider of peerCertificates, to allow lazy cleaning.
  peerCertificatesFn: () -> List<Certificate>,
) {
  /** Returns a possibly-empty list of certificates that identify the remote peer. */
  @get:JvmName("peerCertificates")