HTTPS and TLS considerations

Use the provided parameters to configure inbound client, server, and REST connections. For the client component, enable either HTTP or HTTPS for inbound connections, not both. Specify the protocol in the client.inbound.protocol parameter. For the server and REST components, you can enable one or both protocols using the boolean parameters server.inbound.http.enabled, server.inbound.https.enabled, rest.inbound.http.enabled, and rest.inbound.https.enabled.

For HTTPS connections, you can define a custom TLS configuration using the parameters listed in the sections in this table:


Traffic	Section	Description
client inbound	`client.inbound`	REST calls arriving to client from the Link UI code in web browser
server inbound	`server.inbound`	REST calls arriving to server from client and external REST clients (for example, curl)
rest inbound	`rest.inbound`	REST calls arriving to rest from server and external REST clients (for example, curl)
client outbound to server	`client.outbound.server`	REST calls made by client to server
server outbound to rest	`server.oubound.rest`	REST calls made by server to rest** (for deploying packages)
rest outbound to server	`rest.outbound.server`	REST calls made by rest to server (when delegating authentication to server)

The key parameter in each section is the secret parameter.

If not set, the connection uses a built-in self-signed certificate and key.

If set, it must specify the name of a Kubernetes Secret that contains:

A PEM-encoded custom CA certificate chain (used to validate the certificate presented by the invoked component during the TLS handshake).
A certificate and key (used to prove identity when the invoked component requires mutual authentication, or mTLS).

These Kubernetes Secrets must include the following keys and values:


Key	Value
`ca.crt`	PEM encoded CA certificate chain
`tls.crt`	PEM encoded certificate
`tls.key`	PEM encoded private key

You can create these Kubernetes Secrets automatically using a certificate management tool such as cert-manager, or manually using existing CA, certificate, and key files.

For example, the following kubectl command creates a generic Kubernetes Secret named lnk-server-secret when run from a directory containing the PEM-encoded files ca.crt, server.crt, and server.key:

kubectl create secret generic lnk-server-secret --from-file=ca.crt=ca.crt 
--from-file=tls.crt=server.crt --from-file=tls.key=server.k