TABLE OF CONTENTS
IT administrators can configure and manage the TLS certificate through the Admin Console during installation and update it whenever needed.
TLS Certificate Options
Customers can provide their own TLS certificate or opt for automatic certificate generation by Labforward.
The certificate must cover all subdomains described in the Labfolder Domain & Subdomains section. Wildcard certificates (e.g., *.labforward.app) are fully supported.
The following options are available:
1. Customer-Provided TLS Certificate
To configure a customer-provided TLS certificate, upload the required files in the Admin Console:
Custom certificate configurations
- Certificate File
Upload the .crt or .cer file containing all subdomains listed in the Labfolder Domain & Subdomains section.
- Private Key File
Upload the .key file corresponding to the domain certificate.
- CA Certificate
Upload the intermediary .crt or .cer file. If the root certificate from the Certificate Authority (CA) is unknown, include it as well.
Supports certificate chains containing all intermediate and root certificates. See the Understanding the Certificate Chain section for details.
2. Labforward-Generated TLS Certificates
Labforward offers two automatic certificate generation options:
Labforward managed certificates
- Let’s Encrypt Certificate
Automatically generated and validated by Let’s Encrypt. See more details on Let’s Encrypt’s page.
Let’s Encrypt requires access to the cluster to validate the certificate. For this reason, the following endpoint must be exposed on the public internet /.well-known/acme-challenge/*.
This is a full example of the Let’s Encrypt validation request using the labforward.app domain: http://account.labforward.app/.well-known/acme-challenge/cr1rsRTImVz_s7HHk7biTQ. It makes one request for each subdomain available.
- Self-Signed Certificate
- Generated by the Labforward platform.
- Can be manually distributed within the internal network to establish trust.
To fetch the generated certificate, run the command:
sudo kubectl get secret labforward-tls-certificate -o jsonpath={".data.ca\.crt"} | base64 --decode > ca.crtBoth Labforward-generated certificates are managed using a cert-manager. If you are providing your Kubernetes installation and already have a cert-manager, it is possible to disable Labforward’s cert-manager in favor of your installation. Lastly, limiting the cert-manager only to Labforward’s namespace is possible by selecting the Namespace Issuer option.
Changing or Renewing the TLS Certificate
IT administrators can modify the existing TLS certificate via the Admin Console at any time. The update process is the same as described in the TLS Certificate Options above.
It is possible to replace only the certificate and key or all the files simultaneously.
After replacing the certificate files and deploying the new configuration, the applications will automatically update to the new certificate.
Understanding the Certificate Chain
A TLS certificate chain consists of multiple certificates that help a client verify the authenticity of a server’s certificate. It includes:
1. End-Entity Certificate (Leaf Certificate) – Issued to the website or service.
2. Intermediate Certificate(s) – Issued by a trusted Certificate Authority (CA) to bridge the gap between the root and the server certificate.
3. Root Certificate – The trusted authority that signs intermediate certificates. These are pre-installed in operating systems and browsers.
How the TLS Certificate Chain Works
When a client (e.g., a web browser) connects to a server using TLS, the following process occurs:
1. Server Sends Certificate Chain
- The server presents its certificate along with intermediate certificates to the client.
2. Client Validates the Chain
- The client checks if an intermediate certificate signs the server’s certificate.
- It then checks if a trusted root certificate signs the intermediate certificate.
- The process continues until a known root certificate is found.
3. Establishing Trust
- The client proceeds with a secure connection if the certificate chain is valid and leads to a trusted root certificate.
- If validation fails, the client may display a security warning.
Example of a TLS Certificate Chain
Root CA Certificate → Intermediate CA Certificate → Server Certificate
For example:
- GlobalTrust Root CA
- Intermediate CA - SecureWeb Authority
- www.labforward.app
The browser or system trusts GlobalTrust Root CA, which in turn validates the Intermediate CA -SecureWeb Authority and finally verifies the www.labforward.app certificate, which will include the domain and all the subdomains described above.
In this example, the Intermediate CA -SecureWeb Authority should be included in the CA Certificate field and www.labforward.app in the Certificate file. As a known Certificate authority issues the GlobalTrust Root CA, it is unnecessary.
Inserting Multiple CA Certificates
If there is more than one intermediary or the root certificate is not issued by a known CA, all of them should be merged into a single .cer file and added to the CA Certificates field. This ensures that the full certificate chain is presented to clients.
Example: Merging Certificates into a Single .cer File
Assume you have the following certificate files:
- labforward.crt (Server Certificate, not required by Labforward as part of the certificate chain)
- intermediate1.crt (First Intermediate CA Certificate)
- intermediate2.crt (Second Intermediate CA Certificate)
- root.crt (Root CA Certificate)
Use a text editor or command line to concatenate the certificates in the correct order:
cat intermediate1.crt intermediate2.crt root.crt > ca_chain.cer
Verify the correctness:
openssl verify -CAfile mydomain_fullchain.cer ca_chain.cer
The ca_chain.cer should be included in the CA Certificates field in the admin console.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article