Setting Up GitLab Subdomain Redirects with SSL

By admin_norgaard , 24 September, 2025
Setting Up GitLab Subdomain Redirects with SSL

This guide shows how to configure multiple subdomains for your GitLab instance, with automatic redirects and SSL certificates. You will end up with both gitlab.example.com and git.example.com working, with the latter redirecting to the former.

Prerequisites

  • GitLab Omnibus installation
  • Two DNS records pointing to your server (gitlab.example.com and git.example.com)
  • Certbot installed for SSL certificates
  • Root access to your server

Step 1: Get SSL Certificates

First, obtain certificates for both domains:

# Stop GitLab nginx temporarily
sudo gitlab-ctl stop nginx

# Get certificates for both domains
sudo certbot certonly --standalone -d gitlab.example.com -d git.example.com

# Start nginx back up
sudo gitlab-ctl start nginx
Rate Limits: Let's Encrypt has rate limits. If you hit them, wait for the reset time shown in the error message.

Step 2: Configure GitLab

Edit your GitLab configuration file:

sudo nano /etc/gitlab/gitlab.rb

Add this configuration:

external_url 'https://gitlab.example.com'
letsencrypt['enable'] = false  # Using manual certs
nginx['ssl_certificate'] = "/etc/letsencrypt/live/gitlab.example.com/fullchain.pem"
nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/gitlab.example.com/privkey.pem"
nginx['redirect_http_to_https'] = true

# HTTPS redirect for git.example.com
nginx['custom_nginx_config'] = "
server {
  listen 443 ssl;
  server_name git.example.com;
  ssl_certificate /etc/letsencrypt/live/gitlab.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/gitlab.example.com/privkey.pem;
  return 301 https://gitlab.example.com\$request_uri;
}

server {
  listen 80;
  server_name git.example.com;
  return 301 https://gitlab.example.com\$request_uri;
}
"

Step 3: Apply Configuration

# Reconfigure GitLab
sudo gitlab-ctl reconfigure

# Check status
sudo gitlab-ctl status

Step 4: Set Up Auto-Renewal

Configure certificate auto-renewal to work with GitLab:

# Edit renewal configuration
sudo nano /etc/letsencrypt/renewal/gitlab.example.com.conf

Add these lines at the bottom:

pre_hook = gitlab-ctl stop nginx
post_hook = gitlab-ctl start nginx

Add renewal to crontab:

sudo crontab -e

Add this line:

0 12 * * * /usr/bin/certbot renew --quiet

Step 5: Test Everything

Verify your setup works:

# Test HTTP redirects to HTTPS
curl -I http://gitlab.example.com
curl -I http://git.example.com

# Test HTTPS works
curl -I https://gitlab.example.com
curl -I https://git.example.com

# Test certificate renewal
sudo certbot renew --dry-run

Expected Results:

  • HTTP requests → 301 redirect to HTTPS
  • git.example.com → 301 redirect to gitlab.example.com
  • gitlab.example.com → 302 redirect to login page
  • Renewal test should succeed

What You Get

  • Flexibility: Users can access GitLab using either domain name
  • Security: All traffic automatically redirected to HTTPS
  • Consistency: Everything ends up at your primary domain
  • Automation: Certificates renew automatically

Both gitlab.example.com and git.example.com now work seamlessly, with the shorter git subdomain redirecting to your main GitLab instance. Perfect for accommodating different user preferences while maintaining a single primary URL.

Remember to replace example.com with your actual domain throughout the configuration.