Network Encryption on Baremetal

For an overview of network encryption and how to enable TLS with other topologies, see Network Encryption. This page explains how to manage TLS certificates on baremetal deployments.

Enable TLS

AIStor searches for TLS keys and certificates for each node and automatically enables TLS upon discovery and validation of certificates. The search location depends on your 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.

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.

For example:

/path/to/certs
private.key
public.crt

AIStor certgen can mint self-signed certificates for evaluating AIStor with TLS enabled. For example, the following command generates a self-signed certificate with a set of IP and DNS Subject Alternate Names (SANs) associated to the AIStor hosts:

certgen -host "localhost,minio-*.example.net"

Place the generated public.crt and private.key into the /path/to/certs directory to enable TLS for the AIStor deployment. Applications can use the public.crt as a trusted Certificate Authority (CA) to allow connections to the AIStor deployment without disabling certificate validation.

If you are reconfiguring an existing deployment that did not previously have TLS enabled, update MINIO_VOLUMES to specify https instead of http. You may also need to update URLs used by applications or clients.

Self-signed, internal, private certificates, and public CAs with intermediate certificates

For certificates signed by a non-global or non-public CA, or for a global CA that requires the use of intermediate certificates, you must provide the CAs to the AIStor Server. AIStor allows up to 10 intermediate certificates from request to trusted root certificate. If the necessary CAs are not present, it may return warnings or errors related to TLS validation when connecting to other services.

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

For self-signed certificates, use the public file of the self-signed certificate as the CA. Place the self-signed public certificate in the /certs/CAs directory so that AIStor can trust it.

Important

Do not use or share the private key of the self-signed certificate. Only the public certificate should be shared or distributed for trust purposes.

For certificates signed by an internal, private, or other non-global CA, use the same CA that signed the cert. A non-global CA must include the full chain of trust from the intermediate certificate to the root.

If the provided file is not an X.509 certificate, AIStor ignores it and may return errors for validating certificates signed by that CA.

Third-Party Certificate Authorities

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

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