Note these instructions are for the omnibus installation of GitLab v10+.
If you have a server live on the internet that can be resolved using a FQDN then you might want to use Gitlab’s new built-in Let’s Encrypt certificate tool.
suSelf-signed certificates are most useful for internal servers that aren’t accessible from the Internet. These servers consequently cannot use Let’s Encrypt certificates. In these cases we secure the communications from eavesdropping by generating our own self-signed SSL 2048bit certificate.
Since we are going to be spending the next 10 minutes generating and configuring the certificate it is important to note that we will be generating a certificate that will be valid for 10 years. Typically certificates are seldom issued for this amount of time but we are using this long expiry date to avoid having to repeat these steps unnecessarily, which would be taking us away from our precious development endeavors.
This guide is divided in two steps. We first assign a timezone to our server and we then proceed to configure gitlab to use our self-signed certificate which we will generate using the steps outlined below.
Configure Timezone
Configure your timezone. This is important when using SSL connections. Having the incorrect time can open your server to timing attacks.
sudo nano /etc/gitlab/gitlab.rb
Update this line to match your timezone.
gitlab_rails['time_zone'] = 'UTC'
For EST the directive is modified as follows:
gitlab_rails['time_zone'] = 'America/New_York'
If you are usure which timezone you need you can look it up here.
Create and Install Self-Signed Certificate
1. Create your Self-Signed Certificate (3 steps)
1. Create a private key using 2048 bits
sudo openssl genrsa -out gitlab.key 2048
2. Create certificate signing request (CSR)
sudo openssl req -new -key gitlab.key -out gitlab.csr
3. Create self-signed certificate (valid for 10 years)
sudo openssl x509 -req -days 3650 -in gitlab.csr -signkey gitlab.key -out gitlab.pem
2. Copy your SSL Certificate
Place certificates in the following directory
/etc/gitlab/trusted-certs/
Example:
sudo cp gitlab.pem /etc/gitlab/trusted-certs/gitlab.pem
3. Run gitlab-ctl reconfigure
gitlab-ctl reconfigure
4. Move non-certificate files out of /opt/gitlab/embedded/ssl/certs and run gitlab-ctl reconfigure again
Example:
mkdir ~/gitlab-backups sudo mv filename ~/gitlab-backups sudo mv filename2 ~/gitlab-backups gitlab-ctl reconfigure
5. Update your gitlab URL to use HTTPS
sudo nano /etc/gitlab/gitlab.rb external_url "https://gitlab.example.com"
Run gitlab-ctl reconfigure
gitlab-ctl reconfigure
6. After running the gitlab-ctl reconfigure
You will most likely see errors in your terminal indicating that Let’s Encrypt certificate failed. This is fine. Gitlab will automatically try to generate an SSL certificate once you update your external_url in gitlab.rb to use a HTTPS prefix.
It is safe to ignore this error as it does not apply to you. Your server will not be using Let’s Encrypt and your self-signed certificate will still be applied as expected.
Sample Error Message:
There was an error running gitlab-ctl reconfigure:
letsencrypt_certificate[gitlab] (letsencrypt::http_authorization line 3) had an error: Acme::Client::Error::Malformed: acme_certificate[staging] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 20) had an error: Acme::Client::Error::Malformed: Error creating new authz :: DNS name does not have enough labels
Safely ignore the above error message.
Now you can navigate to your gitlab installation adding the https to your hostname. You will most likely be presented with a self-signed certificate warning. This is normal browser behavior and you can ignore the message and/or add a Permanent Exception if you are using Firefox browser.
Enjoy!
References:
https://docs.gitlab.com/omnibus/settings/configuration.html
https://docs.gitlab.com/ce/workflow/timezone.html#changing-your-time-zone
https://docs.gitlab.com/omnibus/settings/ssl.html
