Travis

Travis CI Enterprise SSL Certificate Management

This page contains information relating to SSL certificates and their use in Travis CI Enterprise (TCIE).

By default, Travis CI Enterprise verifies SSL for all traffic between internal platform components, RabbitMQ, and, e.g., Github.com/Github Enterprise. SSL verification helps to ensure that traffic is delivered securely.

It is strongly recommended that you configure your installation with a valid certificate from a trusted authority.

If you have questions about a specific section or have an issue that is not covered, please contact us at enterprise@travis-ci.com for assistance.

Self-Signed Certificates #

We strongly recommend using a valid certificate from a trusted authority when configuring your installation. That said, we recognize various scenarios where using a self-signed certificate might make more sense for your organization.

In all cases of using self-signed certificates, you must disable SSL certificate validation in your settings. This can be done after installation is complete.

After installation, you can upload a certificate at any time via the Admin Dashboard.

Use a trial license in TCIE 3.x #

If you are using a trial license to evaluate Travis CI Enterprise, using a trusted certificate might not make sense. For this scenario we offer the ability to use self-signed certificates that Travis CI Enterprise itself generates.

You may use your admin-console to upload your self-signed SSL certificate and/or you may need to disable SSL Verification mechanism.

Organizations with an internally managed certificate authority #

Some organizations manage their own internal certificate authority. An internal authority may use a root certificate provided by a trusted root authority.

Organization without a root certificate from a trusted certificate authority #

If your internal certificate authority is not using a root certificate provided by a trusted certificate authority, any certificates produced are considered to be ‘untrusted’ by most tools and browsers, the same as a self-signed certificate.

Certificates created by an internal certificate authority can be uploaded during installation in the same way as any other certificate.

Please be aware that you will also need to follow the instructions on disabling SSL verification below in order to use Travis CI Enterprise.

Organization with a root certificate from a trusted certificate authority #

If your organization’s internal certificate authority does use a root certificate purchased from a trusted certificate authority, the above will not apply. You will not need to disable SSL verification and can proceed as if you are using a certificate directly from a trusted certificate authority.

In some cases it may be necessary to include the intermediate certificate chain in the settings in order for SSL verification to work correctly. The reasons for this can vary depending on your internal setup and your root certificate provider. Please see the section below on how to set intermediate certificate chains for instructions.

Disable SSL Verification in TCIE 3.x #

SSL verification helps to ensure that all traffic between Travis CI Enterprise components is protected. Disabling SSL verification has serious implications!

  1. Access the admin-console config page under http://localhost:8800. If it’s unavailable, try running kubectl kots admin-console --namespace [namespace] and access http://localhost:8800 (admin-console is run on local machine).
  2. Browse to ‘Config’
  3. Find ‘Advanced settings’
  4. Disable SSL verification by marking the appropriate checkbox and save settings
  5. Click ‘Save Config’ at the bottom of the page.
  6. A new version will appear in the Dashboard. Click ‘Deploy’. The changes will be deployed in your Kubernetes cluster.

Disabling SSL in TCIE 3.x

Add or Update Certificates after Installation in TCIE 3.x #

You can add or update certificates via the Admin Dashboard anytime after installation.

  1. Access the admin-console config page under http://localhost:8800. If it’s unavailable, try running kubectl kots admin-console --namespace [namespace] and access http://localhost:8800 (admin-console is run on local machine).
  2. Browse to ‘Config’
  3. Find ‘HTTP Setting’
  4. Please choose between:
    1. If you want to use an automatically generated by TCIE 3.x self-signed certificate: select ‘HTTPS enabled’ option.
    2. If you want to upload your own SSL certificate: select ‘HTTPS enabled’ and ‘Upload SSL keys’ options - two text fields will be shown for uploading the TLS certificate and key. Paste appropriate data in.
    3. If you want to use generated letsencrypt certificates: select the ‘Let’s Encrypt HTTPS option’

      Please note that during the very first installation of TCIE 3.x, when DNS records do not point yet to the correct Load Balancer in the Kubernetes cluster, Let’s Encrypt certificate cannot be properly generated. Therefore, configure a self-signed certificate first, and after the deployment of the Platform and DNS setup are done, re-configure the TCIE Platform to use the Let’s Encrypt certificate.

  5. Click ‘Save Config’ at the bottom of the page.
  6. A new version will appear in the Dashboard. Click ‘Deploy’. The changes will be deployed in your Kubernetes cluster.

Adding or updating SSL in TCIE 3.x

Please note that selecting ‘HTTPS disable’ will disable https for the whole Platform installation.

Use Intermediate Certificate Chains #

In some cases, you may be required to provide the intermediate certificate chain for your desired certificate. Reasons for this can vary depending on your internal setup and root certificate provider.

If you have uploaded a valid certificate but still see unexpected issues related to SSL verification errors, you can set your intermediate certificate chain in the settings.

Intermediate Certificate Chains in TCIE 3.x #

Not available at the moment. It will be added soon.

How to use a Let’s Encrypt SSL Certificate #

You can use a certificate from Let’s Encrypt instead of a self-signed certificate or a certificate purchased from a trusted certificate authority. Certificates from Let’s Encrypt are free and behave the same as those purchased from a trusted certificate authority.

What you will need:

  • An email address (Let’s Encrypt will send notifications regarding urgent renewal and security issues).
  • A domain name under which your installation is available.

The following steps require downtime for your Travis CI Enterprise instance. For this reason, we recommend that you perform these steps during a maintenance window.

Let’s Encrypt SSL Certificate in TCIE 3.x #

Since certbot is already installed within TCIE 3.0 images, you don’t need to install it separately.

  1. Access the admin-console config page under http://localhost:8800. If it’s unavailable, try running kubectl kots admin-console --namespace [namespace] and access http://localhost:8800 (admin-console is run on local machine).
  2. Browse to ‘Config’
  3. Find ‘HTTP Setting’
  4. Choose from existing methods select the ‘Lets Encrypt HTTPS option’
  5. Click ‘Save Config’ at the bottom of the page.
  6. A new version will appear in the Dashboard. Click ‘Deploy’. The changes will be deployed in your Kubernetes cluster.

The Let’s Encrypt certificate will be automatically generated and installed. A restart of nginx will occur during the deployment.

Certificate Renewal #

Let’s Encrypt certificates are short-lived, and expire after 90 days. Because of this, you will need to renew them regularly.

Renew the Let’s Encrypt Certificate for TCIE 3.x #

Currently, the Let’s Encrypt certificate is automatically refreshed every time the nginx pod is started. So to refresh it:

  1. Kill the nginx pod
  2. Deploy it again (e.g., scale replicas down to 0 and back to target number)

Contact Enterprise Support #

To get in touch with us, please write a message to enterprise@travis-ci.com. If possible, please include as much of the following as you can:

  • Description of the problem - what are you observing?
  • Which steps did you try already?
  • A support bundle (see table below on how to obtain it)
  • Log files from all workers (They can be found at /var/log/upstart/travis-worker.log - please include as many as you can retrieve).
  • If a build failed or errored, a text file of the build log
TCI Enterprise version Support bundle
3.x Run kubectl kots admin-console -n [namespace] to access admin console on http://localhost:8800
Support bundle generation instruction is available in ‘troubleshoot’ menu or directly at: http://localhost:8800/app/tci-enterprise-kots/troubleshoot

A command for generating support bundle will appear after selecting:
If you'd prefer, [click here]() to get a command to manually generate a support bundle.
2.x+ You can get it from https://<your-travis-ci-enterprise-domain>:8800/support

Since the announcement in Q3 2020, the most up to date version of Travis CI Enterprise is 3.x line. There are not any new releases for version 2.2 and the support patches has been limited since March 2021 as well. For existing users of Travis CI 2.x we strongly recommend upgrading to the latest Travis CI Enterprise 3.x.

Have you made any customizations to your setup? While we may be able to see some information (such as hostname, IaaS provider, and license expiration), there are many other things we cannot see which could lead to something not working. Therefore, we would like to ask you to also answer the questions below in your support request (if applicable):

  • How many machines are you using / what is your Kubernetes cluster setup?
  • Do you use configuration management tools (Chef, Puppet)?
  • Which other services do interface with Travis CI Enterprise?
  • Which Version Control system (VCS) do you use together with Travis CI Enterprise (e.g. github.com, GitHub Enterprise, or BitBucket Cloud)?
  • If you are using GitHub Enterprise, which version of it?

We are looking forward to helping!