Version 1.0.0
The chain of trust
The TLS-encrypted links between components, which component checks whose certificate on each one, and the settings that name the recognized authorities.
Traffic between Lemniscate components is encrypted with TLS (security white paper V3, sections 3.3 and 6.2). On each link, one component checks the other’s certificate. This page describes which component checks which, and the settings that name the recognized certificate authorities.
No setting disables certificate verification, and no proprietary algorithm is used.
The links
Section titled “The links”In this diagram, an arrow reads “checks the certificate of”. It starts at the component doing the checking and points to the one being checked.
These links are the ones in the flow matrix (security white paper V3, section 3.3). The workstation has only one: it knows only the gateway’s address.
What this diagram does not show
Section titled “What this diagram does not show”- The control channel the gateway opens to the execution host. This is the only flow between these two hosts, and the execution host opens none (security white paper V3, section 3.3).
- The administration console. It talks to the database with its own connection string, so its own verification.
- Anything that is not a certificate. Developer authentication against your directory, revocation and permissions are a separate mechanism, described in The gateway’s role.
From the workstation to the gateway
Section titled “From the workstation to the gateway”The flow from the workstation to the gateway is encrypted with TLS, and it is the only workstation flow related to Lemniscate (security white paper V3, section 3.3). The workstation checks the gateway’s certificate the way any client checks a server.
Two settings act on this link, in the workstation configuration:
| Setting | What it does |
|---|---|
caBundlePath | adds a certificate authority to the recognized ones |
clientCertificate | presents a client certificate, with its key and its passphrase |
When the gateway’s certificate is signed by your internal authority, caBundlePath
names it. The authority is added to the system’s, it does not replace them.
The gateway does not identify the workstation by certificate. The developer is authenticated against your directory, and their session is tied to their identity and to a project (security white paper V3, section 6.1).
The gateway listening
Section titled “The gateway listening”The gateway terminates TLS itself. It receives its certificate and its key
through two environment variables: TLS_CERT_FILE and TLS_KEY_FILE. It is the only
interface exposed to workstations (security white paper V3, section 6.2).
From the gateway to the inference engine
Section titled “From the gateway to the inference engine”The gateway checks the inference engine’s certificate. No environment variable, no flag and no debug mode disables this verification: the setting does not exist in the code.
Two things are configurable: the recognized authority and what the gateway presents.
| Variable | What it sets |
|---|---|
NODE_EXTRA_CA_CERTS | an internal authority, added to the system authorities |
UPSTREAM_TLS_CA_FILE | an authority specific to the path to the engine |
UPSTREAM_TLS_CLIENT_CERT_FILE, UPSTREAM_TLS_CLIENT_KEY_FILE | the client certificate, when the engine requires one |
Additional authorities are added, they do not replace. An authority declared for the path to the engine removes neither the system authorities nor the company’s.
Encryption does not replace network filtering: the engine listens only on the inference server’s internal network, and your filtering lets only the gateway host reach it (security white paper V3, sections 3.3 and 8.2).
From the gateway to the database
Section titled “From the gateway to the database”The link between the gateway and the database is encrypted with TLS, and the
database server’s certificate is checked. No setting makes the verification
optional. The authority that signs the database server’s certificate is added
through one of two entries: the path to its PEM file (DATABASE_CA_CERT_PATH) or the contents of
that PEM (DATABASE_CA_CERT), depending on whether the platform can mount a volume or only
pass environment variables. Both entries lead to the same resolution; setting
both makes startup fail. An authority’s certificate is not a secret: it is the
public half of a key pair.
An encryption parameter written in the database connection string is rejected. A
sslmode, a sslrootcert or one of their neighbors in DATABASE_URL prevents the gateway from
starting, along with the steps to follow: the connection library would let that
parameter override the verification set elsewhere.
Configurations rejected at startup
Section titled “Configurations rejected at startup”On all its links, the gateway refuses to start when the encryption configuration is incomplete or unreadable. The rejected cases:
- only one of the two certificate variables set, both when listening and toward the engine;
- an unreadable certificate, key or authority file;
- a certificate-key pair that does not match, a file in an invalid format, a private key protected by a passphrase.
Each of these cases stops startup with a message that names the variable at fault.