Skip to main content

TLS certificates (legacy)

caution

You are now on a GitGuardian legacy architecture page.

Looking for the GitGuardian new architecture Configure TLS certificates page? Please visit the Configure TLS certificates page.

For information on the new architecture, as well as determining whether you are using the new or the legacy GitGuardian architecture, explore the New GitGuardian Architecture page.

TLS certificates need to be defined so that the domain on referring to your GitGuardian instance is correctly authenticated and secured. The TLS certificate's Common Name must match the domain set for your GitGuardian instance hostname.

You can use self-signed certificates to test the deployment of the application, be aware that this may lead to integration issues with VCS and is not recommended beyond initial testing.

You need to configure TLS certificates for:

  1. KOTS Admin Console: used for the KOTS Admin Console user access.
  2. GitGuardian Application: used for the GitGuardian application user access (sometime also referred as NGINX).
  3. SAML SSO: used for Single Sign-On (or SSO) to manage your organization’s entire membership via a third-party provider.
caution

We strongly recommend revoking any certificate being replaced, regardless of its expiration status, to maintain system security.

KOTS Admin Console

To update the TLS certificate for the KOTS Admin Console, follow these instructions.

caution

Adding the acceptAnonymousUploads annotation temporarily creates a vulnerability for an attacker to maliciously upload TLS certificates. After TLS certificates have been uploaded, the vulnerability is closed again.

Short version:

NAMESPACE=default
kubectl --namespace "${NAMESPACE}" annotate secret kotsadm-tls acceptAnonymousUploads=1
kubectl --namespace "${NAMESPACE}" delete pod -l app=kurl-proxy-kotsadm

If needed, specify another Kubernetes namespace (default namespace is used if not specified).

After the pod has restarted, direct your browser to http://<ip>:8800/tls and go through the upload process in the user interface.

GitGuardian Application

caution

When using self-signed or custom CA certificates, ensure to disable SSL verification for the GitHub webhook.

Certificates in embedded cluster

TLS certificates can be configured during the application setup in KOTS Admin Console, as illustrated on the embedded installation page.

You have the option to use the TLS certificates specified in the KOTS setup for your GitGuardian Application, or you can provide your own certificates as shown below:

legacy-embedded-tls.png

To upload new certificates, replace the previously uploaded files in the KOTS Admin Console.

After updating the configuration, deploy the new version which includes only the configuration changes:

Deploying the updated configuration

Certificates in existing cluster

TLS certificates can be integrated using an existing Kubernetes secret of type kubernetes.io/tls, or by directly uploading the certificates within the KOTS Admin Console.

nginx-certificate.png

Once you've updated your certificate configuration, proceed to deploy the updated application version to apply these configuration changes:

Deploying the updated configuration

SAML SSO

This guide outlines the steps to update the SSO X509 certificate used by GitGuardian for authentication with a third-party SSO provider. For more detailed information on configuring SAML SSO, refer to the Configure SAML SSO page.

Generate a Self-Signed Certificate

To rotate the SSO certificate, start by generating a new self-signed certificate:

  1. Generate a new RSA private key:

Generate a new 2048-bit RSA private key using OpenSSL with the following command:

openssl genrsa -out gitguardian.key 2048
  1. Create a Certificate Signing Request (CSR):

Use the generated private key to create a CSR. Replace <hostname> with the Fully Qualified Domain Name of your self-hosted instance.

openssl req -new -subj '/CN=<hostname>' \
-key gitguardian.key \
-out gitguardian.csr
  1. Create a self-signed certificate:

Use the CSR to create a self-signed certificate valid for 365 days (or as required):

openssl x509 -req -days 365 -in gitguardian.csr \
-signkey gitguardian.key -out gitguardian.crt

Preparing the KOTS Configuration File

Create or update your config.yaml to include the new certificate and key:

apiVersion: kots.io/v1beta1
kind: ConfigValues
spec:
values:
embedded_certificate:
values: |
<content_of_gitguardian.crt>

embedded_key:
values: |
<content_of_gitguardian.key>

Update KOTS Configuration Values

Update the KOTS configuration with the new certificate and private key:

kubectl kots set config gitguardian-seal --namespace <namespace> \
--config-file config.yaml \
--merge

If needed, specify the Kubernetes namespace with --namespace (default namespace is used if not specified).

Connect to the KOTS Admin Console

To apply the changes, connect to the KOTS admin console:

kubectl kots --namespace <namespace> admin-console

If needed, specify the Kubernetes namespace with --namespace (default namespace is used if not specified).

Deploy the New Version

After updating the configuration, deploy the new version which includes only the configuration changes:

Deploying the updated configuration

info

If you encounter 403 errors after attempting to "Login with Okta," clearing your web browser's cache may resolve the issue.

How can I help you ?