Install with Self-Signed SSL Certificates

This configuration uses SSL with self-signed digital certificates.

Self-signed digital certificates are free and can be appropriate for internal deployments and air-gapped systems.

The secretsSetup.sh script is used in this tutorial with OpenSSL to create the public and private keys, self-signed digital certificate, API Key, and the Podman secrets. For information about the secretsSetup.sh script and where to download the file, see Configure the Private AI Services Container.

TLS 1.3 will be used for SSL for the container’s listener. This means that any HTTPS clients also must support TLS 1.3, for example SSL libraries like OpenSSL 1.1.1k+ or equivalent.

In this example, your configuration file is /home/opc/config/config.json.

When the secretsSetup.sh script is run, the following files are created in the $SECRETS_DIR directory:

Filename	Description
api-key	A random string used for authentication. The API Key is a shared secret that is needed by the clients.
cert.pem	The self-signed digital certificate
key.pem	The generated private key
key.pub	The generated public key
keystore	A PKCS12 keystore used to store the certificate password

These files are copied to the $PRIVATE_DIR/secrets directory to enable the container to run with least privilege.

Determine the fully qualified hostname where the container will run.
```
export HOST=$(hostname -f)
echo $HOST
```
Define the directory where you want the container’s secrets to be created.

Make sure to use the fully qualified hostname for the OpenSSL Common name/ hostname question and remember the password for the keystore that is created.
```
mkdir /home/opc/privateai
mkdir /home/opc/secrets
export PRIVATE_DIR=/home/opc/privateai
export SECRETS_DIR=/home/opc/secrets
cd /home/opc/setup
./secretsSetup.sh -s $SECRETS_DIR
./configSetup.sh -d $PRIVATE_DIR -s $SECRETS_DIR
./containerSetup.sh -d $PRIVATE_DIR
```
The container is now running using HTTPS port 8443.
In order to use curl with HTTP/SSL, provide the digital certificate as a parameter.

Now that the container is running in HTTP/SSL mode, the curl commands used in previous tutorials for HTTP will no longer work.
```
curl -i --cacert $SECRETS_DIR/cert.pem https://$HOST:8443/health
```
The /health endpoint did not require the API Key but all of the other endpoints will need it.
Define the value of the API_KEY to make the curl SSL commands easier.
```
export API_KEY=$(cat $SECRETS_DIR/api-key)
```

List the loaded models with SSL.

curl --header "Authorization: Bearer $API_KEY" --cacert $SECRETS_DIR/cert.pem  https://$HOST:8443/v1/models

Show the runtime metrics with SSL.

curl --header "Authorization: Bearer $API_KEY" --cacert $SECRETS_DIR/cert.pem https://$HOST:8443/metrics/embeddings_call_latency

Optionally run commands with a different host from the container.

In the case that you want to connect from a remote host, you will want to use the fully qualified hostname of the container to create the self-signed digital certificate. Use the fully qualified hostname for the container from the client machine.

The fully qualified hostname for the container must be resolvable from the client machine. You may need to add an entry in the client’s /etc/hosts file for the container’s fully qualified hostname.

The client machine needs a local copy of the container’s self-signed digital certificate and API_KEY. Copying the contents of the $SECRETS_DIR from the container machine to the client’s $SECRETS_DIR is the simplest way to do this.
```
curl -i --cacert $SECRETS_DIR/cert.pem https://$HOST:8443/health
curl --header "Authorization: Bearer $API_KEY" --cacert $SECRETS_DIR/cert.pem  https://$HOST:8443/v1/models
curl -X POST --header "Authorization: Bearer $API_KEY" -H "Content-Type: application/json" -d '{"model": "multilingual-e5-base", "input":["This is a phrase to vectorize"]}' --cacert $SECRETS_DIR/cert.pem https://$HOST:8443/v1/embeddings
curl --header "Authorization: Bearer $API_KEY" --cacert $SECRETS_DIR/cert.pem https://$HOST:8443/metrics/embeddings_call_latency
```