Enable Network Encryption

MinIO AIStor implements Transport Layer Security (TLS) 1.2+ encryption with support for Server Name Indication (SNI) for selecting relevant TLS certificates in response to client requests.

You must set up TLS before you can enable data encryption, also called server-side encryption. See Configure TLS Network Encryption for how to do it on .deb or .rpm based Linux distributions.

MinIO AIStor supports the following types of certificate signatures:

• self-signed

• internal or private certificate authorities (CAs)

• third-party CAs

Multiple certificates are implemented with SNI to determine which certificate to return to a client based on the hostname in the request.

MinIO AIStor searches for TLS certificates at $HOME/.minio/certs by default. The certificate directory must contain a PEM-encoded TLS key pair named public.crt and private.key.

If you install with the binary, this directory is created automatically.

The MinIO AIStor DEB or RPM installers, however, create a minio-user system user that has no home directory or login privileges. In this case, follow the instructions to Enable TLS Encryption. These instructions explain manually creating the certificate path.

To use a custom certificate path, specify the --certs-dir flag or set the path in the environment file as part of MINIO_OPTS:

minio server --certs-dir /path/to/custom/certs

Make sure the user running the MinIO AIStor service has read permissions to the certificate files and write permissions to the certificate directory.

MinIO AIStor supports multiple TLS certificates for different hostnames using Server Name Indication (SNI). Organize certificates in the following directory structure:

certs/
 ├─ public.crt         # Default certificate
 ├─ private.key        # Default private key
 │
 ├─ example.com/       # Subdirectory name is ignored
 │  ├─ public.crt
 │  └─ private.key
 └─ internal.corp/
    ├─ public.crt
    └─ private.key

Each key pair must use the file names public.crt and private.key. MinIO AIStor ignores the subdirectory names but skips any directory named CAs or prefixed with ... Symbolic links to directories are supported and resolved automatically.

When a client connects, MinIO AIStor uses SNI to match the requested hostname against the Subject Alternative Names (SANs) of the available certificates. MinIO AIStor returns the first certificate whose SAN matches the requested hostname. If no certificate matches, or if the client does not send an SNI hostname (for example, when connecting directly to an IP address), MinIO AIStor returns the default certificate from the root directory.

For detailed instructions, examples of certificate directory structure, and security guidance on certificate placement, see Configure TLS Network Encryption.

MinIO AIStor loads trusted CA certificates from both the host system’s root certificate store and the CAs/ subdirectory within the certificate directory (for example, $HOME/.minio/certs/CAs/). Place PEM-encoded CA certificate files in this directory. MinIO AIStor reads all top-level files in the CAs/ directory and adds valid X.509 PEM certificates to the trusted root CA pool.

If MinIO AIStor cannot verify an incoming client’s TLS certificate against the combined CA pool, the server rejects the connection.

MinIO AIStor also adds the public certificates from all loaded TLS key pairs to the root CA pool. This allows self-signed certificates to work without placing a copy in the CAs/ directory. For production deployments, place the issuing CA certificate in the CAs/ directory rather than relying on this behavior.

When using certificate-based STS authentication (AssumeRoleWithCertificate), MinIO AIStor allows up to 10 intermediate CA certificates in the client certificate chain.

MinIO AIStor automatically reloads TLS certificates when the underlying files change. On Linux, MinIO AIStor uses inotify to watch for IN_CLOSE_WRITE and IN_MOVED_TO events on the certificate directories. On other platforms, MinIO AIStor watches for file Create and Write events. This detects certificate updates made by writing a new file and renaming it into place (atomic update), which is the recommended method for rotating certificates.

When a file change is detected, MinIO AIStor re-reads both public.crt and private.key, computes SHA-256 hashes of the new content, and reloads the certificate only if the content has changed. If the reload fails due to an invalid key pair or a partially written file, MinIO AIStor continues serving the previously loaded certificate.

For certificates that use symbolic links (common with cert-manager on Kubernetes or other automated certificate management tools), MinIO AIStor polls the symlink targets every 10 seconds to detect changes.

Automatic reloading detects modifications to existing certificate files. To pick up structural changes to the certificates directory, such as adding or removing subdirectories, send the SIGHUP signal to trigger a full rescan.

Use SIGHUP when you:

• Add new certificate subdirectories for additional hostnames.
• Remove certificate subdirectories that are no longer needed.
• Reorganize the certificate directory structure.

To trigger a certificate rescan:

kill -SIGHUP $(pgrep minio)

If certificate loading fails during a SIGHUP rescan, MinIO AIStor continues using the previously loaded certificates.

MinIO AIStor uses a separate configuration for internal, internode connections. When a node sends a request to another node, it includes a hash of the public key derived from the root credentials to establish trust. This requires that nodes have a direct TLS connection to all other nodes in the cluster.

If you require a reverse proxy or similar service between nodes, this may cause TLS to fail. Create an issue in SUBNET for assistance is configuring the system to work in such a scenario.

MinIO AIStor in FIPS mode supports only the AES-GCM ciphers. FIPS mode excludes CHACHA20_POLY1305 and all CBC cipher suites.

MinIO AIStor supports the following public key algorithms:

• RSA-2048 up to RSA-4096, OAEP and PSS
• ECDSA with P-256, P-384 and P-521
• EdDSA/Ed25519

MinIO AIStor in FIPS mode does not support EdDSA/Ed25519 algorithms.

MinIO AIStor supports the following signature hash functions:

• SHA2-256
• SHA2-384
• SHA2-512