Enable Network Encryption

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.

AIStor supports the following types of certificate signatures:

• self-signed

• internal or private certificate authorities (CAs)

• third-party CAs

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

AIStor searches by default for certificates at $HOME/.minio/certs. If you install with the binary, this directory is created automatically.

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

If you work with a user-specified path, specify your path in the environment file as part of MINIO_OPTS. Or you can run:

minio server --certs-dir PATH_TO_CUSTOM_CERTS_LOCATION

Make sure the user running the AIStor service has read and write permissions to this location.

AIStor supports multiple TLS certificates using Server Name Indication (SNI) to determine which certificate to return to a client based on the hostname in the request.

If AIStor cannot find a TLS certificate whose SAN covers the client-requested hostname, AIStor uses the default certificate and attempts to establish the handshake. If no certificates match the client request hostname, AIStor returns a TLS error indicating a failure to match the hostname against a valid certificate.

AIStore validates the TLS certificate presented by each connecting client against the host system’s trusted root certificate store. If AIStor cannot match an incoming client’s TLS certificate issuer against any of the available CAs, the server rejects the connection as invalid.

AIStor supports private, internal, or other third-party CAs but you must make sure to provide a CA file that includes the full chain of certificates, including any intermediate or leaf certificates. AIStor allows up to 10 intermediate certificates from request to trusted root certificate.

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.

The following table provides MinIO’s recommendations for TLS certificates for AIStor:

AIStor supports the following TLS 1.2 and 1.3 cipher suites as supported by Go. Recommended algorithms are marked with an asterisk (*):

AIStor in FIPS mode supports only the AES ciphers.

Key Manager supports the following public key signature algorithms:

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

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

Key Manager supports the following signature hash functions:

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