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.

Certificate Path

AIStor searches for certificates at either a default or user-specified path. The structure of folders at that path must conform as follows:

/certs
  private.key
  public.crt

Place the TLS certificates for the default domain (for example aistor.example.net) in the /certs directory, with the private key as private.key and public certificate as public.crt.

The full path to the /certs directory depends on your AIStor configuration.

Default path

By default, AIStor looks for the TLS keys and certificates for each node in the following directory:

${HOME}/.minio/certs

where ${HOME} is the home directory of the user running the AIStor process. You may need to create the ${HOME}/.minio/certs directory if it does not exist.

For systemd managed deployments this must correspond to the USER running the AIStor process. If that user has no home directory, use the Custom Path option instead.

Custom path

You can specify a path for the AIStor to search for certificates using the aistor server --certs-dir or -S parameter.

For example, the following command fragment directs the AIStor process to use the /opt/minio/certs directory for TLS certificates.

minio server --certs-dir /opt/minio/certs ...

The user running the AIStor service must have read and write permissions to this directory.

Multiple TLS Certificates

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.

Create a subfolder for each set of TLS certificates in the certificate path. For example:

/certs
  private.key
  public.cert #default certificate
  /object-store.example.net
    private.key
    public.cert # wildcard certificate for *.object-store.example.net
  /s3.example.net
    private.key
    public.cert # wildcard certificate for *.s3.example.net

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.

Third-Party Certificate Authorities

AIStore validates the TLS certificate presented by each connecting client against the host system’s trusted root certificate store.

Place the CA certificates in the /certs/CAs folder. The root path for this folder depends on whether you use the default certificate path or a custom certificate path (minio server --certs-dir or -S)

Default certificate path Custom certificate path

Place the certificate file for each CA into the /CAs subdirectory. Ensure all hosts in the AIStor deployment have a consistent set of trusted CAs in that directory. AIStor allows up to 10 intermediate certificates from request to trusted root certificate.

If AIStor cannot match an incoming client’s TLS certificate issuer against any of the available CAs, the server rejects the connection as invalid.

Internode connections

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.

Supported TLS cipher suites

AIStor recommends generating ECDSA (for example, NIST P-256 curve) or EdDSA (for example, Curve25519) TLS private keys/certificates due to their lower computation requirements compared to RSA.

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

TLS 1.3 TLS 1.2